Following warnings can be observed with CHECK_DTBS=y for the RK3528:
rk3528-pinctrl.dtsi:101.36-105.5: Warning (node_name_chars_strict):
/pinctrl/fephy/fephym0-led_dpx: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:108.38-112.5: Warning (node_name_chars_strict):
/pinctrl/fephy/fephym0-led_link: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:115.36-119.5: Warning (node_name_chars_strict):
/pinctrl/fephy/fephym0-led_spd: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:122.36-126.5: Warning (node_name_chars_strict):
/pinctrl/fephy/fephym1-led_dpx: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:129.38-133.5: Warning (node_name_chars_strict):
/pinctrl/fephy/fephym1-led_link: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:136.36-140.5: Warning (node_name_chars_strict):
/pinctrl/fephy/fephym1-led_spd: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:782.32-790.5: Warning (node_name_chars_strict):
/pinctrl/rgmii/rgmii-rx_bus2: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:793.32-801.5: Warning (node_name_chars_strict):
/pinctrl/rgmii/rgmii-tx_bus2: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:804.36-810.5: Warning (node_name_chars_strict):
/pinctrl/rgmii/rgmii-rgmii_clk: Character '_' not recommended in node name
rk3528-pinctrl.dtsi:813.36-823.5: Warning (node_name_chars_strict):
/pinctrl/rgmii/rgmii-rgmii_bus: Character '_' not recommended in node name
Rename the affected nodes to fix these warnings.
Fixes: a31fad19ae ("arm64: dts: rockchip: Add pinctrl and gpio nodes for RK3528")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250621113859.2146400-1-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The bootloader for RK3588 Tiger currently forces the PMIC reset behavior
(stored in RST_FUN bitfield in register SYS_CFG3 of the PMIC) to 0b1X
which is incorrect for our devices.
It is required to restart the PMU as otherwise the companion
microcontroller cannot detect the PMIC (and by extension the full
product and main SoC) being rebooted which is an issue as that is used
to reset a few things like the PWM beeper and watchdogs.
Let's add the new rockchip,reset-mode property to make sure the PMIC
reset behavior is the expected one.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-5-ce05d041b45f@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The bootloader for RK3588 Jaguar currently forces the PMIC reset
behavior (stored in RST_FUN bitfield in register SYS_CFG3 of the PMIC)
to 0b1X which is incorrect for our devices.
It is required to restart the PMU as otherwise the companion
microcontroller cannot detect the PMIC (and by extension the full
product and main SoC) being rebooted which is an issue as that is used
to reset a few things like the PWM beeper and watchdogs.
Let's add the new rockchip,reset-mode property to make sure the PMIC
reset behavior is the expected one.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-4-ce05d041b45f@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
To make it easier to read the device tree, let's add constants for the
rockchip,reset-mode property values that are currently only applicable
to RK806 PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
[dt-maintainers did not consider this part of the binding, so we're
keeping the header in the devicetree directory]
Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-3-ce05d041b45f@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Much like the Sige5, the ROCK 4D also has an HDMI port, so is capable of
providing HDMI audio output as well.
Enable the SoC's hdmi_sound card, and also enable the SoC audio
controller (sai6) that feeds into it.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-4-0b3c8e8fda9c@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The production version of the ROCK 4D appears to sport a AICSEMI
AIC8800D80 USB Wi-Fi + BT chipset. This chip does not yet have a
mainline driver.
Add the necessary rfkill node and wifi regulator node to at least make
it show up in lsusb output. The regulator is set as always-on, as like 2
hours deep into debugging why onboard_usb_dev.c wouldn't try enabling
the regulator the device needs to actually show up and thus bind to
onboard_usb_dev.c, I decided that it's not worth the effort.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250630-rock4d-reg-usb-wifi-v1-3-1057f412d98c@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The ROCK 4D uses both USB controllers, and both of which in host mode.
However, it still names one of the supplies for them "OTG" in the
schematic.
Fix the "host" supply's input, and add the "otg" supply. Enable the
remaining USB PHY nodes, and the first controller node as well.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250630-rock4d-reg-usb-wifi-v1-2-1057f412d98c@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The ROCK 4D's actual DC input is 5V, and the schematic names it as being
5V as well.
Rename the regulator, and change the voltage it claims to be at.
Furthermore, fix vcc_1v1_nldo_s3's vin-supply as coming from
vcc_5v0_sys, and not the DCIN, as per the schematic. This makes no
functional change; both regulators are always on, and one feeds into the
other.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250630-rock4d-reg-usb-wifi-v1-1-1057f412d98c@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Currently, the common AIA functions kvm_riscv_vcpu_aia_has_interrupts()
and kvm_riscv_aia_wakeon_hgei() lookup HGEI line using an array of VCPU
pointers before accessing HGEI[E|P] CSR which is slow and prone to race
conditions because there is a separate per-hart lock for the VCPU pointer
array and a separate per-VCPU rwlock for IMSIC VS-file (including HGEI
line) used by the VCPU. Due to these race conditions, it is observed
on QEMU RISC-V host that Guest VCPUs sleep in WFI and never wakeup even
with interrupt pending in the IMSIC VS-file because VCPUs were waiting
for HGEI wakeup on the wrong host CPU.
The IMSIC virtualization already keeps track of the HGEI line and the
associated IMSIC VS-file used by each VCPU so move the HGEI[E|P] CSR
access to IMSIC virtualization so that costly HGEI line lookup can be
avoided and likelihood of race-conditions when updating HGEI[E|P] CSR
is also reduced.
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Tested-by: Atish Patra <atishp@rivosinc.com>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: 3385339296 ("RISC-V: KVM: Use IMSIC guest files when available")
Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Link: https://lore.kernel.org/r/20250707035345.17494-3-apatel@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org>
If VS-timer expires when no VCPU running on a host CPU then WFI
executed by such host CPU will be effective NOP resulting in no
power savings. This is as-per RISC-V Privileged specificaiton
which says: "WFI is also required to resume execution for locally
enabled interrupts pending at any privilege level, regardless of
the global interrupt enable at each privilege level."
To address the above issue, vstimecmp CSR must be set to -1UL over
here when VCPU is scheduled-out or exits to user space.
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Tested-by: Atish Patra <atishp@rivosinc.com>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: 8f5cb44b1b ("RISC-V: KVM: Support sstc extension")
Fixes: cea8896bd9 ("RISC-V: KVM: Fix kvm_riscv_vcpu_timer_pending() for Sstc")
Reported-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2112578
Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Link: https://lore.kernel.org/r/20250707035345.17494-2-apatel@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org>
The definition of tegra186_bpmp_ops was not updated in sync with the use
in bpmp.c:
drivers/firmware/tegra/bpmp.c:856:17: error: 'tegra186_bpmp_ops' undeclared here (not in a function); did you mean 'tegra_bpmp_ops'?
856 | .ops = &tegra186_bpmp_ops,
aarch64-linux-ld: drivers/firmware/tegra/bpmp.o:(.rodata+0x2f0): undefined reference to `tegra186_bpmp_ops'
Update the Makefile as needed.
There is really no need to hide the declaration based on the configuration,
so just expose it unconditionally so it never has to be updated again
for the next SoC.
Fixes: 94bce2cf7c ("firmware: tegra: bpmp: Add support on Tegra264")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250711082409.1398497-1-arnd@kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
drm-misc-fixes for v6.16-rc6 or final:
- Fix nouveau fail on debugfs errors.
- Magic 50 ms to fix nouveau suspend.
- Call rust destructor on drm device release.
- Fix DMA api error handling in tegra/nvdec.
- Fix PVR device reset.
- Habanalabs maintainer update.
- Small memory leak fix when nouveau acpi init fails.
- Do not attempt to bind to any PCI device with AGP capability.
- Make FB's acquire handles on backing object, same as i915/xe already does.
- Fix race in drm_gem_handle_create_tail.
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e522cdc7-1787-48f2-97e5-0f94783970ab@linux.intel.com
Move away from the legacy MSI domain setup, switch to use
msi_create_parent_irq_domain().
While doing the conversion, I noticed that hv_compose_msi_msg() is doing
more than it is supposed to (composing message). This function also
allocates and populates struct tran_int_desc, which should be done in
hv_pcie_domain_alloc() instead. It works, but it is not the correct design.
However, I have no hardware to test such change, therefore I leave a TODO
note.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Export irq_domain_free_irqs_top(), making it usable for drivers compiled as
modules.
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Nam Cao <namcao@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The v6.16 driver and DeviceTree updates described and implemented CPU
frequency scaling for the Qualcomm X Elite platform. But the necessary
CPUCP mailbox driver was not enabled, resulting in a series of error
messages being logged during boot (and no CPU frequency scaling).
Enable the missing drivers to silence the errors, and enable CPU
frequency scaling on this platform.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmhv/yAVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fq8QQAJ7O/pDAH1Qy775bmF6ZBpHPN+3D
aEpVBBxv9Pv5UhGdTnaOn8HFvfn19R6UNt0TqK1q6RZou10kzbZQQsBDqThWpajQ
R1aSLqpVOYBbWeg+YAzKNlMt3Lphu0ewSpGCvOReUJMEaQv33HzJCBwvp9W+oMi9
BAfvjoO22S5epSr114eKKrRCJsyDNQz3P2rg0rSKnhDiTs2Le1g+3O459XWzyGc9
dm264CnNszjTnvg9fLSMU9XJifEObNlg2v/iRwWL1B1A802skMJoxTJv2kE4RB+9
G1ZjnLCYphm8taO1RojhW0RCNzOQ40iLXurklxVmO14hNOwRJWrfedxPanaw5R7Y
HqQIH/8mNs+j1eDtWC2zArxkkBwWGyyrzFCHt1WV83PKUJRvbMwobeylB63ecC6w
XUBf3guIyU22i6wS38abxAlGfO7Zo2POxehamf0Oab66TkGmSLukd2KuYsAof6TD
t5B8MiPchJWFQhPbdOcXD7GhTL0OgnwsxQxbo02o6i3C7lWNNqPigSQ7dGKjnoL4
kvZIftEfLXLwU1wFpxtXccdRQr1idHJ3XhyAeIAYiqDl+AkpMRJuwUNLpUFvTbWQ
qDp3YPBlsAMHkj+CxsdA9OdAGanC+fMB/6HKGRnXzcJonbca+G2x9zwuBb0KT/G5
5foLJzNqCFK+vLWf
=eirM
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmhw+FcACgkQmmx57+YA
GNnvhxAAkG6ZWjDHHMnwDjNHwctopaS/3NQhIwfYKRxXxzmPiWAubBLDfoj5+STg
SYkSXG4AK47dPNAYVipDfa6Jjfvq4nlgB68ZPV0vYJ/iwvFXe5fMw7Rkcx3jQ8ok
gszz2MRfsfO+NcbhxcJsq5Y5fafjKa04xFgECz14HPkm9tgivw5DsMeeYkbbU1Ea
vLSjtu+iYY6DtW2An216vZvTc+CfjV50YJtLwhoZY4s/dJ3WnW0ScI/Ecb52Iwog
O/epa8XwHT2ONRhCiaj4K/od5GXj989CBzajaZN5+SlizJ4KYoa2VRdJlrjgVJs9
8JiMYSxLkjqMwrQeZhIGa43sDcKCdlfuhtngn5fxnfUdGWB47kmtSHcU8tSRI99i
IpHyPxM4g+0CzRlJd4Z0ZC3Ket6o465KODIBTrlQ34Er5vbQHW/oaUq4IK3z3D0K
jovnkh4EBNiAASqMD+k+FyLTfv5P6Ieeo8KI/8KRFzUAKV7x96B3d4m36AyGjPvE
ypYbBSz9j1P2hivqe1HgNx1VNAE5i4EUSLrGWuijbBjwC9wNSDne5lPcgJzEvPza
ivwOj14QKweoY+FPinRWjOL/sQuxOqwLw39giV/pbMeinhWUSPeR0HrTWgBJvt0e
eHL+SS4YE79h2tLu981SeZ9cH2Nfv/pY0OBe/6HuQRQh/7FESX4=
=2Ewt
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm Arm64 defconfig fixes for v6.16
The v6.16 driver and DeviceTree updates described and implemented CPU
frequency scaling for the Qualcomm X Elite platform. But the necessary
CPUCP mailbox driver was not enabled, resulting in a series of error
messages being logged during boot (and no CPU frequency scaling).
Enable the missing drivers to silence the errors, and enable CPU
frequency scaling on this platform.
* tag 'qcom-arm64-defconfig-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable Qualcomm CPUCP mailbox driver
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The RTC DeviceTree binding was changed in v6.16, to require an explicit
flag indicating that we store RTC offset in in an UEFI variable.
The result sent X Elite and Lenovo Thinkpad X13s users back to 1970, add
the flag to explicitly select the correct configuration for these
devices.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmhv/igVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FnDoP/i2N80ZY/jhr0GKqnXm9D5bDHRiU
Yt/SdvufrkZ7/Zq5nSSjDw4ZLkFIE54v6tWZpucZSK/cqlVv1UnJ6Wr8QahVxIkj
oZAHaQ/0o4HqkTUbNlI3jOHSz9AriBKzBzu5Oef4Wl5E8SlTxJVU7Bxy5nPABKzN
wrKaN1Rh4ZHogBHEt1Gro6qtDgW85X7Qb+htxztp+0CwnOsjz77nOnZIrcbJccGd
yV0nNIThUAApus0zH+3hBY0VKYr4+ZWYCT60Umtlzt/uwrswgwQSEut1Gj5xAeW4
pDc8fEZusCyUcwGvaoHuYAwjryq/PX/MWnUmvKf41m58ER3iz+WUST9TNiseo0Cw
vdKH9bEE1qrDglNTW+m2rZkDdpdPD2QR1bIstM0X0wZ9wkHKTHqCT0BqznSd8/8Q
135HxdIz/q/xlze3XG6mJkA1/qY2aB7wdRz0ZTCvwwF6QOZJMr0DrbnTTQkphLT7
pYoYFIwO7WLkXqiWMBTYkxstMBlrIU39NuSF/6+xv3r9K0pbt3zdFXjufWh498tN
vBocgPXJ/6+7FO8j5sHZ00PNH0uFKhVcToTYiW1aqIuziKbkiiDdXRG9FzK88rhI
sccFVj/rDFUnEf1SyXkiv7dECuqrmUFVjHodKzX5xdSbOavii3YUoTIURdcUeDL1
yGVQdUjHpNA3zeab
=IYwp
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmhw+E0ACgkQmmx57+YA
GNmqexAAu+Q6Y/BxW6U6dNpVdopu80qgAqSdO1YjlVP2MmrBlpgIc608NesQ9i0T
OejpQK6kkL8ucgByYv/TUhJxIeKLv83y19qmXCMHs7aUHljfXlrQKxJx+PUEshr8
H6QbSL6rkyNp4UIu4h1aVVFuTuoJgQ0Jk5eEkliwXAn5NHu3RYMLzCYdGAbWuWmU
QdKKJbegHhWEMAFD0Z7sCHurzH1nfXWLH55VV918I5pygYkzqlATpP3g+dSd2sZK
1FitznkQMX/4OLFlw9q5d8vrjqF4B40zUrA9/BjNa0oRICOdH3rU6lsQQuVAPxBn
Va7M0oLMnTaB7gVmjPEOGa9Z+9s+vPyLN/bSEc6eOjK12UXRW51zFFGddDxq4qGt
OsQjiqimYg8vEJAdzpfBiBWyhNzYBhz43/0tsNsIXSgQk31WvnLHtFUvRVJuAgjt
5PBO16vPc/rDoKBCi32bM3tEuSpj+kftHy2X0h5yjyfzwnw6KSwkj/bxmRMhx+zp
Fi3Y4HxZk9hHHeCKmwnN+V1fGusZxwTzgF+wRgRBkxyCZ6BOzRRbbMmfT+gyixTu
XZkIcQzVlwad7DcM7ftjVN9MSkrYwXqsjVgffO9Eg717PwzmFdPGM66WWARhgTai
XMgqNXp9UPG4G82fx9wVJ90HiLQYJb2MxcLY/5aF5SE01/a1MC0=
=NURv
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm DeviceTree fixes for v6.16
The RTC DeviceTree binding was changed in v6.16, to require an explicit
flag indicating that we store RTC offset in in an UEFI variable.
The result sent X Elite and Lenovo Thinkpad X13s users back to 1970, add
the flag to explicitly select the correct configuration for these
devices.
* tag 'qcom-arm64-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: x1e80100: describe uefi rtc offset
arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Address concerns in the ASPEED LPC snoop driver identified in the first two
patches of the cleanup series at [1].
[1]: https://lore.kernel.org/all/20250616-aspeed-lpc-snoop-fixes-v2-0-3cdd59c934d3@codeconstruct.com.au/
-----BEGIN PGP SIGNATURE-----
iJIEABYIADoWIQSoUT1x3bOSX/nAa8ajM9GZTrjhpgUCaGyDXRwcYW5kcmV3QGNv
ZGVjb25zdHJ1Y3QuY29tLmF1AAoJEKMz0ZlOuOGmgn8BAPPjymrNsFLeu4rjN8YH
MyLMMQIKDQ7y0mrj5TFrfG38AP0ZJLcwACV2Fl1++uVrI3Ibj73Mtd7C5nIDiAKr
aG1aBQ==
=pX3h
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmhw98gACgkQmmx57+YA
GNnIBA/5AQHJf+UEwDQXyK7h5gWRbchsjBcs2h4K2NfN8KrJZXMyr/Y/eJtmyndJ
SDX/x9kgA+8PT9PdOs87q646KXOSN73j7ixKXd/4EMRoNi4toJuZRlcOOj7Uof9u
Ml/ycVZSEchHQl1umOdTmlbgGw3bq4A6M5Qdes0IUyr6FknugpsaLfP2GinsUdMR
vv7FoEaF86UNv6AkdxYBt+rgA+hRio2ovbaItZhpGrWqU+FMH9Td+H8u8A7HtZbe
Jz8BIqkVv5jTIwFP64MsbvJ2Cd3uN+uxYYtyzAPmgz5XGs2qmOShwnk7ORUiWGk/
OWP8o38OILo3JWYFv0szqPB40VNIyj9yFnLks8382ytwYFdsaMVmDgKCiu8uNwVX
oQMLu+7TnjrCAa8hGXp62kpP8pICjQVcZCYUHzAsfysGzOzpQSg6HfyeBz7/IFIY
SivIM2cY+alQrT5Tf0idGNULKdCuKonzHQvY0+uCTdsn1OUD9J7lrigCzORaXCHR
ePJYB2HH0V83rbvxm8R9azeBTY1w2vmkB8OmiexMjZlEZmgCBlcNY8qWENJvGycv
U7fbTf4o4kBCdhT8JH+u5Gxq3Ucblw0u0Yck5Eb+rpH8ej7gBbNGopZrXe3Qm/R3
/YEXE6vTHenaX8RNnQ/gvgdkPMOHbo7VAH+2mca5PrSB8qhc+zw=
=pKBI
-----END PGP SIGNATURE-----
Merge tag 'aspeed-6.16-fixes-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into arm/fixes
ASPEED SoC driver fixes for 6.16
Address concerns in the ASPEED LPC snoop driver identified in the first two
patches of the cleanup series at [1].
[1]: https://lore.kernel.org/all/20250616-aspeed-lpc-snoop-fixes-v2-0-3cdd59c934d3@codeconstruct.com.au/
* tag 'aspeed-6.16-fixes-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled
soc: aspeed: lpc-snoop: Cleanup resources in stack-order
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Use a safer function strscpy() instead of strcpy() for copying to
arrays.
Only idiomatic code replacement, and no functional changes.
Link: https://patch.msgid.link/20250711083051.18759-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This adds initial support for the Marvell PXA1908 SoC and
"samsung,coreprimevelte", a smartphone using the SoC.
*Important note*: There is a regression on all of the v6.16 RCs where
the board does not boot unrelated to the patches in this set. See:
https://lore.kernel.org/regressions/3367665.aeNJFYEL58@radijator/
USB works and the phone can boot a rootfs from an SD card, but there are
some warnings in the dmesg:
During SMP initialization:
[ 0.006519] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x000000018cba80, CPU1: 0x00000000000000
[ 0.006542] CPU features: Unsupported CPU feature variation detected.
[ 0.006589] CPU1: Booted secondary processor 0x0000000001 [0x410fd032]
[ 0.010710] Detected VIPT I-cache on CPU2
[ 0.010716] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x000000018cba80, CPU2: 0x00000000000000
[ 0.010758] CPU2: Booted secondary processor 0x0000000002 [0x410fd032]
[ 0.014849] Detected VIPT I-cache on CPU3
[ 0.014855] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x000000018cba80, CPU3: 0x00000000000000
[ 0.014895] CPU3: Booted secondary processor 0x0000000003 [0x410fd032]
SMMU probing fails:
[ 0.101798] arm-smmu c0010000.iommu: probing hardware configuration...
[ 0.101809] arm-smmu c0010000.iommu: SMMUv1 with:
[ 0.101816] arm-smmu c0010000.iommu: no translation support!
A 3.14 based Marvell tree is available on GitHub
acorn-marvell/brillo_pxa_kernel, and a Samsung one on GitHub
CoderCharmander/g361f-kernel.
Andreas Färber attempted to upstream support for this SoC in 2017:
https://lore.kernel.org/lkml/20170222022929.10540-1-afaerber@suse.de/
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* newsoc/pxa1908:
MAINTAINERS: add myself as Marvell PXA1908 maintainer
arm64: dts: Add DTS for Marvell PXA1908 and samsung,coreprimevelte
arm64: Kconfig.platforms: Add config for Marvell PXA1908 platform
dt-bindings: marvell: Document PXA1908 SoC and samsung,coreprimevelte
dt-bindings: mmc: sdhci-pxa: restrict pinctrl to pxav1
Add dt bindings for the Marvell PXA1908 SoC and the Samsung Galaxy Core
Prime VE LTE phone (model number SM-G361F) using the SoC.
The SoC comes with 4 Cortex-A53 cores clocked up to ~1.2GHz and a
Vivante GC7000UL GPU. The phone also has a 4.5" 480x800 touchscreen, 8GB
eMMC and 1GB of LPDDR3 RAM.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
Link: https://lore.kernel.org/r/20250708-pxa1908-lkml-v16-2-b4392c484180@dujemihanovic.xyz
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The current pinctrl properties apply only to the pxav1 controller.
Adding one default pinctrl node to a pxav3 controller therefore causes
a schema warning.
Check the existing properties only on pxav1. pxav2 and pxav3 may add
their own set of pinctrl properties if and when needed.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
Link: https://lore.kernel.org/r/20250708-pxa1908-lkml-v16-1-b4392c484180@dujemihanovic.xyz
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
as the in-controller functionality does not work as intended for them.
HDMI drive strength adjustment for better ddc communication and some
missing supplies.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmhtgdgQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgTqNB/98mPmSnPdlondFeI0EPjD/IbhDD2+n5iSV
F7tnX0HtRJJw8PawoPvl/4vI5uYb/y5c8n+bYM1/Nza6Sr7FTqaPtKOVfINrgI8o
BnxceWFAmBnsmilo7eVpvPTnV9l2VBGT0a2lmLSjn+WQpTGQ1CVRyyvx0SWE4ttc
CKAUjPZOX/R2VEZnaSIyEt+b5508hM6BWIBZ3CHK9JxDAJKDg5UggIsHMP6jabak
l9vBaGt7mXQDG0AoRZb2j0ZYnL6Zoa3Y85EhG20dJfEN3B/lDOBCbITR/jUwG4ZU
/olNI+JoiRCzI9Ciux06fwTap4AlpElholnRnFJ7ATV+15jvjqt9
=xycR
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmhw8skACgkQmmx57+YA
GNlWVg//WAjHVAZV9aael3FiBdTwMrrJzZiaUwCzh0+1x5eMeJoUZ4yBS4uzIfe2
S9sdMLgx+0zwkYQYQ2Rs+0hJJZu2+cAivZgyEsJk5e+kjbQ/MNEHPUVXlqpGi3Ps
G7Zxdmxf86dqujSGYX1XJd89bNcZ1a/oCzBQBWa+MT7taQtB+Bt7r2Ujn4rhi6hj
PRRToX7vPEt4fObxN51HERIr2+hmS8Ydeg0/n3HdVfjfmIr09urnBtmJkSJSe3op
jwtCHx7/lxHGM81NDQY1oWfRusMYrqdv4ZqUJEevvw208mOHRbGBIlXHUq7rluko
/e6MgxfA+Lycf2XB7LNo9jx38ykBxL6qmO6PCO1rmZVp4ys/k2/0gc/460aP4w69
7cKs7XlFqH8uVza+UZhcn31yhhUF+B9vWzMeRbCCxsF7ctDCJ5N3WfKwJD/d+Wrv
SU4sYBs3yo5FkeGRvB32uItF6V5dMj676MRmbEj7twnYDUg6VVO0MRIl2jTmXW7I
6jIakryuNmat2pe9+nPuThXNHNb600P+6DQz1tI1+u4a+CErv+dgTkzGdpkv2mni
WQa2Uf0A6fhAqwxvLFsIFoTgMqDiLEMcIzayVfhrfETcbR+JzLkwvuUqs3NyeVXU
iBs9irZx9PAvn7Aaul+e07EIM9Uy3LkCHLk50buRO8Boq7lKQ8A=
=/uVC
-----END PGP SIGNATURE-----
Merge tag 'v6.16-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
Switch to the gpio variant for spi-cs and mmc-detect for some boards
as the in-controller functionality does not work as intended for them.
HDMI drive strength adjustment for better ddc communication and some
missing supplies.
* tag 'v6.16-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: Add missing fan-supply to rk3566-quartz64-a
arm64: dts: rockchip: use cs-gpios for spi1 on ringneck
arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5
arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi 4B
arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi CM5
arm64: dts: rockchip: Adjust the HDMI DDC IO driver strength for rk3588
arm64: dts: rockchip: fix rk3576 pcie1 linux,pci-domain
Link: https://lore.kernel.org/r/5108768.AiC22s8V5E@diego
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Convert the Renesas R-Car GPIO driver from SIMPLE_DEV_PM_OPS() to
DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr(). This lets us drop the
check for CONFIG_PM_SLEEP, and reduces kernel size in case CONFIG_PM or
CONFIG_PM_SLEEP is disabled, while increasing build coverage.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://lore.kernel.org/r/e201140426daacaa799d73e2f76bfd96b6f5718f.1752086619.git.geert+renesas@glider.be
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Downgrade the "msg lost in rx" message to debug level, to prevent
flooding the kernel log with error messages.
Fixes: e0d1f4816f ("can: m_can: add Bosch M_CAN controller support")
Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20250711-mcan_ratelimit-v3-1-7413e8e21b84@geanix.com
[mkl: enhance commit message]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Anders and Naresh found that the addition of the FS_IOC_GETLBMD_CAP
handling in the blockdev ioctl handler breaks all ioctls with
_IOC_NR==2, as the new command is not added to the switch but only
a few of the command bits are check.
Move the check into the blk_get_meta_cap() function itself and make
it return -ENOIOCTLCMD for any unsupported command code, including
those with a smaller size that previously returned -EINVAL.
For consistency this also drops the check for NULL 'arg' that
is really useless, as any invalid pointer should return -EFAULT.
Fixes: 9eb22f7fed ("fs: add ioctl to query metadata and protection info capabilities")
Link: https://lore.kernel.org/all/CA+G9fYvk9HHE5UJ7cdJHTcY6P5JKnp+_e+sdC5U-ZQFTP9_hqQ@mail.gmail.com/
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Anders Roxell <anders.roxell@linaro.org>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/20250711084708.2714436-1-arnd@kernel.org
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
In the buffer write path, iomap_set_range_uptodate() is called every
time iomap_end_write() is called. But if folio_test_uptodate() holds, we
know that all blocks in this folio are already in the uptodate state, so
there is no need to go deep into the critical section of state_lock to
execute bitmap_set().
This is because the folios always creep towards ifs_is_fully_uptodate()
state and once they've gotten there folio_mark_uptodate() is called, which
means the folio is uptodate.
Then once a folio is uptodate, there is no route back to !uptodate without
going through the removal of the folio from the page cache. Therefore, it's
fine to use folio_test_uptodate() to short-circuit unnecessary code paths.
Although state_lock may not have significant lock contention due to
folio lock, this patch at least reduces the number of instructions,
especially the expensive lock-prefixed instructions.
Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com>
Link: https://lore.kernel.org/20250711081207.1782667-1-alexjlzheng@tencent.com
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <brauner@kernel.org>
- Clear LMTT page to avoid leaking data from one VF to another
- Align PF queue size to power of 2
- Disable Indirect Ring State to avoid intermittent issues on context
switch: feature is not currently needed, so can be disabled for now.
- Fix compression handling when the BO pages are very fragmented
- Restore display pm on error path
- Fix runtime pm handling in xe devcoredump
- Fix xe_pm_set_vram_threshold() doc
- Recommend new minor versions of GuC firmware
- Drop some workarounds on VF
- Do not use verbose GuC logging by default: it should be only for
debugging
-----BEGIN PGP SIGNATURE-----
iQJNBAABCgA3FiEE6rM8lpABPHM5FqyDm6KlpjDL6lMFAmhwnQgZHGx1Y2FzLmRl
bWFyY2hpQGludGVsLmNvbQAKCRCboqWmMMvqU3/QD/9TtgEyP+On1K1T8pYBY6I2
RuhAQ5OUs/7H4A0boO/+ZZRCqF8nuEfHy7FqWSYnO1IlRvmFfvjWyMJsJmMCcj2X
t1ZMbrT6DiSAGGxf8F+euRPAKCCRltqLJ2dfGDIBerW1CMFpA5lepNSjrMyGpQ93
R9IfUzW8h8yexW7xGfUjgV2MCs/14oNQW79c5LFjkfVU+8ILHP1a8EZMeWmR310R
NqDfBqvHhKxBQguhbGzIYUOdKTBDr7McZ9A8fZ9nzp4GYIb/j6AbKxlyZgDIgM2b
ahGWeLqqM7PnNvGs0r+vdESuVDkzo9tYw6MfHRHhLGmq+kYSm9w95p9SKsVNtRft
K/w3SXjIS4e0hPpqBEOC5ANfSvValzBwltJDFLd9dG+fPEAarbi2AAYQjnoUf73n
EK4DQ1K44T2kYlf27UQxaXE2LYvO2h6nv1iJ9FvAuaUznP6Za6zeVQqfMyvLaBXg
gpAkvJG5QY6y7II9lRaCMNR8tb6IJwOgdvEynHgKsmwv3iHUfmdqRfTx5Eb1ECe8
rk9J0R4SIuYkhu1qUxJx4qrBX386v3ERiof8fjNitoTi6ITcgBoPiG9QxbmS1L1f
Qhv8HM7ebPQgc8Eyy8dc1ZrknFqGe0/MggQDHmKgMU3t6jisiBWpJ/qJv4gAqwMk
551lBdaKfDKGSrZ8hkUqaA==
=HUb3
-----END PGP SIGNATURE-----
Merge tag 'drm-xe-fixes-2025-07-11' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Driver Changes:
- Clear LMTT page to avoid leaking data from one VF to another
- Align PF queue size to power of 2
- Disable Indirect Ring State to avoid intermittent issues on context
switch: feature is not currently needed, so can be disabled for now.
- Fix compression handling when the BO pages are very fragmented
- Restore display pm on error path
- Fix runtime pm handling in xe devcoredump
- Fix xe_pm_set_vram_threshold() doc
- Recommend new minor versions of GuC firmware
- Drop some workarounds on VF
- Do not use verbose GuC logging by default: it should be only for
debugging
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/s6jyd24mimbzb4vxtgc5vupvbyqplfep2c6eupue7znnlbhuxy@lmvzexfzhrnn
Convert the Renesas R-Car CAN driver from SIMPLE_DEV_PM_OPS() to
DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr(). This lets us drop the
__maybe_unused annotations from its suspend and resume callbacks, and
reduces kernel size in case CONFIG_PM or CONFIG_PM_SLEEP is disabled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/6ffe085f6e2548f53674dd11704b388cf4b303e9.1752086078.git.geert+renesas@glider.be
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
- Keep LDO5 always on for imx8mm-verdin to fix broken Ethernet support
- Add big-endian property back for LS1046A watchdog, as the removal was
an accident
- Fix DMA interrupter number of i.MX95 pcie0_ep device
- A set of changes from Tim Harvey to fix TPM SPI frequency on
imx8mp-venice devices
- A couple of changes from Wei Fang to fix NETC overshoot issue on
i.MX95 EVK boards
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmhszHQACgkQUFdYWoew
fM6P8AgAg+KL/YtgmWxU+/YBJz2wxWxIcWLsn82PuOe61rHfUemOuN2T96576dTh
SbAjv9k3qO/aguTnZ5mWbccmcZ4zoSwGjHHf/Ag1C+V8THEyohYa+408z3GBaMXg
q2H+rJ587lpBU6y+kLlARvqfTII9It7jy8jAojx16gKBM0/FAA52XTEYLUtqcdzS
jcJmqT+2pg8RfIsfHK7PEIZ6uRSixCiOsfd7V5QjRwD18gBhifMGk8n5zB0Yd5H3
vXEATM1Kmldqqc3HkWrLAqucbiYw5cLOCyG9e0KKgspwytZZ3BlBS6PeW2+C/mm+
p19fIEz84EhOM7eOcn3ve7D2gHuCmw==
=VVCu
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmhw2OIACgkQmmx57+YA
GNnaIxAArV8QvDScUPZ1Ju+3iKyWOl46zpW6YtzpHLalZK744MnYIm3fUK+zU12t
wGNtBBSsFMvrtye3D/FpCL0MK0Blkb4c0eQrooO5m26LBQ2ACfKf420ErAZNJxuJ
0sFDSljP4iuiLvkyS/CG4XwG1AbJQz/TqLPHg6JQX7dbspyv9aEMhA1bZba3hbqJ
WhwfpTQzZUlw/dY+Vtg8yDNRPfV+V9RIh2WyC0IOpbaclLXrmgTsWQ9qygyBuxHi
rAOihKSNlPvVCITt4c/TpltiwRbjEwLIPeXj936OYQ51wRzbeNePXcNYG0SmIukG
uAErVA2k8b5SbsNQQ6sAueEc60SW4cHi7q29aj7iOA2BuV8HyLh3Kg6Lo4G5XArM
AlVcagh+GanQZM9UUokLK3R9fmX8wUiP+r2ZUsCnTSlCtI+M1vLJGRGO7mJTSF6/
JvYnqndlmGqM0vHRtzQtw94rTvqDJP0yn4+2Z/Tf88hVA7EzzG8guPjPfX+LBQla
0IK/wR8KdIIZNkgrsnQFbW238n0ogDdy7x30oExfepmQGyu6oKY7Tmr+KBoRP2ds
vmMrfHJz5MKZW9ocwLycV9zcy5maO9TLErqaByG8ZNI5GO0f+4p3OD7lLnpTfs9g
beG3Nz3MLVCqzby5T/q2uP1dC/QFRcs/5pJ+WV3kDDSi8f04ips=
=EUCo
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.16:
- Keep LDO5 always on for imx8mm-verdin to fix broken Ethernet support
- Add big-endian property back for LS1046A watchdog, as the removal was
an accident
- Fix DMA interrupter number of i.MX95 pcie0_ep device
- A set of changes from Tim Harvey to fix TPM SPI frequency on
imx8mp-venice devices
- A couple of changes from Wei Fang to fix NETC overshoot issue on
i.MX95 EVK boards
* tag 'imx-fixes-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on
arm64: dts: imx95: Correct the DMA interrupter number of pcie0_ep
arm64: dts: add big-endian property back into watchdog node
arm64: dts: imx95-15x15-evk: fix the overshoot issue of NETC
arm64: dts: imx95-19x19-evk: fix the overshoot issue of NETC
arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequency
arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequency
arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequency
arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency
Link: https://lore.kernel.org/r/aGzNeZ7KtsRsUkZT@dragon
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The _CRS resources in many cases want to have ResourceSource field
to be a type of ACPI String. This means that to compile properly
we need to enclosure the name path into double quotes. This will
in practice defer the interpretation to a run-time stage, However,
this may be interpreted differently on different OSes and ACPI
interpreter implementations. In particular ACPICA might not correctly
recognize the leading '^' (caret) character and will not resolve
the relative name path properly. On top of that, this piece may be
used in SSDTs which are loaded after the DSDT and on itself may also
not resolve relative name paths outside of their own scopes.
With this all said, fix documentation to use fully-qualified name
paths always to avoid any misinterpretations, which is proven to
work.
Fixes: 8eb5c87a92 ("i2c: add ACPI support for I2C mux ports")
Reported-by: Yevhen Kondrashyn <e.kondrashyn@gmail.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250710170225.961303-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove the gpio hog node which forces using DSI signals rather than
the second LVDS channels signals.
The dsi signals are not used in any of the current device trees.
Leave that decision to the actual device tree which will also define
the consumer of the signals.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The MUX which either outputs DSI or 2nd channel LVDS signals is part of
the SoM. Move the pinmuxing of the GPIO used for controlling the MUX
to the SoM dtsi file.
Fixes: 97dc91c045 ("arm64: dts: freescale: add Toradex SMARC iMX8MP")
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
Fixes: b999bdaf05 ("arm64: dts: imx: Add i.mx8mm Gateworks gw7904 dts support")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
Fixes: a72ba91e5b ("arm64: dts: imx: Add i.mx8mm Gateworks gw7903 dts support")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
Fixes: ef484dfcf6 ("arm64: dts: imx: Add i.mx8mm/imx8mn Gateworks gw7902 dts support")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
Fixes: ef484dfcf6 ("arm64: dts: imx: Add i.mx8mm/imx8mn Gateworks gw7902 dts support")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
