summaryrefslogtreecommitdiff
path: root/arch/arm64/boot
AgeCommit message (Collapse)Author
2022-02-25arm64: dts: imx8mp-verdin: swap rx/tx bt audio signalsMarcel Ziswiler
As the PCB of the hardware version V1.1 has this fixed, also swapp RX and TX signals of Bluetooth Audio (WiFi_TX_DATA and WiFi_RX_DATA) in software (not that this is currently used anywhere). While at it also rename bti2sgrp to wifii2sgrp. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-02-25arm64: dts: imx8mp-verdin: fix comment sodimm 151 vs. 153Marcel Ziswiler
Fix comment about SODIMM 151 vs. 153 mixup. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-02-25arm64: dts: imx8mp-verdin: eth_int# shared with tpm_int# (n/a)Marcel Ziswiler
Split ETH_INT# being shared with TPM_INT# (usually N/A) into its own pinctrl node and add a comment in that respect. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-02-25arm64: dts: imx8mp-verdin: non-wifi/wifi specific default iomuxc pinctrlMarcel Ziswiler
In preparation for the PCB of the hardware version V1.1 module make the default iomuxc pinctrl non-WiFi/wifi specific. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-02-25arm64: dts: imx8mp-verdin: remove pmic_tpm_ena et al.Marcel Ziswiler
As on the PCB of the hardware version V1.1 the footprint for an optional SPI TPM (ATTPM20P) got replaced with one for an optional I2C TPM (ST33GTPMII2C) which would not requiring any enable signal, remove PMIC_TPM_ENA et al. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-02-25arm64: dts: imx8mp-verdin: re-order gpio3 and gpio4 nodes.Marcel Ziswiler
Re-order gpio3 and gpio4 nodes. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-02-24arm64: dts: imx8mm-verdin: fix wrong gpio line nameAndrejs Cainikovs
SODIMM_179 should be SODIMM_174. Cosmetic typo, but needs to be fixed to avoid confusion of our customers. Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
2022-02-24arm64: dts: imx8mm-verdin: remove reserved gpio line namesAndrejs Cainikovs
SODIMM_174 and SODIMM_250 gpio lines are used as, respectively, WIFI_W_WKUP_HOST and WIFI_WKUP_WLAN, and hence should be not used for user purposes. Remove these gpio line names from WiFi variant. Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
2022-02-24arm64: dts: imx8mm-verdin: Update IOMUX configurationAndrejs Cainikovs
Update IOMUX configuration as required by the hardware design team. Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
2022-02-23arm64: dts: meson-g12: drop BL32 region from SEI510/SEI610Christian Hewitt
[ Upstream commit f26573e2bc9dfd551a0d5c6971f18cc546543312 ] The BL32/TEE reserved-memory region is now inherited from the common family dtsi (meson-g12-common) so we can drop it from board files. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20220126044954.19069-4-christianshewitt@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23arm64: dts: meson-g12: add ATF BL32 reserved-memory regionChristian Hewitt
[ Upstream commit 08982a1b3aa2611c9c711d24825c9002d28536f4 ] Add an additional reserved memory region for the BL32 trusted firmware present in many devices that boot from Amlogic vendor u-boot. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20220126044954.19069-3-christianshewitt@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23arm64: dts: meson-gx: add ATF BL32 reserved-memory regionChristian Hewitt
[ Upstream commit 76577c9137456febb05b0e17d244113196a98968 ] Add an additional reserved memory region for the BL32 trusted firmware present in many devices that boot from Amlogic vendor u-boot. Suggested-by: Mateusz Krzak <kszaquitto@gmail.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20220126044954.19069-2-christianshewitt@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27arm64: dts: qcom: msm8996: drop not documented adreno propertiesDavid Heidelberg
commit c41910f257a22dc406c60d8826b4a3b5398003a3 upstream. These properties aren't documented nor implemented in the driver. Drop them. Fixes warnings as: $ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/gpu.yaml ... arch/arm64/boot/dts/qcom/msm8996-mtp.dt.yaml: gpu@b00000: 'qcom,gpu-quirk-fault-detect-mask', 'qcom,gpu-quirk-two-pass-use-wfi' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/display/msm/gpu.yaml ... Fixes: 69cc3114ab0f ("arm64: dts: Add Adreno GPU definitions") Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211030100413.28370-1-david@ixit.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27arm64: tegra: Adjust length of CCPLEX cluster MMIO regionThierry Reding
[ Upstream commit 2b14cbd643feea5fc17c6e8bead4e71088c69acd ] The Tegra186 CCPLEX cluster register region is 4 MiB is length, not 4 MiB - 1. This was likely presumed to be the "limit" rather than length. Fix it up. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27arm64: dts: ls1028a-qds: move rtc node to the correct i2c busBiwen Li
[ Upstream commit cbe9d948eadfe352ad45495a7cc5bf20a1b29d90 ] The i2c rtc is on i2c2 bus not i2c1 bus, so fix it in dts. Signed-off-by: Biwen Li <biwen.li@nxp.com> Signed-off-by: Li Yang <leoyang.lil@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27arm64: dts: ti: k3-j721e: Fix the L2 cache setsNishanth Menon
[ Upstream commit e9ba3a5bc6fdc2c796c69fdaf5ed6c9957cf9f9d ] A72's L2 cache[1] on J721e[2] is 1MB. A72's L2 is fixed line length of 64 bytes and 16-way set-associative cache structure. 1MB of L2 / 64 (line length) = 16384 ways 16384 ways / 16 = 1024 sets Fix the l2 cache-sets. [1] https://developer.arm.com/documentation/100095/0003/Level-2-Memory-System/About-the-L2-memory-system [2] http://www.ti.com/lit/pdf/spruil1 Fixes: 2d87061e70de ("arm64: dts: ti: Add Support for J721E SoC") Reported-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211113043639.4413-1-nm@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27arm64: dts: qcom: msm8916: fix MMC controller aliasesDmitry Baryshkov
[ Upstream commit b0293c19d42f6d6951c2fab9a47fed50baf2c14d ] Change sdhcN aliases to mmcN to make them actually work. Currently the board uses non-standard aliases sdhcN, which do not work, resulting in mmc0 and mmc1 hosts randomly changing indices between boots. Fixes: c4da5a561627 ("arm64: dts: qcom: Add msm8916 sdhci configuration nodes") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211201020559.1611890-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27arm64: dts: ti: k3-j721e: correct cache-sets infoPeng Fan
[ Upstream commit 7a0df1f969c14939f60a7f9a6af72adcc314675f ] A72 Cluster has 48KB Icache, 32KB Dcache and 1MB L2 Cache - ICache is 3-way set-associative - Dcache is 2-way set-associative - Line size are 64bytes So correct the cache-sets info. Fixes: 2d87061e70dea ("arm64: dts: ti: Add Support for J721E SoC") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211112063155.3485777-1-peng.fan@oss.nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27arm64: dts: meson-gxbb-wetek: fix missing GPIO bindingChristian Hewitt
[ Upstream commit c019abb2feba3cbbd7cf7178f8e6499c4fa6fced ] The absence of this binding appears to be harmless in Linux but it breaks Ethernet support in mainline u-boot. So add the binding (which is present in all other u-boot supported GXBB device-trees). Fixes: fb72c03e0e32 ("ARM64: dts: meson-gxbb-wetek: add a wetek specific dtsi to cleanup hub and play2") Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20211012052522.30873-3-christianshewitt@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27arm64: dts: meson-gxbb-wetek: fix HDMI in early bootChristian Hewitt
[ Upstream commit 8182a35868db5f053111d5d9d4da8fcb3f99259d ] Mark the VDDIO_AO18 regulator always-on and set hdmi-supply for the hdmi_tx node to ensure HDMI is powered in the early stages of boot. Fixes: fb72c03e0e32 ("ARM64: dts: meson-gxbb-wetek: add a wetek specific dtsi to cleanup hub and play2") Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20211012052522.30873-2-christianshewitt@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-26arm64: dts: apalis-imx8: clean-up sd card dtsDenys Drozdov
Keep +3.3V pull-ups interface by default in imx8-apalis-v1.1.dtsi SD card interface setting per board device tree: imx8-apalis-eval.dtsi +3.3V pull-ups imx8-apalis-ixora-v1.1.dtsi +3.3V pull-ups imx8-apalis-ixora-v1.2.dtsi +1.8V signaling, UHS capable Signed-off-by: Denys Drozdov <denys.drozdov@toradex.com>
2022-01-12Merge remote-tracking branch 'fscl/5.4-2.3.x-imx' into ↵Denys Drozdov
toradex_5.4-2.3.x-imx-v5.4.161 Conflicts: drivers/net/phy/micrel.c drivers/usb/chipidea/core.c
2022-01-11arm64: dts: imx8mm-verdin: Update mcp2518fd maximum SPI clock frequencyRafael Beims
The current verdin imx8mm device tree sets up the maximum SPI clock of the MCP2518FD CAN controller to 2Mhz. After executing tests with real CAN bus traffic, customers noticed significant packet loss (in some cases higher than 30% of packets lost). With more testing, we found out that increasing the SPI clock reduces the packet loss significantly without noticeable negative impact. The tests were performed with 3 different bus rates (256kbps, 512kbps and 1Mbps) and 3 different CAN bus occupation rates (~30%, ~55% and ~100%). To select the SPI clock rate for this change, we considered an errata for the MCP2518FD chip that states that the RAM can be corrupted when written at high SPI clock speeds while there's simultaneous activity on the CAN bus. The listed workaround for this issue is to limit the SPI clock to 0.85 * (SYSCLK/2). On the verdin imx8mm we have the SYSCLK setup in the hardware as 20MHz. This commit changes the SPI clock frequency to 8.5 Mhz so that we get the best performance out of the hardware. With this change we can measure reduced packet loss in several conditions, according to the table (all the tests executed with DLC 1): +-------------+----------------+------------------+--------------------+ | Bus bitrate | Bus occupation | Packet Loss 2Mhz | Packet Loss 8.5Mhz | +-------------+----------------+------------------+--------------------+ | 1Mbps | 57 % | 33.92 % | 0 | +-------------+----------------+------------------+--------------------+ | 500kbps | 57 % | 12.03 % | 0 | +-------------+----------------+------------------+--------------------+ | 1Mbps | 100 % | 31.68 % | 4.1 % | +-------------+----------------+------------------+--------------------+ | 500kbps | 100 % | 32.66 % | 0.2 % | +-------------+----------------+------------------+--------------------+ Signed-off-by: Rafael Beims <rafael.beims@toradex.com>
2022-01-10Merge tag 'v5.4.160' into HEADDenys Drozdov
This is the 5.4.160 stable release
2022-01-10Merge tag 'v5.4.157' into HEADDenys Drozdov
This is the 5.4.157 stable release
2022-01-03arm64: dts: colibri-imx8x: remove unnecessary settings from usdhc2Philippe Schenker
- pinctrl-0 is already defined in imx8x-colibri.dtsi - delete keep-power-in-suspend this flag is not defined in colibri device trees upwards - sd-uhs tags From the commit-message of the introduction of those: --- Provide the option to configure these speed modes per host, for those host drivers that can't distinguish this in runtime. --- Since our host driver obviously can distinguish this (UHS works also without those tags), these tags don't need to be set. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-01-03arm64: dts: imx8x-colibri-iris-v2: iris v2 is 1.8 volt uhs capablePhilippe Schenker
The Iris v2 does NOT have 3.3 volt pull-up resistors on the command- and data-lines of the SD-signals and is therefore fully compatible with all UHS modes. Mark this hardware as being compatible with 1.8 volt signalling by explicitly deleting the no-1-8-v tag. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2022-01-03arm64: dts: imx8x-colibri: mark usdhc2 with no-1-8-vPhilippe Schenker
The original Colibri family module standard never supported switching the SD card interface to 1.8 volt signalling. And as all former carrier boards do have 3.3 volt pull-up resistors on the command- and data-lines of SD-signals this is also not compatible with all UHS modes. Mark this module as not compatible with 1.8 volt signalling with the no-1-8-v tag. Should you be lucky and have a custom carrier board or Iris v2 which does not have such 3.3 volt pull-ups (or you removed yours) one may explicitly delete this property again. While at it also alphabetically re-order them usdhc2 properties. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2021-12-29arm64: dts: allwinner: orangepi-zero-plus: fix PHY modeRobert Marko
[ Upstream commit 08d2061ff9c5319a07bf9ca6bbf11fdec68f704a ] Orange Pi Zero Plus uses a Realtek RTL8211E RGMII Gigabit PHY, but its currently set to plain RGMII mode meaning that it doesn't introduce delays. With this setup, TX packets are completely lost and changing the mode to RGMII-ID so the PHY will add delays internally fixes the issue. Fixes: a7affb13b271 ("arm64: allwinner: H5: Add Xunlong Orange Pi Zero Plus") Acked-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Ron Goossens <rgoossens@gmail.com> Tested-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20211117140222.43692-1-robert.marko@sartura.hr Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-22arm64: dts: rockchip: fix audio-supply for Rock Pi 4Alex Bee
[ Upstream commit 8240e87f16d17a9592c9d67857a3dcdbcb98f10d ] As stated in the schematics [1] and [2] P5 the APIO5 domain is supplied by RK808-D Buck4, which in our case vcc1v8_codec - i.e. a 1.8 V regulator. Currently only white noise comes from the ES8316's output, which - for whatever reason - came up only after the the correct switch from i2s0_8ch_bus to i2s0_2ch_bus for i2s0's pinctrl was done. Fix this by setting the correct regulator for audio-supply. [1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf [2] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi_4c_v12_sch_20200620.pdf Fixes: 1b5715c602fd ("arm64: dts: rockchip: add ROCK Pi 4 DTS support") Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20211027143726.165809-1-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-22arm64: dts: rockchip: fix rk3399-leez-p710 vcc3v3-lan supplyJohn Keeping
[ Upstream commit 2b454a90e2ccdd6e03f88f930036da4df577be76 ] Correct a typo in the vin-supply property. The input supply is always-on, so this mistake doesn't affect whether the supply is actually enabled correctly. Fixes: fc702ed49a86 ("arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC") Signed-off-by: John Keeping <john@metanate.com> Link: https://lore.kernel.org/r/20211102182908.3409670-3-john@metanate.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-22arm64: dts: rockchip: remove mmc-hs400-enhanced-strobe from rk3399-khadas-edgeArtem Lapkin
[ Upstream commit 6dd0053683804427529ef3523f7872f473440a19 ] Remove mmc-hs400-enhanced-strobe from the rk3399-khadas-edge dts to improve compatibility with a wider range of eMMC chips. Before (BJTD4R 29.1 GiB): [ 7.001493] mmc2: CQHCI version 5.10 [ 7.027971] mmc2: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA ....... [ 7.207086] mmc2: mmc_select_hs400es failed, error -110 [ 7.207129] mmc2: error -110 whilst initialising MMC card [ 7.308893] mmc2: mmc_select_hs400es failed, error -110 [ 7.308921] mmc2: error -110 whilst initialising MMC card [ 7.427524] mmc2: mmc_select_hs400es failed, error -110 [ 7.427546] mmc2: error -110 whilst initialising MMC card [ 7.590993] mmc2: mmc_select_hs400es failed, error -110 [ 7.591012] mmc2: error -110 whilst initialising MMC card After: [ 6.960785] mmc2: CQHCI version 5.10 [ 6.984672] mmc2: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA [ 7.175021] mmc2: Command Queue Engine enabled [ 7.175053] mmc2: new HS400 MMC card at address 0001 [ 7.175808] mmcblk2: mmc2:0001 BJTD4R 29.1 GiB [ 7.176033] mmcblk2boot0: mmc2:0001 BJTD4R 4.00 MiB [ 7.176245] mmcblk2boot1: mmc2:0001 BJTD4R 4.00 MiB [ 7.176495] mmcblk2rpmb: mmc2:0001 BJTD4R 4.00 MiB, chardev (242:0) Fixes: c2aacceedc86 ("arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards") Signed-off-by: Artem Lapkin <art@khadas.com> Link: https://lore.kernel.org/r/20211115083321.2627461-1-art@khadas.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-17arm64: dts: apalis-imx8: remove fec regulatorPhilippe Schenker
Despite this being present on the hardware, remove it from the device tree. If this is present then the fec does power-off the regulator when going into suspend. This leads to a non working phy after resume due to the reset line that is not triggered. We try to fix this upstream but this seems to become a bigger task so introduce this intermediate solution of just removing the regulator. According to the KSZ9131 datasheet, the power-consumption in software power-down is about 26mW. Related-to: ELB-4251 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-12-17arm64: dts: apalis-imx8: leave phy-reset in push-pullPhilippe Schenker
In order to prevent backfeeding we have a sleep-state of our pins. Currently the phy-reset is put to open-drain input, High-Z and pull-down. This causes a pull-up on hardware and the configured pull-down to work against each other and causing some strange voltage level. Leave the phy-reset signal configured as push-pull and pull-up as the reset also needs to be high during runtime suspend. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-12-17arm64: dts: apalis-imx8: let phy framework handle resetPhilippe Schenker
It is considered legacy, that the fec resets the phy. Let the phylib handle this reset. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-12-08arm64: dts: mcbin: support 2W SFP modulesRussell King
commit 05abc6a5dec2a8c123a50235ecd1ad8d75ffa7b4 upstream. Allow the SFP cages to be used with 2W SFP modules. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Cc: Christian Lamparter <chunkeey@gmail.com> Cc: 照山周一郎 <teruyama@springboard-inc.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-01arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio functionMarek Behún
commit 715878016984b2617f6c1f177c50039e12e7bd5b upstream. We found out that we are unable to control the PERST# signal via the default pin dedicated to be PERST# pin (GPIO2[3] pin) on A3700 SOC when this pin is in EP_PCIE1_Resetn mode. There is a register in the PCIe register space called PERSTN_GPIO_EN (D0088004[3]), but changing the value of this register does not change the pin output when measuring with voltmeter. We do not know if this is a bug in the SOC, or if it works only when PCIe controller is in a certain state. Commit f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready before training link") says that when this pin changes pinctrl mode from EP_PCIE1_Resetn to GPIO, the PERST# signal is asserted for a brief moment. So currently the situation is that on A3700 boards the PERST# signal is asserted in U-Boot (because the code in U-Boot issues reset via this pin via GPIO mode), and then in Linux by the obscure and undocumented mechanism described by the above mentioned commit. We want to issue PERST# signal in a known way, therefore this patch changes the pcie_reset_pin function from "pcie" to "gpio" and adds the reset-gpios property to the PCIe node in device tree files of EspressoBin and Armada 3720 Dev Board (Turris Mox device tree already has this property and uDPU does not have a PCIe port). Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Remi Pommarel <repk@triplefau.lt> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-26arm64: dts: imx8mp-verdin: limit sdio wi-fi frequency to 100 mhzMarcel Ziswiler
For now, limit the SDIO Wi-Fi frequency to 100 MHz as using 208 (resp. 200) MHz may not work reliably across all modules. Note that the maximum attainable speed will now be somewhere below 250 Mbits/sec. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2021-11-26ARM64: dts: verdin-imx8m(m|p): Add gpio to regulatorPhilippe Schenker
This is needed due to the GPIO also going to the AzureWave module Power Down signal. Change also the regulator-name to reflect for what it is really used. Fixes commit 42de66b9fbfcd7350834c903a98d686ef5a7a7df Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-11-26arm64: dts: freescale: fix arm,sp805 compatible stringMichael Walle
[ Upstream commit 99a7cacc66cae92db40139b57689be2af75fc6b8 ] According to Documentation/devicetree/bindings/watchdog/arm,sp805.yaml the compatible is: compatible = "arm,sp805", "arm,primecell"; The current compatible string doesn't exist at all. Fix it. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residencyAngeloGioacchino Del Regno
[ Upstream commit 3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50 ] The entry/exit latency and minimum residency in state for the idle states of MSM8998 were ..bad: first of all, for all of them the timings were written for CPU sleep but the min-residency-us param was miscalculated (supposedly, while porting this from downstream); Then, the power collapse states are setting PC on both the CPU cluster *and* the L2 cache, which have different timings: in the specific case of L2 the times are higher so these ones should be taken into account instead of the CPU ones. This parameter misconfiguration was not giving particular issues because on MSM8998 there was no CPU scaling at all, so cluster/L2 power collapse was rarely (if ever) hit. When CPU scaling is enabled, though, the wrong timings will produce SoC unstability shown to the user as random, apparently error-less, sudden reboots and/or lockups. This set of parameters are stabilizing the SoC when CPU scaling is ON and when power collapse is frequently hit. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210901183123.1087392-3-angelogioacchino.delregno@somainline.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26arm64: dts: hisilicon: fix arm,sp805 compatible stringMichael Walle
[ Upstream commit 894d4f1f77d0e88f1f81af2e1e37333c1c41b631 ] According to Documentation/devicetree/bindings/watchdog/arm,sp805.yaml the compatible is: compatible = "arm,sp805", "arm,primecell"; The current compatible string doesn't exist at all. Fix it. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26arm64: zynqmp: Fix serial compatible stringMichal Simek
[ Upstream commit 812fa2f0e9d33564bd0131a69750e0d165f4c82a ] Based on commit 65a2c14d4f00 ("dt-bindings: serial: convert Cadence UART bindings to YAML") compatible string should look like differently that's why fix it to be aligned with dt binding. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/89b36e0a6187cc6b05b27a035efdf79173bd4486.1628240307.git.michal.simek@xilinx.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26arm64: zynqmp: Do not duplicate flash partition label propertyAmit Kumar Mahapatra
[ Upstream commit 167721a5909f867f8c18c8e78ea58e705ad9bbd4 ] In kernel 5.4, support has been added for reading MTD devices via the nvmem API. For this the mtd devices are registered as read-only NVMEM providers under sysfs with the same name as the flash partition label property. So if flash partition label property of multiple flash devices are identical then the second mtd device fails to get registered as a NVMEM provider. This patch fixes the issue by having different label property for different flashes. Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/6c4b9b9232b93d9e316a63c086540fd5bf6b8687.1623684253.git.michal.simek@xilinx.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-25ARM64: dts: verdin-imx8mp: dev-board: limit usdhc2 clockPhilippe Schenker
Limit the USDHC2 clock to 100MHz as with certain SDIO cards the clock frequency cannot go higher without being distorted. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-11-25ARM64: dts: verdin-imx8mm: dev-board: limit usdhc2 clockPhilippe Schenker
Limit the USDHC2 clock to 100MHz as with certain SDIO cards the clock frequency cannot go higher without being distorted. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-11-24ARM64: dts: verdin-imx8m(m|p): remove wifi regulatorPhilippe Schenker
In newest hardware revisions we are no longer able to switch the voltage +V3.3_Wi-Fi that powers the AzureWave module. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-11-24ARM64:dts: verdin-imx8m(m|p): do not power off wifiPhilippe Schenker
cap-power-off-card means according to documentation "Powering off the card is safe." which we know from latest investigations is not true. Plus in newest hardware revisions this is also not possible so remove this. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2021-11-17arm64: dts: meson-g12a: Fix the pwm regulator supply propertiesAnand Moon
[ Upstream commit 085675117ecf5e02c4220698fd549024ec64ad2c ] After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VDDCPU pwm regulator to 12V regulator supply instead of dummy regulator. [ 11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property in node /regulator-vddcpu failed [ 11.602344] VDDCPU: supplied by regulator-dummy [ 11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT [ 11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled Fixes: e9bc0765cc12 ("arm64: dts: meson-g12a: enable DVFS on G12A boards") Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210919202918.3556-2-linux.amoon@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-17arm64: dts: rockchip: Fix GPU register width for RK3328Alex Bee
[ Upstream commit 932b4610f55b49f3a158b0db451137bab7ed0e1f ] As can be seen in RK3328's TRM the register range for the GPU is 0xff300000 to 0xff330000. It would (and does in vendor kernel) overlap with the registers of the HEVC encoder (node/driver do not exist yet in upstream kernel). See already existing h265e_mmu node. Fixes: 752fbc0c8da7 ("arm64: dts: rockchip: add rk3328 mali gpu node") Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20210623115926.164861-1-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-25 18:34:07 +0000