summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-30arm64: dts: mediatek: mt8192-asurada: Couple VGPU and VSRAM_OTHER regulatorsAngeloGioacchino Del Regno
Add coupling for these regulators, as VSRAM_OTHER is used to power the GPU SRAM, and they have a strict voltage output relation to satisfy in order to ensure GPU stable operation. While at it, also add voltage constraint overrides for the GPU SRAM regulator "mt6359_vsram_others" so that we stay in a safe range of 0.75-0.80V. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-13-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8192-asurada: Fix voltage constraint for VgpuAngeloGioacchino Del Regno
The MT8192 SoC specifies a maximum voltage for the GPU's digital supply of 0.88V and the GPU OPPs are declaring a maximum voltage of 0.80V. In order to keep the GPU voltage in the safe range, change the maximum voltage for mt6315@7's vbuck1 to 0.80V as sending, for any mistake, 1.193V would be catastrophic. Fixes: 3183cb62b033 ("arm64: dts: mediatek: asurada: Add SPMI regulators") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-12-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8192-asurada: Assign sram supply to MFG1 pdAngeloGioacchino Del Regno
Add a phandle to the MT8192_POWER_DOMAIN_MFG1 power domain and assign the GPU VSRAM supply to this in mt8192-asurada: this allows to keep the sram powered up while the GPU is used. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-11-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8192-asurada: Add MFG0 domain supplyNícolas F. R. A. Prado
The mfg0 power domain encompasses the whole GPU and its surrounding glue logic. This power domain has a separate power rail. Add its power supply for Asurada. Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> [wenst@chromium.org: fix subject prefix and add commit message] Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> [Angelo: Reordered commits to address DVFS stability issues] Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-10-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8192: Add mfg_ref_sel clock to MFG0 domainAngeloGioacchino Del Regno
The mfg_ref_sel clock is a mux used to switch between different "safe" (and slower) clock sources for the GPU: this is used during MFGPLL reconfiguration and eventually during idling at very low frequencies. This clock getting turned off means that the GPU will occasionally be unclocked, producing obvious consequences such as system crash or unpredictable behavior: assigning it to the top level MFG power domain will make sure that this stays on at all times during any operation on the MFG domain (only GPU-related transactions). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-9-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8192: Add GPU nodesAlyssa Rosenzweig
The MediaTek MT8192 includes a Mali-G57 GPU supported in Panfrost. Add the GPU node to the device tree to enable 3D acceleration. The GPU node is disabled by default. It should be enabled by board with its power supplies correctly assigned. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> [nfraprado: removed sram supply, tweaked opp node name, adjusted commit message] Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> [wenst@: disable GPU by default; adjusted prefix; split out board change] Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> [Angelo: cosmetic fixes] Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-8-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8183: Use mediatek,mt8183b-mali as GPU compatibleAngeloGioacchino Del Regno
Use the new GPU related compatible to finally enable GPU DVFS on the MT8183 SoC. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-7-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8183-evb: Couple VGPU and VSRAM_GPU regulatorsAngeloGioacchino Del Regno
Add coupling for these regulators, as they have a strict voltage output relation to satisfy in order to ensure GPU stable operation. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-6-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mt8183-pumpkin: Couple VGPU and VSRAM_GPU regulatorsAngeloGioacchino Del Regno
Add coupling for these regulators, as they have a strict voltage output relation to satisfy in order to ensure GPU stable operation. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-5-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8183: Remove second opp-microvolt entries from gpu tableAngeloGioacchino Del Regno
This was done to keep a strict relation between VSRAM and VGPU, but it never worked: now we're doing it transparently with the new mediatek-regulator-coupler driver. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-4-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8183-kukui: Override vgpu/vsram_gpu constraintsAngeloGioacchino Del Regno
Override the PMIC-default voltage constraints for VGPU and VSRAM_GPU with the platform specific vmin/vmax for the highest possible SoC binning. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-3-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-30arm64: dts: mediatek: mt8183-kukui: Couple VGPU and VSRAM_GPU regulatorsAngeloGioacchino Del Regno
Add coupling for these regulators, as they have a strict voltage output relation to satisfy in order to ensure GPU stable operation. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20230301095523.428461-2-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2023-03-29pinctrl: qcom: Support OUTPUT_ENABLE; deprecate INPUT_ENABLEDouglas Anderson
The Qualcomm pinctrl driver has been violating the documented meaning of PIN_CONFIG_INPUT_ENABLE. That documentation says: Note that this does not affect the pin's ability to drive output. ...yet the Qualcomm driver's sole action when asked to "enable input" on a pin is to disable its output. The Qualcomm driver's implementation stems from the fact that "output-disable" is a "new" property from 2017. It was introduced in commit 425562429d4f ("pinctrl: generic: Add output-enable property"). The "input-enable" handling in Qualcomm drivers is from 2015 introduced in commit 407f5e392f9c ("pinctrl: qcom: handle input-enable pinconf property"). Let's change the Qualcomm driver to move us in the right direction. As part of this: 1. We'll now support PIN_CONFIG_OUTPUT_ENABLE 2. We'll still support using PIN_CONFIG_INPUT_ENABLE to disable a pin's output (in violation of the docs) with a big comment in the code. This is needed because old device trees have "input-enable" in them and, in some cases, people might need the old behavior. While we could programmatically change all old device trees, it doesn't really hurt to keep supporting the old behavior and we're _supposed_ to try to be compatible with old device trees anyway. It can also be noted that the PIN_CONFIG_INPUT_ENABLE handling code seems to have purposefully ignored its argument. That means that old boards that had _either_ "input-disable" or "input-enable" in them would have had the effect of disabling a pin's output. While we could change this behavior, since we're only leaving the PIN_CONFIG_INPUT_ENABLE there for backward compatibility we might as well be fully backward compatible. NOTE: despite the fact that we'll still support PIN_CONFIG_INPUT_ENABLE for _setting_ config, we take it away from msm_config_group_get(). This appears to be only used for populating debugfs and fixing debugfs to "output enabled" where relevant instead of "input enabled" makes more sense and has more truthiness. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230323102605.8.Id740ae6a993f9313b58add6b10f6a92795d510d4@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-03-29dt-bindings: pinctrl: qcom: Add output-enableDouglas Anderson
In the patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable") we allowed setting "output-disable" for TLMM pinctrl states. Let's also add "output-enable". At first blush this seems a needless thing to do. Specifically: - In Linux (and presumably any other OSes using the same device trees) the GPIO/pinctrl driver knows to automatically enable the output when a GPIO is changed to an output. Thus in most cases specifying "output-enable" is superfluous and should be avoided. - If we need to set a pin's default state we already have "output-high" and "output-low" and these properties already imply "output-enabled" (at least on the Linux Qualcomm TLMM driver). However, there is one instance where "output-enable" seems like it could be useful: sleep states. It's not uncommon to want to configure pins as inputs (with appropriate pulls) when the driver controlling them is in a low power state. Then we want the pins back to outputs when the driver wants things running normally. To accomplish this we'd want to be able to use "output-enable". Then the "default" state could have "output-enable" and the "sleep" state could have "output-disable". NOTE: in all instances I'm aware of, we'd only want to use "output-enable" on pins that are configured as "gpio". The Qualcomm documentation that I have access to says that "output-enable" only does something useful when in GPIO mode. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230323102605.7.I7874c00092115c45377c2a06f7f133356956686e@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-03-29dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enableDouglas Anderson
As evidenced by the Qualcomm TLMM Linux driver, the TLMM IP block in Qualcomm SoCs has a bit to enable/disable the output for a pin that's configured as a GPIO but _not_ a bit to enable/disable an input buffer. Current device trees that are specifying "input-enable" for pins managed by TLMM are either doing so needlessly or are using it to mean "output-disable". Presumably the current convention of using "input-enable" to mean "output-disable" stems from the fact that "output-disable" is a "new" property from 2017. It was introduced in commit 425562429d4f ("pinctrl: generic: Add output-enable property"). The "input-enable" handling in Qualcomm drivers is from 2015 introduced in commit 407f5e392f9c ("pinctrl: qcom: handle input-enable pinconf property"). Given that there's no other use for "input-enable" for TLMM, we can still handle old device trees in code, but let's encourage people to move to the proper / documented property by updating the bindings. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230323102605.6.I291ce0ba2c6ea80b341659c4f75a567a76dd7ca6@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-03-28Merge branch 'arm64-fixes-for-6.3' into arm64-for-6.4Bjorn Andersson
Merge the arm64-fixes-for-6.3 branch to avoid merge conflicts with changes for v6.4.
2023-03-28ARM: dts: stm32: add uart nodes and uart aliases on stm32mp135f-dkValentin Caron
Update device-tree stm32mp135f-dk.dts to add usart1, uart8, usart2 and uart aliases. - Usart2 is used to interface a BT device, enable it by default. - Usart1 and uart8 are available on expansion connector. They are kept disabled. So, the pins are kept in analog state to lower power consumption by default or can be used as GPIO. - Uart4 is used for console. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: dts: stm32: add pins for usart2/1/4/8 in stm32mp13-pinctrlValentin Caron
Add pins for uart4, uart8, usart1 and usart2 in stm32mp13-pinctrl.dtsi Theses pins have three states: default, sleep and idle. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: dts: stm32: add uart nodes on stm32mp13Valentin Caron
Update device-tree stm32mp131.dtsi to add some uart features. On uart 1, 2, 3, 5, 6, 7, 8 nodes, add compabible, exti interrupts, clock, reset properties, dma config. On uart 4 node, only add dma configuration and use exti interrupt. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: dts: stm32: clean uart aliases on stm32mp15xx-exx boardsValentin Caron
Remove duplicates and clean uart aliases. Uart aliases and uart pins should be declared and associated to uart instance at the same time. Put also aliases node above chosen node as same as stm32mp157c-dk2.dts. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: dts: stm32: clean uart aliases on stm32mp15xx-dkx boardsValentin Caron
Remove duplicates and clean uart aliases. Uart aliases and uart pins should be declared and associated to uart instance at the same time. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: dts: stm32: fix slew-rate of USART2 on stm32mp15xx-dkxValentin Caron
On stm32mp15xx-dkx boards: - Fix slew-rate of USART 2 to 0 like other USARTs, because frequency of USART pins doesn't exceed 10Mhz. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: stm32: add support for STM32MP151Roan van Dijk
This patch adds initial support of STM32MP151 microprocessor (MPU) based on Arm Cortex-A7. New Cortex-A infrastructure (gic, timer,...) are selected if ARCH_MULTI_V7 is defined. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Roan van Dijk <roan@protonic.nl> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: tegra: transformers: Bind RT5631 sound nodesSvyatoslav Ryhel
TF201, TF300TG and TF700T support RT5631 codec. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2023-03-28ARM: tegra: transformers: Update WM8903 sound nodesSvyatoslav Ryhel
Fix headset detection and use device GPIO microphone detection on WM8903 Transformers. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2023-03-28arm64: dts: apple: t600x: Disable unused PCIe portsJanne Grunau
The PCIe ports are unused (without devices) so disable them instead of removing them. Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28arm64: dts: apple: t8103: Disable unused PCIe portsJanne Grunau
The PCIe ports are unused (without devices) so disable them instead of removing them. Fixes: 7c77ab91b33d ("arm64: dts: apple: Add missing M1 (t8103) devices") Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28arm64: dts: apple: t8112: Initial t8112 (M2) device treesHector Martin
This adds device trees for the following devices: - Macbook Air (M2, 2022) - Macbook Pro 13" (M2, 2022) - Mac mini (M2, 2023) This brings the hardware support of the machines to the same level as M1 and M1 Pro / Max / Ultra. Supported hardware include NVMe, PCIe, serial, pinctrl/gpio, I2C, iommu, watchdog, admac, nco, cpufreq, boot framebuffer for laptop panels and the interrupt controller. The ethernet LAN device on the M2 Mac mini is the only working PCIe device. The Wlan/BT devices are powered off and controlled by the not yet supported SMC. The ASMedia xHCI on the M2 Mac mini requires firmware to be loaded at startup. The main missing hardware support to make these devices useful are the integrated USB 2/3/4 controller, keyboard and trackpad on the laptops and SMC to power the PCIe Wlan/BT device on. The M2 Mac mini has currently no working display output. Due to changes in the display pipeline it is currently not possible to initialize the HDMI output in the bootloader. Co-developed-by: Janne Grunau <j@jannau.net> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: arm: apple: Add t8112 j413/j473/j493 compatiblesJanne Grunau
This adds the following apple,t8112 platforms: - apple,j413 - MacBook Air (M2, 2022) - apple,j473 - Mac mini (M2, 2023) - apple,j493 - MacBook Pro (13-inch, M2, 2022) The sort order logic here is having SoC numeric code families in release order, and SoCs within each family in release order: - t8xxx (Apple HxxP/G series, "phone"/"tablet" chips) - t8103 (Apple H13G/M1) - t8112 (Apple H14G/M2) - t6xxx (Apple HxxJ series, "desktop" chips) - t6000 (Apple H13J(S)/M1 Pro) - t6001 (Apple H13J(C)/M1 Max) - t6002 (Apple H13J(D)/M1 Ultra) Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: clock: apple,nco: Add t8112-nco compatibleJanne Grunau
The block found on Apple's M2 SoC is compatible with the existing driver so add its per-SoC compatible. Acked-by: Martin Povišer <povik+lin@cutebit.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: i2c: apple,i2c: Add apple,t8112-i2c compatibleJanne Grunau
This block on the Apple M2 is compatible with the existing driver so just add the per-SoC compatible. Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: pinctrl: apple,pinctrl: Add apple,t8112-pinctrl compatibleJanne Grunau
This new SoC uses the same pinctrl hardware, so just add a new per-SoC compatible. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: pci: apple,pcie: Add t8112 supportJanne Grunau
The block found in the Apple M2 SoC is compatible with the existing driver, and supports 4 downstream ports like the t6000 one. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: nvme: apple: Add apple,t8112-nvme-ans2 compatible stringJanne Grunau
"apple,t8112-nvme-ans2" as found on Apple M2 SoCs is compatible with the existing driver. Add its SoC specific compatible string to allow special handling if it'll be necessary. t8112 uses only 2 power-domains as no 4 and 8 TB configurations are offered. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: mailbox: apple,mailbox: Add t8112 compatiblesJanne Grunau
The mailbox hardware remains unchanged on M2 SoCs so just add its per-SoC compatible. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: iommu: apple,sart: Add apple,t8112-sart compatible stringJanne Grunau
"apple,t8112-sart" as found on the Apple M2 SoC appears to be SART3 as well. To allow for later discovered incompatibilities use '"apple,t8112-sart", "apple,t6000-sart"' as compatible string. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: interrupt-controller: apple,aic2: Add apple,t8112-aic compatibleJanne Grunau
The Apple M2 SoC uses AICv2 and is compatible with the existing driver. Add its per-SoC compatible. Since multi-die versions of the M2 are not expected decrease '#interrupt-cells' to 3 for apple,t8112-aic. This is seamlessly handled inside the driver. Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: arm: cpus: Add apple,avalanche & blizzard compatiblesJanne Grunau
These are the CPU cores in the Apple silicon M2 SoC. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: watchdog: apple,wdt: Add t8112-wdt compatibleJanne Grunau
The block on the Apple M2 SoC is compatible with the existing driver so add its per-SoC compatible. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: arm: apple: apple,pmgr: Add t8112-pmgr compatibleJanne Grunau
The block on Apple M2 SoCs is compatible with the existing driver so just add its per-SoC compatible. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28dt-bindings: power: apple,pmgr-pwrstate: Add t8112 compatibleHector Martin
Add the apple,t8112-pmgr-pwrstate compatible for the Apple M2 SoC. This goes after t8103. The sort order logic here is having SoC numeric code families in release order, and SoCs within each family in release order: - t8xxx (Apple HxxP/G series, "phone"/"tablet" chips) - t8103 (Apple H13G/M1) - t8112 (Apple H14G/M2) - t6xxx (Apple HxxJ series, "desktop" chips) - t6000 (Apple H13J(S)/M1 Pro) - t6001 (Apple H13J(C)/M1 Max) - t6002 (Apple H13J(D)/M1 Ultra) Note that t600[0-2] share the t6000 compatible where the hardware is 100% compatible, which is usually the case in this highly related set of SoCs. Reviewed-by: Janne Grunau <j@jannau.net> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2023-03-28ARM: dts: stm32: fix spi1 pin assignment on stm32mp15Alexandre Torgue
Bank A and B IOs can't be handled by the pin controller 'Z'. This patch assign spi1 pin definition to the correct controller. Fixes: 9ad65d245b7b ("ARM: dts: stm32: stm32mp15-pinctrl: add spi1-1 pinmux group") Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: dts: stm32: drop invalid simple-panel compatible on stm32mp157c-lxaKrzysztof Kozlowski
"simple-panel" compatible is not documented and nothing in Linux kernel binds to it. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-03-28ARM: dts: omap: Drop ti,omap36xx compatibleAndrew Davis
This was not matched anywhere and provides no additional information. The driver code already checks also for "ti,omap3630" compatible. Signed-off-by: Andrew Davis <afd@ti.com> Message-Id: <20230216153339.19987-2-afd@ti.com> [tony@atomide.com: updated comments for ti,omap3630 compatible] Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-03-28arm64: dts: imx8dxl: drop clocks from scu clock controllerPeng Fan
The clocks and clock-names are not documented and not used, drop them. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-03-28arm64: dts: imx8mp: verdin-yavia: drop disable-over-currentPeng Fan
disable-over-current is for chipidea IP, i.MX8MQ use dwc3, this property is not valid. Drop it. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-03-28arm64: dts: imx8mq: tqma8mq-mba8mx: drop disable-over-currentPeng Fan
disable-over-current is for chipidea IP, i.MX8MQ use dwc3, this property is not valid. Drop it. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-03-27ARM: dts: sunxi: add MangoPi MQ-R-T113 boardAndre Przywara
The MangoPi MQ-R-T113 is a small SBC with the Allwinner T113-s3 SoC. The SoC features two Arm Cortex-A7 cores and 128 MB of co-packaged DDR3 DRAM. The board adds mostly connectors and the required regulators, plus a Realtek RTL8189FTV WiFi chip. Power comes in via a USB-C connector wired as a peripheral, and there is a second USB-C connector usable as a host port. Add a .dtsi file describing most of the board's peripherals, and include that from the actual board .dts file. This allows to re-use the .dtsi for the MQ-R-F113 RISC-V variant of that board. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230320005249.13403-5-andre.przywara@arm.com Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
2023-03-27dt-bindings: arm: sunxi: document MangoPi MQ-R board namesAndre Przywara
The MangoPi MQ-R board is a small development board, using Allwinner SoCs with co-packaged DRAM. There are versions with a RISC-V core and ones with two Arm Cortex-A7 cores. Add the board/SoC compatible string pair to the list of known boards. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230320005249.13403-4-andre.przywara@arm.com Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
2023-03-27ARM: dts: sunxi: add Allwinner T113-s SoC .dtsiAndre Przywara
The Allwinner T113-s SoC is apparently using the same (or at least a very similar) die as the D1/D1s, but replaces the single RISC-V core with two Arm Cortex-A7 cores. Since the D1 core .dtsi already describes all common peripherals, we just need a DT describing the ARM specific peripherals: the CPU cores, the Generic Timer, the GIC and the PMU. We include the core .dtsi directly from the riscv DT directory. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230320005249.13403-3-andre.przywara@arm.com Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
generated by cgit (git 2.34.1) at 2025-09-12 11:00:15 +0000