| Age | Commit message (Collapse) | Author |
|---|
|
It appears that exposing the GICv3 EL2 registers through the usual
sysreg interface is not consistent with the way we expose the EL1
registers. The latter are exposed via the GICv3 device interface
instead, and there is no reason why the EL2 registers should get
a different treatement.
Hide the registers from userspace until the GICv3 code grows the
required infrastructure.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250714122634.3334816-3-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
|
|
We always expose a virtual CPU that has EL3 when NV is enabled,
irrespective of EL3 being actually implemented in HW.
Therefore, as per the architecture, RVBAR_EL2 must UNDEF, since
EL2 is not the highest implemented exception level. This is
consistent with RMR_EL2 also triggering an UNDEF.
Adjust the handling of RVBAR_EL2 accordingly.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250714122634.3334816-2-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
|
|
syzkaller has found that it can trip a warning in KVM's exception
emulation infrastructure by repeatedly injecting exceptions into the
guest.
While it's unlikely that a reasonable VMM will do this, further
investigation of the issue reveals that KVM can potentially discard the
"pending" SEA state. While the handling of KVM_GET_VCPU_EVENTS presumes
that userspace-injected SEAs are realized immediately, in reality the
emulated exception entry is deferred until the next call to KVM_RUN.
Hack-a-fix the immediate issues by committing the pending exceptions to
the vCPU's architectural state immediately in KVM_SET_VCPU_EVENTS. This
is no different to the way KVM-injected exceptions are handled in
KVM_RUN where we potentially call __kvm_adjust_pc() before returning to
userspace.
Reported-by: syzbot+4e09b1432de3774b86ae@syzkaller.appspotmail.com
Reported-by: syzbot+1f6f096afda6f4f8f565@syzkaller.appspotmail.com
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
|
|
The regulator-compatible property has never existed in the
regulator/fcs,fan53555.yaml binding, so drop it.
This fixes the following DTB validation warnings:
Unevaluated properties are not allowed
('regulator-compatible' was unexpected)
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-11-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
On nodes with compatible "rockchip,px30-usb2phy-grf", the #address-cells
and #size-cells are required and consequently their child nodes should
have unit addresses. That is not the case for the px30-pmugrf and
px30-grf nodes, so remove them there.
This fixes the following DTB validation warnings:
unnecessary #address-cells/#size-cells without "ranges",
"dma-ranges" or child "reg" property
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-10-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The MIPI DSI connector on the PineTab2 only has 1 port with 1 endpoint,
so drop the unit-address properties.
While at it, move 'rotation' property to its proper sorting position.
This fixes the following DTB validation warnings:
node has a unit name, but no reg or ranges property
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-9-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
According to the DTS coding style [1] referenced nodes should be sorted
alpha-numerically so move mipi_out to be after mipi_in_panel.
[1] https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250709132323.128757-8-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The only thing actually added here is a single endpoint on mipi_out,
which is already defined in rk3399-base.dtsi, so it's simpler to just
reference that phandle, which allows the removal of several properties.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-7-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The only thing actually added here is a single endpoint on edp_out,
which is already defined in rk3399-base.dtsi, so it's simpler to just
reference that phandle, which allows the removal of several properties.
This fixes the following DTB validation warnings:
graph node has single child node 'endpoint@0',
#address-cells/#size-cells are not necessary
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-6-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
When there's only 1 endpoint, there is no need for a unit-address and
removing that allows removing of related properties as well.
This fixes the following DTB validation warnings:
graph node has single child node 'endpoint@0',
#address-cells/#size-cells are not necessary
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-5-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 6.16, take #6
- Fix use of u64_replace_bits() in adjusting the guest's view of
MDCR_EL2.HPMN.
|
|
Breno reports that pNMIs are not behaving the way they should since
they were reworked for GICv5. Turns out we feed the IRQ number to
the pNMI helper instead of the IPI number -- not a good idea.
Fix it by providing the correct number (duh).
Fixes: ba1004f861d16 ("arm64: smp: Support non-SGIs for IPIs")
Reported-by: Breno Leitao <leitao@debian.org>
Suggested-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"There are 18 devicetree fixes for three arm64 plaforms: Qualcomm
Snapdragon, Rockchips and NXP i.MX. These get updated to more
correctly describe the hardware, fixing issues with:
- real-time clock on Snapdragon based laptops
- SD card detection, PCI probing and HDMI/DDC communication on
Rockchips
- ethernet and SPI probing on certain i.MX based boards
- a regression with the i.MX watchdog
Aside from the devicetree fixes, there are two additional fixes for
the merged ASPEED LPC snoop driver that saw some changes in 6.16, and
one additional driver enabled in arm64 defconfig to fix CPU frequency
scaling"
* tag 'soc-fixes-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (21 commits)
arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on
soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled
soc: aspeed: lpc-snoop: Cleanup resources in stack-order
arm64: dts: imx95: Correct the DMA interrupter number of pcie0_ep
arm64: dts: rockchip: Add missing fan-supply to rk3566-quartz64-a
arm64: dts: rockchip: use cs-gpios for spi1 on ringneck
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: rockchip: list all CPU supplies on ArmSoM Sige5
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
arm64: dts: qcom: x1e80100: describe uefi rtc offset
arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset
arm64: defconfig: Enable Qualcomm CPUCP mailbox driver
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
...
|
|
All devices based on the A523/A527/H728/T527 processors contain a G57 MC1 GPU.
Enable the DT nodes for this GPU and specify a regulator that supplies power
to the SoC's VDD_GPU pins. The other parameters are set in the SoC dtsi,
so are board independent.
Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250711035730.17507-4-iuncuim@gmail.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
The Allwinner A523 SoC features the Mali-G57 MC1 GPU, which belongs
to the Mali Valhall (v9) family. There is a power domain specifically
for this GPU that needs to be enabled to utilize it.
To enable in a specific device, we need to enable the gpu node and specify
the “mali-supply” regulator additionally in the device tree.
Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250711035730.17507-3-iuncuim@gmail.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
The A523 SoC family has two power controllers, one based on the existing
PPU, and one newer one based on ARM's PCK-600.
Add device nodes for both of them.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250712074021.805953-6-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm into sunxi/dt-for-6.17
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
Currently we call gcs_free() when releasing task_struct but this is
redundant, it attempts to deallocate any kernel managed userspace GCS
which should no longer be relevant and resets values in the struct we're
in the process of freeing.
By the time arch_release_task_struct() is called the mm will have been
disassociated from the task so the check for a mm in gcs_free() will
always be false, for threads that are exiting leaving the mm active
deactivate_mm() will have been called previously and freed any kernel
managed GCS.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250714-arm64-gcs-release-task-v2-1-8a83cadfc846@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The #address-cells and #size-cells properties are not useful on the DSI
controller node; they are only useful/required on ports and panel(s).
So remove them from the controller node and add them where actually
needed on the various rk3399 based boards.
This fixes the following DTB validation warnings:
unnecessary #address-cells/#size-cells without "ranges",
"dma-ranges" or child "reg" property
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-3-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The #address-cells and #size-cells properties are not useful on the DSI
controller node; they are only useful/required on ports and panel(s).
So remove them from the controller node and add them where actually
needed on the various px30 based boards, which includes rk3326.
This fixes the following DTB validation warnings:
unnecessary #address-cells/#size-cells without "ranges",
"dma-ranges" or child "reg" property
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250709132323.128757-2-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Trying to use UART2 DMA for Bluetooth on ArmSoM Sige1 result in tx
timeout when using dma-names = "tx", "rx" as required by the dt-binding:
Bluetooth: hci0: command 0x0c03 tx timeout
Bluetooth: hci0: BCM: Reset failed (-110)
Change the dmas order to fix UART DMA support on RK3528.
With this fixed Bluetooth can be loaded using DMA on ArmSoM Sige1:
Bluetooth: hci0: BCM: chip id 159
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM4362A2
Bluetooth: hci0: BCM4362A2 (000.017.017) build 0000
Bluetooth: hci0: BCM4362A2 'brcm/BCM4362A2.hcd' Patch
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM43752A2 UART 37.4MHz Ampak AP6398 sLNA iLNA CL1 [Version: 1091.1173]
Bluetooth: hci0: BCM4362A2 (000.017.017) build 1173
Fixes: ab6fcb58aedf ("arm64: dts: rockchip: Add UART DMA support for RK3528")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250709210831.3170458-1-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The NanoPi R5S LTS version has a reset button, which is connected via
GPIO. Note that the non-LTS version does not have the reset button and
therefore on page 19 of the schematic version 2204 it is marked 'NC',
but it is connected on the LTS version.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250711142138.197445-1-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The RTC_HCTOSYS_DEVICE module defaults to rtc0 and should (highly)
preferable be assigned to a battery backed RTC module as it is used to
(re)initialize the system clock.
The R5S and R5C have a connector for a RTC battery which is used by
HYM8563 RTC. Both devices also have another RTC from the rk809 PMIC.
To make sure the HYM8563 is always assigned rtc0, add an alias for it.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250713161723.270963-1-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Instead of having the core code guess the note name for each regset,
use USER_REGSET_NOTE_TYPE() to pick the correct name from elf.h.
This does not affect the correctness of switch(note_type) and similar
code, since note type values known to Linux for coredump purposes were
already required to be unique.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Link: https://lore.kernel.org/r/20250701135616.29630-7-Dave.Martin@arm.com
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
Instead of exposing the arm64-optimized SHA-1 code via arm64-specific
crypto_shash algorithms, instead just implement the sha1_blocks()
library function. This is much simpler, it makes the SHA-1 library
functions be arm64-optimized, and it fixes the longstanding issue where
the arm64-optimized SHA-1 code was disabled by default. SHA-1 still
remains available through crypto_shash, but individual architectures no
longer need to handle it.
Remove support for SHA-1 finalization from assembly code, since the
library does not yet support architecture-specific overrides of the
finalization. (Support for that has been omitted for now, for
simplicity and because usually it isn't performance-critical.)
To match sha1_blocks(), change the type of the nblocks parameter and the
return value of __sha1_ce_transform() from int to size_t. Update the
assembly code accordingly.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20250712232329.818226-9-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Add ov5640 overlay file for imx8qm-mek and imx8qxp-mek board. Camera can
connect different CSI port. So use dts overlay file to handle these
difference connect options.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add the clock-frequency property to the cb_intosc_ls_clk and
cb_intosc_hs_div2_clk device tree nodes.
The f2s_free_clk is implemented by custom logic in the FPGA; so it
should be disabled in the dtsi by default and enabled by a
dts for a specific FPGA design on a specific board.
Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
This addresses this warning:
socfpga_stratix10_swvp.dtb: ethernet@ff800000 (altr,socfpga-stmmac-a10-s10):
'phy-addr' does not match any of the regexes: '^pinctrl-[0-9]+$'
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
The cpu1-start-addr property is only applicable to 32-bit SoCFPGA
platforms.
Removing this property will take care of warnings like this:
socfpga_stratix10_swvp.dtb: sysmgr@ffd12000: cpu1-start-addr:
False schema does not allow 4291846704
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
'altr,modrst-offset' property is not applicable for arm64 SoCFPGA
platforms.
This will fix this dtbs_check warning:
socfpga_stratix10_swvp.dtb:
rstmgr@ffd11000: altr,modrst-offset: False schema does not allow 32
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Add the default "altr,rst-mgr" to the rstmgr node on Stratix10.
This fixes this warning:
arch/arm64/boot/dts/altera:33:10
rstmgr@ffd11000 (altr,stratix10-rst-mgr): compatible: 'oneOf' conditional
failed, one must be fixed:
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
The f2s-free-clk requires a clock-frequency value. We put in an
arbitrary value of 100 MHz for a constant. The true clock frequency
would get generated in an FPGA design and the bootloader will populated
in actual hardware designs.
This fixes warning like this:
arch/arm64/boot/dts/intel:34:8
4 f2s-free-clk (fixed-clock): 'clock-frequency' is a required property
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
The SID controller should be compatible with A64 and others SoC with 0x200
offset.
Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Link: https://patch.msgid.link/20250703151132.2642378-8-iuncuim@gmail.com
[wens@csie.org: Fixed position of SID device node]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
The Liontron H-A133L board features an Ethernet controller with a
JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
Note that the reset pin must be handled as a bus-wide reset GPIO in
order to let the MDIO core properly reset it before trying to read
its identification registers. There's no other device on the MDIO bus.
The datasheet of the PHY mentions that the reset signal must be held
for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
be on the safe side without wasting too much time during boot.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250707165155.581579-5-paulk@sys-base.io
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
The Allwinner A100/A133 Ethernet MAC (EMAC) is compatible with the A64
one and needs access to the syscon register for control of the
top-level integration of the unit.
Note that there are two such controllers on the sun50iw10 die, which are
the same unit with a different top-level syscon register offset.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250707165155.581579-4-paulk@sys-base.io
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
The Allwinner A100/A133 supports both RGMII and RMII for its Ethernet
MAC (EMAC) controller. Add corresponding pin definitions.
Note that the sun50iw10 die actually includes two ethernet controllers,
the second of which is rarely exposed to pins. Call the first controller
"emac0" to distinguish it from the second that may be added later.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250707165155.581579-3-paulk@sys-base.io
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
|
|
The P3971-0089+P3834-0008 is an engineering reference platform for the
Tegra264 SoC.
Link: https://lore.kernel.org/r/20250709231401.3767130-3-thierry.reding@gmail.com
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Link: https://lore.kernel.org/r/20250709231401.3767130-4-thierry.reding@gmail.com
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add basic support for the Tegra264 SoC, sufficient for booting into an
initial ramdisk.
Link: https://lore.kernel.org/r/20250709231401.3767130-2-thierry.reding@gmail.com
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add the description of the front/user camera (OV8858) on the PinePhone Pro
to the device dts file.
It receives commands over SCCB, an I2C-compatible protocol, at
I2C address 0x36 and transmits data over CSI-MIPI.
I confirmed this address experimentally.
The pin control mapping was again extracted from the PinePhone Pro
schematic v1.0 as well as the RK3399 datasheet revision 1.8.
Table 2-3 in section 2.8 of the RK3399 datasheet contains the mapping
of IO functions for the SoC pins. Page 52 shows GPIO1_A4, page 54 shows
GPIO2_B4.
For the reset (RESET) signal:
page 11 quadrant D2 | p.18 q.B3-4 | p.18 q.C2
RK3399_E.R28 -> GPIO1_A4 -> Camera2_RST -> MIPI_RST1 -> OV8858.12
For the powerdown (PWDN) signal:
page 9 quadrants D4-5 | p.18 q.B2
RK3399_L.F31 -> GPIO2_B4 -> DVP_PDN0_H -> OV8858.14
Helped-by: Dragan Simic <dsimic@manjaro.org>
Co-developed-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Olivier Benjamin <olivier.benjamin@bootlin.com>
Link: https://lore.kernel.org/r/20250620-camera-v4-4-0201a8ed5fae@bootlin.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
PinePhone Pro
Add the description of the rear/world camera (IMX258) on the PinePhone Pro
to the device dts file.
It receives commands on the I2C Bus 1 at address 0x1a and transmits data
over CSI-MIPI.
The I2C address for IMX258 can be found in the IMX258-0AQH5 Software
Reference Manual, page 24, section 2.3.1: 0b0011010 = 0x1a.
Section 3 indicates the module has 4 pairs of data lines. While 4-lane
mode is nominal, 2-lane mode should also be supported.
The pin muxing info was extracted from the PinePhone Pro schematic v1.0
as well as the RK3399 datasheet revision 1.8.
Table 2-3 in section 2.8 of the RK3399 datasheet contains the mapping
of IO functions for the SoC pins. Page 52 shows GPIO1_A0, page 54 shows
GPIO2_D4.
For I2C power, the PinePhone Pro schematic page 11 quadrants A4 and A5:
RK3399_J.AA8 and RK3399_J.Y8 get power from vcaa1v8_codec, so turn it on
The IMX258 also uses the following regulators, expected by its driver:
- vana (2.8V analog), called AVDD2V8_DVP on P.18 q.C1 and derived from
VCC1V8_S3 on P.13 q.B2
- vdig (1.2V digital core), called DVDD_DVP on P.18 q.C1 and shown on
P.18 q.D3 to be equivalent to VCC1V2_DVP derived from VCC3V3_SYS on
P.13 q.B3. Note that this regulator's voltage is inconsistently
labeled either 1.2V or 1.5V
RK3399_J.AG1 is GPIO4_A1/I2C1_SDA, RK3399_J.Y6 is GPIO4_A2/I2C1_SCL
This is the default pinctrl "i2c1_xfer" for i2c1 from rk3399-base.
For the reset (RESET) signal:
page 11 quadrant D2 | p.18 q.C3-4 | p.18 q.C2
RK3399_E.R25 -> GPIO1_A0 -> Camera_RST -> MIPI_RST0 -> IMX258.12
For the powerdown (PWDN) signal:
page 11 quadrants B4-5 | p.18 q.C2
RK3399_G.AF8 -> GPIO2_D4 -> DVP_PDN1_H -> IMX258.14
Helped-by: Dragan Simic <dsimic@manjaro.org>
Co-developed-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Olivier Benjamin <olivier.benjamin@bootlin.com>
Link: https://lore.kernel.org/r/20250620-camera-v4-3-0201a8ed5fae@bootlin.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
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: a31fad19ae39 ("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>
|
|
Add device tree for FriendlyElec NanoPi M5 with Rockchip RK3576 SoC
(4x Cortex-A72, 4x Cortex-A53, Mali-G52 MC3 GPU, 6 TOPS NPU). Enables
basic booting and connectivity.
Supported features:
- RK3576 SoC
- 4GB LPDDR4X or 8GB/16GB LPDDR5
- 16MB SPI Nor Flash
- 2x 1Gbps Ethernet
- 2x USB 3.2 Gen 1 Type-A ports
- M.2 M-Key PCIe 2.1 x1 NVMe support
- M.2 E-Key SDIO connector
- microSD UHS-I
- HDMI 1.4/2.0 (up to 4096x2304@60Hz)
- 30-pin GPIO (2x SPI, 4x UART, 3x I2C, 5x PWM, 20x GPIO)
- Debug UART
- RTC with HYM8563TS
- Power via USB-C (PD, 6V~20V)
Signed-off-by: John Clark <inindev@gmail.com>
Link: https://lore.kernel.org/r/20250628143229.74460-3-inindev@gmail.com
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>
|
