summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2021-01-18arm64: defconfig: Enable Broadcom BCM54140 PHYMichael Walle1-0/+1
Enable support for the QuadPHY on the Kontron K-Box A-230-LS. Enable the driver as a module. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-18arm64: dts: freescale: sl28: enable SATA supportMichael Walle1-0/+4
With a newer bootloader SATA might be used in a mPCI slot using a mSATA card. Enable the SATA controller on the Kontron K-Box LS-230-A which comes with such a slot. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-18arm64: dts: lx2160a-cex7: delete RTC interruptRussell King1-2/+0
The RTC interrupt is incorrect and prevents the RTC driver initialising. In any case, the PCF2127 driver wants an active low interrupt, which neither the GIC nor the GPIO blocks support. There is an ISPPT block in the LX2160A, but this is not supported in mainline kernels. So, just delete the interrupt. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-18arm64: dts: imx8mn-beacon-som: Configure RTC aliasesAdam Ford1-1/+6
On the i.MX8MN Beacon SOM, there is an RTC chip which is fed power from the baseboard during power off. The SNVS RTC integrated into the SoC is not fed power. Depending on the order the modules are loaded, this can be a problem if the external RTC isn't rtc0. Make the alias for rtc0 point to the external RTC all the time and rtc1 point to the SVNS in order to correctly hold date/time over a power-cycle. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-18arm64: dts: imx8mm-beacon: add more pinctrl states for usdhc1Adam Ford1-1/+3
The WiFi chip is capable of communication at SDR104 speeds. Enable 100Mhz and 200MHz pinmux to support this. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-18arm64: dts: lx2160a-clearfog-itx: add power button supportRussell King1-0/+12
Add support for the power button. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-16arm64: dts: qcom: qrb5165-rb5: sort nodes alphabeticallyDmitry Baryshkov1-20/+20
Move swr0 device node to keep alphabetical sorting order of device tree nodes. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210116002346.422479-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-16Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski1-4/+12
Daniel Borkmann says: ==================== pull-request: bpf-next 2021-01-16 1) Extend atomic operations to the BPF instruction set along with x86-64 JIT support, that is, atomic{,64}_{xchg,cmpxchg,fetch_{add,and,or,xor}}, from Brendan Jackman. 2) Add support for using kernel module global variables (__ksym externs in BPF programs) retrieved via module's BTF, from Andrii Nakryiko. 3) Generalize BPF stackmap's buildid retrieval and add support to have buildid stored in mmap2 event for perf, from Jiri Olsa. 4) Various fixes for cross-building BPF sefltests out-of-tree which then will unblock wider automated testing on ARM hardware, from Jean-Philippe Brucker. 5) Allow to retrieve SOL_SOCKET opts from sock_addr progs, from Daniel Borkmann. 6) Clean up driver's XDP buffer init and split into two helpers to init per- descriptor and non-changing fields during processing, from Lorenzo Bianconi. 7) Minor misc improvements to libbpf & bpftool, from Ian Rogers. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (41 commits) perf: Add build id data in mmap2 event bpf: Add size arg to build_id_parse function bpf: Move stack_map_get_build_id into lib bpf: Document new atomic instructions bpf: Add tests for new BPF atomic operations bpf: Add bitwise atomic instructions bpf: Pull out a macro for interpreting atomic ALU operations bpf: Add instructions for atomic_[cmp]xchg bpf: Add BPF_FETCH field / create atomic_fetch_add instruction bpf: Move BPF_STX reserved field check into BPF_STX verifier code bpf: Rename BPF_XADD and prepare to encode other atomics in .imm bpf: x86: Factor out a lookup table for some ALU opcodes bpf: x86: Factor out emission of REX byte bpf: x86: Factor out emission of ModR/M for *(reg + off) tools/bpftool: Add -Wall when building BPF programs bpf, libbpf: Avoid unused function warning on bpf_tail_call_static selftests/bpf: Install btf_dump test cases selftests/bpf: Fix installation of urandom_read selftests/bpf: Move generated test files to $(TEST_GEN_FILES) selftests/bpf: Fix out-of-tree build ... ==================== Link: https://lore.kernel.org/r/20210116012922.17823-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15arm64: defconfig: Drop unused K3 SoC specific optionsNishanth Menon1-2/+0
With [1] integrated and all users of the config symbols removed, we can safely remove the options from defconfig. [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201026170624.24241-1-nm@ti.com/ Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210107132228.6577-1-nm@ti.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-15Merge tag 'imx-fixes-5.11' of ↵Arnd Bergmann2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.11: - Fix backlight pwm on imx6qdl-kontron-samx6i which is lost from #pwm-cells conversion. - Fix duplicated bus node name for i.MX8MN SoC. - Fix reset register offset on LS1028A SoC. - Rename MMC node aliases for imx6q-tbs2910 to keep the MMC device index consistent with previous kernel version. - Selecting ARM_GIC_V3 on non-CP15 processors to fix one build failure with i.MX8M SoC driver. - Fix typos with status property on imx6qdl-kontron-samx6i board. - Fix duplicated regulator-name on imx6qdl-gw52xx board. * tag 'imx-fixes-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx6qdl-gw52xx: fix duplicate regulator naming ARM: dts: imx6qdl-kontron-samx6i: fix i2c_lcd/cam default status ARM: imx: fix imx8m dependencies ARM: dts: tbs2910: rename MMC node aliases arm64: dts: ls1028a: fix the offset of the reset register arm64: dts: imx8mn: Fix duplicate node name ARM: dts: imx6qdl-kontron-samx6i: fix pwms for lcd-backlight Link: https://lore.kernel.org/r/20210112131224.GI28365@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-15arm64: defconfig: Enable Qualcomm SM8250 audio configDmitry Baryshkov1-0/+5
Enable ASoC platform driver and condec drivers for Qualcomm SM8250 platform and devices based on it. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210115151522.399359-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15Merge tag 'renesas-arm-dt-for-v5.12-tag1' of ↵Arnd Bergmann18-85/+1140
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/dt Renesas ARM DT updates for v5.12 - Timer (CMT/TMU) support for R-Car Gen3 SoCs, - Watchdog (RWDT), pincontrol (PFC), GPIO, and DMA (SYS-DMAC) support for the R-Car V3U SoC, - USB2 clock selector and SPI Multi I/O Bus Controller (RPC-IF) support for RZ/G2 SoCs, - Support for the Beacon EmbeddedWorks RZ/G2H and RZ/G2N kits, - Various fixes and improvements. * tag 'renesas-arm-dt-for-v5.12-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (24 commits) arm64: dts: renesas: r8a779a0: Add SYS-DMAC nodes arm64: dts: renesas: r8a779a0: Add GPIO nodes arm64: dts: renesas: r8a779a0: Add pinctrl device node arm64: dts: renesas: rzg2: Add RPC-IF Support arm64: dts: renesas: rzg2: Add usb2_clksel to RZ/G2 M/N/H arm64: dts: renesas: r8a774e1: Introduce beacon-rzg2h-kit arm64: dts: renesas: r8a774b1: Introduce beacon-rzg2n-kit arm64: dts: renesas: beacon-rzg2m-kit: Rearrange SoC unique functions arm64: dts: renesas: beacon: Better describe keys arm64: dts: renesas: beacon: Configure Audio CODEC clocks arm64: dts: renesas: beacon kit: Fix Audio Clock sources arm64: dts: renesas: beacon: Configure programmable clocks arm64: dts: renesas: falcon: Enable watchdog timer arm64: dts: renesas: r8a779a0: Add RWDT node arm64: dts: renesas: beacon: Correct I2C bus speeds arm64: dts: renesas: beacon: Enable SPI arm64: dts: renesas: beacon: Don't make vccq_sdhi0 always on arm64: dts: renesas: beacon: Fix RGB Display PWM Backlight arm64: dts: renesas: beacon: Fix LVDS PWM Backlight arm64: dts: renesas: beacon: Fix audio-1.8V pin enable ... Link: https://lore.kernel.org/r/20210115094610.2334058-2-geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-15arm64: defconfig: enable Lontium LT9611UXC bridge driverDmitry Baryshkov1-0/+1
Enable lt9611uxc driver for Lontium DSI to HDMI bridge found on Qualcomm RB5 Robotics platform. Enable this driver to get display working on this platform. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201228151827.4019213-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: defconfig: enable display clock controller on sm8250Dmitry Baryshkov1-0/+1
Enable the driver for the display clock controller on Qualcomm SM8250, needed in order to get the display working. This driver provides power-domains and as such should not be compiled as a module. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201228151225.4018477-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: qcom: qrb5165-rb5: fix uSD pins drive strengthDmitry Baryshkov1-4/+2
Lower drive strength for microSD data and CMD pins from 16 to 10. This fixes spurious card removal issues observed on some boards. Also this change allows us to re-enable 1.8V support, which seems to work with lowered drive strength. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Fixes: 53a8ccf1c7e5 ("arm64: dts: qcom: rb5: Add support for uSD card") Link: https://lore.kernel.org/r/20201217183341.3186402-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: qcom: sc7180: Add labels for cpuN-thermal nodesMatthias Kaehlcke1-10/+10
Add labels to the cpuN-thermal nodes to allow board files to use a phandle instead replicating the node hierarchy when adjusting certain properties. Due to the 'sustainable-power' property CPU thermal zones are more likely to need property updates than other SC7180 zones, hence only labels for CPU zones are added for now. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20210108141648.1.Ia8019b8b303ca31a06752ed6ceb5c3ac50bd1d48@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: qcom: sm8250: Add CPU capacities and energy modelDanny Lin1-0/+16
Power and performance measurements were made using my freqbench [1] benchmark coordinator, which isolates, offlines, and disables the timer tick on test CPUs to maximize accuracy. It uses EEMBC CoreMark [2] as the workload and measures power usage using the PM8150B PMIC's fuel gauge. The energy model dynamic-power-coefficient values were calculated with DPC = µW / MHz / V^2 for each OPP, and averaged across all OPPs within each cluster for the final coefficient. Voltages were obtained from the qcom-cpufreq-hw driver that reads voltages from the OSM LUT programmed into the SoC. Normalized DMIPS/MHz capacity scale values for each CPU were calculated from CoreMarks/MHz (CoreMark iterations per second per MHz), which serves the same purpose. For each CPU, the final capacity-dmips-mhz value is the C/MHz value of its maximum frequency normalized to SCHED_CAPACITY_SCALE (1024) for the fastest CPU in the system. A Xiaomi Redmi K30S Ultra device running a downstream Qualcomm 4.19 kernel was used for benchmarking to ensure proper frequency scaling and other low-level controls. Raw benchmark results can be found in the freqbench repository [3]. Below is a human-readable summary: Frequency domains: cpu1 cpu4 cpu7 Offline CPUs: cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 Baseline power usage: 1223 mW ===== CPU 1 ===== Frequencies: 300 403 518 614 691 787 883 979 1075 1171 1248 1344 1420 1516 1612 1708 1804 300: 1114 3.7 C/MHz 29 mW 6.4 J 39.0 I/mJ 224.5 s 403: 1497 3.7 C/MHz 33 mW 5.5 J 45.2 I/mJ 167.0 s 518: 1925 3.7 C/MHz 48 mW 6.3 J 39.7 I/mJ 129.9 s 614: 2281 3.7 C/MHz 73 mW 8.0 J 31.1 I/mJ 109.6 s 691: 2566 3.7 C/MHz 46 mW 4.5 J 55.2 I/mJ 97.4 s 787: 2923 3.7 C/MHz 86 mW 7.4 J 33.8 I/mJ 85.5 s 883: 3279 3.7 C/MHz 77 mW 5.9 J 42.5 I/mJ 76.2 s 979: 3635 3.7 C/MHz 65 mW 4.4 J 56.2 I/mJ 68.8 s 1075: 3992 3.7 C/MHz 71 mW 4.4 J 56.2 I/mJ 62.6 s 1171: 4348 3.7 C/MHz 121 mW 6.9 J 36.0 I/mJ 57.5 s 1248: 4633 3.7 C/MHz 79 mW 4.2 J 58.9 I/mJ 54.0 s 1344: 4990 3.7 C/MHz 81 mW 4.0 J 61.7 I/mJ 50.1 s 1420: 5275 3.7 C/MHz 85 mW 4.0 J 61.8 I/mJ 47.4 s 1516: 5632 3.7 C/MHz 88 mW 3.9 J 64.3 I/mJ 44.4 s 1612: 5988 3.7 C/MHz 92 mW 3.8 J 65.4 I/mJ 41.7 s 1708: 6346 3.7 C/MHz 96 mW 3.8 J 66.3 I/mJ 39.4 s 1804: 6701 3.7 C/MHz 105 mW 3.9 J 63.5 I/mJ 37.3 s ===== CPU 4 ===== Frequencies: 710 825 940 1056 1171 1286 1382 1478 1574 1670 1766 1862 1958 2054 2150 2246 2342 2419 710: 6022 8.5 C/MHz 123 mW 5.1 J 49.1 I/mJ 41.5 s 825: 7001 8.5 C/MHz 142 mW 5.1 J 49.4 I/mJ 35.7 s 940: 7987 8.5 C/MHz 164 mW 5.1 J 48.7 I/mJ 31.3 s 1056: 8954 8.5 C/MHz 185 mW 5.2 J 48.3 I/mJ 27.9 s 1171: 9944 8.5 C/MHz 212 mW 5.3 J 46.9 I/mJ 25.2 s 1286: 10926 8.5 C/MHz 235 mW 5.4 J 46.4 I/mJ 22.9 s 1382: 11735 8.5 C/MHz 253 mW 5.4 J 46.4 I/mJ 21.3 s 1478: 12531 8.5 C/MHz 277 mW 5.5 J 45.2 I/mJ 20.0 s 1574: 13335 8.5 C/MHz 306 mW 5.7 J 43.6 I/mJ 18.8 s 1670: 14169 8.5 C/MHz 335 mW 5.9 J 42.2 I/mJ 17.7 s 1766: 14969 8.5 C/MHz 353 mW 5.9 J 42.3 I/mJ 16.7 s 1862: 15800 8.5 C/MHz 444 mW 7.0 J 35.6 I/mJ 15.8 s 1958: 16630 8.5 C/MHz 463 mW 7.0 J 35.9 I/mJ 15.0 s 2054: 17428 8.5 C/MHz 480 mW 6.9 J 36.3 I/mJ 14.4 s 2150: 18238 8.5 C/MHz 496 mW 6.8 J 36.8 I/mJ 13.7 s 2246: 19053 8.5 C/MHz 578 mW 7.6 J 32.9 I/mJ 13.1 s 2342: 19873 8.5 C/MHz 625 mW 7.9 J 31.8 I/mJ 12.6 s 2419: 20522 8.5 C/MHz 675 mW 8.2 J 30.4 I/mJ 12.2 s ===== CPU 7 ===== Frequencies: 844 960 1075 1190 1305 1401 1516 1632 1747 1862 1977 2073 2169 2265 2361 2457 2553 2649 2745 2841 844: 7172 8.5 C/MHz 155 mW 5.4 J 46.4 I/mJ 34.9 s 960: 8148 8.5 C/MHz 172 mW 5.3 J 47.4 I/mJ 30.7 s 1075: 9116 8.5 C/MHz 197 mW 5.4 J 46.2 I/mJ 27.4 s 1190: 10105 8.5 C/MHz 220 mW 5.4 J 46.0 I/mJ 24.8 s 1305: 11084 8.5 C/MHz 242 mW 5.5 J 45.8 I/mJ 22.6 s 1401: 11888 8.5 C/MHz 262 mW 5.5 J 45.4 I/mJ 21.0 s 1516: 12859 8.5 C/MHz 297 mW 5.8 J 43.2 I/mJ 19.5 s 1632: 13840 8.5 C/MHz 335 mW 6.1 J 41.3 I/mJ 18.1 s 1747: 14827 8.5 C/MHz 369 mW 6.2 J 40.1 I/mJ 16.9 s 1862: 15800 8.5 C/MHz 395 mW 6.3 J 40.0 I/mJ 15.8 s 1977: 16786 8.5 C/MHz 443 mW 6.6 J 37.9 I/mJ 14.9 s 2073: 17566 8.5 C/MHz 488 mW 6.9 J 36.0 I/mJ 14.2 s 2169: 18395 8.5 C/MHz 620 mW 8.4 J 29.7 I/mJ 13.6 s 2265: 19223 8.5 C/MHz 621 mW 8.1 J 30.9 I/mJ 13.0 s 2361: 20040 8.5 C/MHz 672 mW 8.4 J 29.8 I/mJ 12.5 s 2457: 20852 8.5 C/MHz 696 mW 8.3 J 29.9 I/mJ 12.0 s 2553: 21684 8.5 C/MHz 738 mW 8.5 J 29.3 I/mJ 11.5 s 2649: 22458 8.5 C/MHz 793 mW 8.8 J 28.3 I/mJ 11.1 s 2745: 23314 8.5 C/MHz 875 mW 9.4 J 26.6 I/mJ 10.7 s 2841: 24103 8.5 C/MHz 928 mW 9.6 J 26.0 I/mJ 10.4 s [1] https://github.com/kdrag0n/freqbench [2] https://www.eembc.org/coremark/ [3] https://github.com/kdrag0n/freqbench/tree/master/results/sm8250/k30s Signed-off-by: Danny Lin <danny@kdrag0n.dev> Link: https://lore.kernel.org/r/20210112013255.415253-2-danny@kdrag0n.dev Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: qcom: sm8250: Define CPU topologyDanny Lin1-0/+36
sm8250 has a big.LITTLE CPU setup with DynamIQ, so all cores are within the same CPU cluster and LLC (Last-Level Cache) domain. Define this topology to help the scheduler make decisions. Signed-off-by: Danny Lin <danny@kdrag0n.dev> Link: https://lore.kernel.org/r/20210112013255.415253-1-danny@kdrag0n.dev Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: qcom: msm8916-samsung-a2015: Fix sensorsStephan Gerhold1-0/+6
When the BMC150 accelerometer/magnetometer was added to the device tree, the sensors were working without specifying any regulator supplies, likely because the regulators were on by default and then never turned off. For some reason, this is no longer the case for pm8916_l17, which prevents the sensors from working in some cases. Now that the bmc150_accel/bmc150_magn drivers can enable necessary regulators, declare the necessary regulator supplies to make the sensors work again. Fixes: 079f81acf10f ("arm64: dts: qcom: msm8916-samsung-a2015: Add accelerometer/magnetometer") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210111175358.97171-1-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: sdm850: Add OPP tables for 2.84 and 2.96GHzSteev Klimaszewski2-1/+22
Running cpufreq-hw driver on Lenovo Yoga C630 laptop, the following warning messages will be seen. [ 3.415340] cpu cpu4: Voltage update failed freq=2841600 [ 3.418755] cpu cpu4: failed to update OPP for freq=2841600 [ 3.422949] cpu cpu4: Voltage update failed freq=2956800 [ 3.427086] cpu cpu4: failed to update OPP for freq=2956800 This is because the cpufreq-hw lookup table of SDM850 provides these two set-points, but they are missing from OPP table in DT. Let's create sdm850.dtsi to add the OPP for them, so that the warning will be gone. Signed-off-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20210112090640.20062-1-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: sdm845: add oneplus6/6t devicesCaleb Connolly4-0/+667
Add initial support for the OnePlus 6 (enchilada) and 6T (fajita) based on the sdm845-mtp DT with the following functionality: * Touch * Display * GPU * Wlan and Bluetooth * USB peripheral mode * Remoteproc Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Caleb Connolly <caleb@connolly.tech> Link: https://lore.kernel.org/r/20210114203057.64541-2-caleb@connolly.tech Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: defconfig: Enable interconnect for imx8mqMartin Kepplinger1-0/+2
Enable INTERCONNECT_IMX8MQ in order to make interconnect more widely available. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: dts: imx8mq: Add interconnect for lcdifMartin Kepplinger1-0/+3
Add interconnect ports for lcdif to set bus capabilities. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: dts: imx8mq: Add interconnect provider propertyMartin Kepplinger1-0/+1
Add #interconnect-cells on main &noc so that it will probe the interconnect provider. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: dts: imx8mq: Add NOC nodeLeonard Crestez1-0/+24
Add initial support for dynamic frequency scaling of the main NOC on imx8mq. Make DDRC the parent of the NOC (using passive governor) so that the main NOC is automatically scaled together with DDRC by default. Support for proactive scaling via interconnect will come on top. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: syscall: include prototype for EL0 SVC functionsMark Rutland1-0/+1
The kbuild test robot reports that when building with W=1, GCC will warn for a couple of missing prototypes in syscall.c: | arch/arm64/kernel/syscall.c:157:6: warning: no previous prototype for 'do_el0_svc' [-Wmissing-prototypes] | 157 | void do_el0_svc(struct pt_regs *regs) | | ^~~~~~~~~~ | arch/arm64/kernel/syscall.c:164:6: warning: no previous prototype for 'do_el0_svc_compat' [-Wmissing-prototypes] | 164 | void do_el0_svc_compat(struct pt_regs *regs) | | ^~~~~~~~~~~~~~~~~ While this isn't a functional problem, as a general policy we should include the prototype for functions wherever possible to catch any accidental divergence between the prototype and implementation. Here we can easily include <asm/exception.h>, so let's do so. While there are a number of warnings elsewhere and some warnings enabled under W=1 are of questionable benefit, this change helps to make the code more robust as it evolved and reduces the noise somewhat, so it seems worthwhile. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: kernel test robot <lkp@intel.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/202101141046.n8iPO3mw-lkp@intel.com Link: https://lore.kernel.org/r/20210114124812.17754-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-01-15arm64: dts: freescale: sl28: add variant 1Michael Walle2-0/+63
There is a new variant 1 of this board available. It features up to four SerDes lanes for customer use. Add a new device tree which features just the basic peripherals. A customer will then have to modify or append to this device tree. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: dts: qcom: sm8250: correct sdhc_2 xo clkDmitry Baryshkov1-1/+1
sdhc_2 uses 19200000 Hz clock rather than wrongly specified xo_board (39400000 Hz). Specify correct clock to fix DLL setup for SDR104 mode. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: c4cf0300be84 ("arm64: dts: qcom: sm8250: Add support for SDC2") Link: https://lore.kernel.org/r/20210109011252.3436533-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: qcom: qrb5165-rb5: add HDMI audio playbackDmitry Baryshkov1-0/+23
Add support for audio output over the HDMI output using Tertiary I2S and LT9611UXC DSI-to-HDMI bridge. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210115024713.92574-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: qcom: qrb5165-rb5: enable cdsp deviceDmitry Baryshkov1-0/+5
Enable Compute DSP (cdsp) on QRB5165-RB5 platform and provide firmware filename used to boot the cdsp. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210115024156.92265-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15bpf: Rename BPF_XADD and prepare to encode other atomics in .immBrendan Jackman1-4/+12
A subsequent patch will add additional atomic operations. These new operations will use the same opcode field as the existing XADD, with the immediate discriminating different operations. In preparation, rename the instruction mode BPF_ATOMIC and start calling the zero immediate BPF_ADD. This is possible (doesn't break existing valid BPF progs) because the immediate field is currently reserved MBZ and BPF_ADD is zero. All uses are removed from the tree but the BPF_XADD definition is kept around to avoid breaking builds for people including kernel headers. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Björn Töpel <bjorn.topel@gmail.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-5-jackmanb@google.com
2021-01-15numa: Move numa implementation to common codeAtish Patra4-531/+2
ARM64 numa implementation is generic enough that RISC-V can reuse that implementation with very minor cosmetic changes. This will help both ARM64 and RISC-V in terms of maintanace and feature improvement Move the numa implementation code to common directory so that both ISAs can reuse this. This doesn't introduce any function changes for ARM64. Signed-off-by: Atish Patra <atish.patra@wdc.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-15arm64, numa: Change the numa init functions name to be genericAtish Patra4-20/+27
This is a preparatory patch for unifying numa implementation between ARM64 & RISC-V. As the numa implementation will be moved to generic code, rename the arm64 related functions to a generic one. Signed-off-by: Atish Patra <atish.patra@wdc.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14arm64: allow LTO to be selectedSami Tolvanen1-0/+2
Allow CONFIG_LTO_CLANG to be enabled. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-17-samitolvanen@google.com
2021-01-14arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGSSami Tolvanen1-0/+2
DYNAMIC_FTRACE_WITH_REGS uses -fpatchable-function-entry, which makes running recordmcount unnecessary as there are no mcount calls in object files, and __mcount_loc doesn't need to be generated. While there's normally no harm in running recordmcount even when it's not strictly needed, this won't work with LTO as we have LLVM bitcode instead of ELF objects. This change selects FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY, which disables recordmcount when patchable function entries are used instead. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-16-samitolvanen@google.com
2021-01-14arm64: vdso: disable LTOSami Tolvanen1-1/+2
Disable LTO for the vDSO by filtering out CC_FLAGS_LTO, as there's no point in using link-time optimization for the small amount of C code. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-15-samitolvanen@google.com
2021-01-14arm64: dts: ti: k3-j7200-som-p0: Add DDR carveout memory nodes for R5FsSuman Anna1-0/+62
Two carveout reserved memory nodes each have been added for each of the R5F remote processor devices within both the MCU and MAIN domains on the TI J7200 EVM boards. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc device, and the second region will furnish the static carveout regions for the firmware memory. An additional reserved memory node is also added to reserve a portion of the DDR memory to be used for performing inter-processor communication between all the remote processors running RTOS. 8 MB of memory is reserved for this purpose, and this accounts for all the vrings and vring buffers between all the possible pairs of remote processors. The current carveout addresses and sizes are defined statically for each device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables either to allocate the memory for firmware memory segments. NOTE: 1. The R5F1 carveouts are needed only if the R5F cluster is running in Split (non-LockStep) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. 2. The J7200 SoCs have no DSPs and one less R5F cluster compared to J721E SoCs. So, while the carveout memories reserved for the R5F clusters present on the SoC match to those on J721E, the overall memory map reserved for firmwares is quite different. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210111184554.6748-4-s-anna@ti.com
2021-01-14arm64: dts: ti: k3-j7200-som-p0: Add mailboxes to R5FsSuman Anna1-1/+17
Add the required 'mboxes' property to all the R5F processors for the TI J7200 common processor board. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. The nodes are therefore added in the common k3-j7200-som-p0.dtsi file so that all of these can be co-located. The chosen sub-mailboxes match the values used in the current firmware images. This can be changed, if needed, as per the system integration needs after making appropriate changes on the firmware side as well. Note that any R5F Core1 resources are needed and used only when that R5F cluster is configured for Split-mode. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210111184554.6748-3-s-anna@ti.com
2021-01-14arm64: dts: ti: k3-j7200: Add R5F cluster nodesSuman Anna2-2/+82
The J7200 SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS) subsystems/clusters. One R5F cluster is present within the MCU domain (MCU_R5FSS0), and the other one is present within the MAIN domain (MAIN_R5FSS0). Each of these can be configured at boot time to be either run in a LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. These subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - ATCM and BTCM (further interleaved into two banks). The TCMs of both Cores are combined in LockStep-mode to provide a larger 128 KB of memory, but otherwise are functionally similar to those on J721E SoCs. Add the DT nodes for both the MCU and MAIN domain R5F cluster/subsystems, the two R5F cores are added as child nodes to each of the R5F cluster nodes. The clusters are configured to run in LockStep mode by default, with the ATCMs enabled to allow the R5 cores to execute code from DDR with boot-strapping code from ATCM. The inter-processor communication between the main A72 cores and these processors is achieved through shared memory and Mailboxes. The following firmware names are used by default for these cores, and can be overridden in a board dts file if desired: MCU R5FSS0 Core0: j7200-mcu-r5f0_0-fw (both in LockStep and Split modes) MCU R5FSS0 Core1: j7200-mcu-r5f0_1-fw (needed only in Split mode) MAIN R5FSS0 Core0: j7200-main-r5f0_0-fw (both in LockStep & Split modes) MAIN R5FSS0 Core1: j7200-main-r5f0_1-fw (needed only in Split mode) Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210111184554.6748-2-s-anna@ti.com
2021-01-14arm64: dts: allwinner: Pine H64: Enable HS200 eMMC modeAndre Przywara1-0/+1
The eMMC modules offered for the Pine64 boards are capable of the HS200 eMMC speed mode, when observing the frequency limit of 150 MHz. Enable that in the DT. This increases the interface speed from ~80 MB/s to ~120 MB/s. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-9-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: Pine64-LTS/SoPine: Enable HS200 eMMC modeAndre Przywara1-0/+1
The eMMC modules offered for the Pine64 boards are capable of the HS200 eMMC speed mode, when observing the frequency limit of 150 MHz. Enable that in the DT. This increases the interface speed from ~80 MB/s to ~120 MB/s. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-8-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: A64: Limit MMC2 bus frequency to 150 MHzAndre Przywara2-1/+2
In contrast to the H6 (and later) manuals, the A64 datasheet does not specify any limitations in the maximum possible frequency for eMMC controllers. However experimentation has found that a 150 MHz limit similar to other SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist for the MMC2 controller. Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi. The Pinebook seems to be the an odd exception, since it apparently seems to work with 200 MHz as well, so overwrite this in its board .dts file. Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works. Fixes: 22be992faea7 ("arm64: allwinner: a64: Increase the MMC max frequency") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-7-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: H6: Allow up to 150 MHz MMC bus frequencyAndre Przywara1-0/+3
The H6 manual explicitly lists a frequency limit of 150 MHz for the bus frequency of the MMC controllers. So far we had no explicit limits in the DT, which limited eMMC to the spec defined frequencies, or whatever the driver defines (both Linux and FreeBSD use 52 MHz here). Put those maximum frequencies in the SoC .dtsi, to allow higher speed modes (which still would need to be explicitly enabled, per board). Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed 200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably. Fixes: 8f54bd1595b3 ("arm64: allwinner: h6: add device tree nodes for MMC controllers") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-6-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD cardAndre Przywara1-1/+0
The SD card on the SoPine SoM module is somewhat concealed, so was originally defined as "non-removable". However there is a working card-detect pin (tested on two different SoM versions), and in certain SoM base boards it might be actually accessible at runtime. Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the non-removable flag, even though the SD card slot is perfectly accessible and usable there. (It turns out that just *my* board has a broken card detect switch, so I originally thought CD wouldn't work on the LTS.) Drop the "non-removable" flag to describe the SD card slot properly. Fixes: c3904a269891 ("arm64: allwinner: a64: add DTSI file for SoPine SoM") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-5-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: Pine64-LTS: Add status LEDAndre Przywara1-0/+11
The Pine64-LTS board features a blue status LED on pin PL7. Describe it in the DT. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-4-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: H6: properly connect USB PHY to port 0Andre Przywara1-0/+4
In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the H6 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: eabb3d424b6d ("arm64: dts: allwinner: h6: add USB2-related device nodes") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-3-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: A64: properly connect USB PHY to port 0Andre Przywara2-4/+4
In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the A64 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. Remove the part from the Pinebook DTS which already had this property. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: dc03a047df1d ("arm64: allwinner: a64: add EHCI0/OHCI0 nodes to A64 DTSI") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-2-andre.przywara@arm.com
2021-01-14arm64: dts: renesas: r8a779a0: Add SYS-DMAC nodesGeert Uytterhoeven1-0/+58
Add device nodes for the Direct Memory Access Controller for System (SYS-DMAC) instances on the Renesas R-Car V3U (r8a779a0) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210107182045.1948037-1-geert+renesas@glider.be
2021-01-14arm64: dts: renesas: r8a779a0: Add GPIO nodesGeert Uytterhoeven1-0/+140
Add device nodes for the General Purpose Input/Output (GPIO) block on the Renesas R-Car V3U (r8a779a0) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210114111117.2214281-1-geert+renesas@glider.be
2021-01-14KVM: arm64: Use the reg_to_encoding() macro instead of sys_reg()Alexandru Elisei1-10/+7
The reg_to_encoding() macro is a wrapper over sys_reg() and conveniently takes a sys_reg_desc or a sys_reg_params argument and returns the 32 bit register encoding. Use it instead of calling sys_reg() directly. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210106144218.110665-1-alexandru.elisei@arm.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 01:33:50 +0300