ETHERNET2 instance is connected to Realtek PHY in RGMII mode
Ethernet is SNSP IP with GMAC5 version.
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Add pinctrl entry related to ETH2 in stm32mp25-pinctrl.dtsi
ethernet2: RGMII with crystal.
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Both instances ethernet based on GMAC SNPS IP on stm32mp25.
GMAC IP version is SNPS 5.3
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The High Performance Direct Memory Access (HPDMA) controller is used to
perform programmable data transfers between memory-mapped peripherals
and memories (or between memories) via linked-lists.
There are 3 instances of HPDMA on stm32mp251, using stm32-dma3 driver, with
16 channels per instance and with one interrupt per channel.
Channels 0 to 7 are implemented with a FIFO of 8 bytes.
Channels 8 to 11 are implemented with a FIFO of 32 bytes.
Channels 12 to 15 are implemented with a FIFO of 128 bytes.
Thanks to stm32-dma3 bindings, the user can ask for a channel with specific
FIFO size.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Fixed the PHY address and reset GPIOs (does not match the corresponding
pinctrl) for gmac0 and gmac1.
Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20240630150010.55729-7-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The R66S and R68S boards do not have HDMI output, so disable
the display subsystem.
Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20240701143028.1203997-3-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Fix the following error when booting:
[ 15.851853] platform fd800000.usb: deferred probe pending
[ 15.852384] platform fd840000.usb: deferred probe pending
[ 15.852881] platform fd880000.usb: deferred probe pending
This is due to usb2phy1 is not enabled. There is no USB 2.0
port on the board, just remove it.
Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20240630150010.55729-5-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Fixes pmu_io_domains supply according to the schematic. Among them,
the vccio3 is responsible for the io voltage of sdcard. There is no
sdcard slot on the R68S, and it's connected to vcc_3v3, so describe
the supply of vccio3 separately.
Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S")
Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20240630150010.55729-4-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Remove the non-existent usb_host regulator and fix the supply according
to the schematic. Also remove the unnecessary always-on and boot-on for
the usb_otg regulator.
Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20240701143028.1203997-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Make the regulator name the same as those marked by schematics.
Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20240630150010.55729-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
There have been several attempts to set the dma-names property on the
SoC level (in rk356x.dtsi), but that appears to cause problems when set
on channels without flow control.
Quoting part of a previous attempt for clarification:
> Nah, enabling it for bluetooth is fine because you have flow control.
> My issues have been on channels without flow control. Without DMA it
> simply drops messages or the channel hangs until you close and reopen
> it. With DMA, when an overflow locks up the channel it is usually
> unavailable until the board is rebooted.
Setting it on the board level for the bluetooth connection was deemed
safe, so do so for the Quartz64 Model B.
This fixes the following error/warning:
of_dma_request_slave_channel: dma-names property of node
'/serial@fe650000' missing or empty
dw-apb-uart fe650000.serial: failed to request DMA
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://libera.irclog.whitequark.org/armlinux/2024-02-29
Link: https://lore.kernel.org/linux-rockchip/18284546.sWSEgdgrri@diego/
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240628120130.24076-1-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add support for voltage ranges to the GPU OPPs defined in the SoC dtsi for
Rockchip RK356x. This is, for example, useful for RK356x-based boards that
are designed to use the same power supply for the GPU and NPU portions of
the SoC, which is described further in the following documents:
- Rockchip RK3566 Hardware Design Guide, version 1.1.0, page 37
- Rockchip RK3568 Hardware Design Guide, version 1.2, page 78
The values for the exact GPU OPP voltages and the lower limits for the GPU
OPP voltage ranges differ from the values found in the vendor kernel source
(cf. downstream commit f8b9431ee38e ("arm64: dts: rockchip: rk3568: support
adjust opp-table by otp")), [1][2] and present the exact GPU OPP voltage
values that have served us well so far.
[1] f8b9431ee3
[2] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
Suggested-by: Diederik de Haas <didi.debian@cknow.org>
Helped-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/7e9ba70fd54a21d6f1f267df11e0acabff8d24e0.1719763100.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The rtl82xx DT bindings do not require ethernet-phy-ieee802.3-c22
as the fallback compatible string. There are fewer users of the
Realtek PHY compatible string with fallback compatible string than
there are users without fallback compatible string, so drop the
fallback compatible string from the few remaining users:
$ git grep -ho ethernet-phy-id001c....... | sort | uniq -c
1 ethernet-phy-id001c.c816",
2 ethernet-phy-id001c.c915",
2 ethernet-phy-id001c.c915";
5 ethernet-phy-id001c.c916",
13 ethernet-phy-id001c.c916";
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202406290316.YvZdvLxu-lkp@intel.com/
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240630034910.173552-2-marex@denx.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The iommu@fe043e00 on RK356x SoC shares the VOP power domain, but the
power-domains property was not provided when the node has been added.
The consequence is that an attempt to reload the rockchipdrm module will
freeze the entire system. That is because on probe time,
pm_runtime_get_suppliers() gets called for vop@fe040000, which blocks
when pm_runtime_get_sync() is being invoked for iommu@fe043e00.
Fix the issue by adding the missing property.
Fixes: 9d6c6d978f97 ("arm64: dts: rockchip: rk356x: Add VOP2 nodes")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240702-rk356x-fix-vop-mmu-v1-1-a66d1a0c45ea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
For varying privacy and security reasons, sometimes we would like to
completely silence the _serial_ console, and only enable it when needed.
But there are many existing systems that depend on this _serial_ console,
so add acpi=nospcr to disable console in ACPI SPCR table as default
_serial_ console.
Signed-off-by: Liu Wei <liuwei09@cestc.cn>
Suggested-by: Prarit Bhargava <prarit@redhat.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Prarit Bhargava <prarit@redhat.com>
Link: https://lore.kernel.org/r/20240625030504.58025-1-liuwei09@cestc.cn
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Declare that the host controller supports ATS, so the OS can enable it
for ATS-capable PCIe endpoints.
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20240607105415.2501934-5-jean-philippe@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>
This replaces custom macros usage (i.e ID_AA64PFR0_EL1_ELx_64BIT_ONLY and
ID_AA64PFR0_EL1_ELx_32BIT_64BIT) and instead directly uses register fields
from ID_AA64PFR0_EL1 sysreg definition. Finally let's drop off both these
custom macros as they are now redundant.
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20240613102710.3295108-3-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Although we now have support for nXS-flavoured TLBI instructions,
we still don't expose the feature to the guest thanks to a mixture
of misleading comment and use of a bunch of magic values.
Fix the comment and correctly express the masking of LS64, which
is enough to expose nXS to the world. Not that anyone cares...
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20240703154743.824824-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Reserve 576MiB of CMA as global CMA pool starting after initial 1GiB of
DDR.
AM62ax has different multimedia components such as Camera, Display, H.264
VPU and JPEG Encoder which use CMA for buffer allocations.
The 12x 720x480 realtime VPU decode use-case requires 544MiB of CMA,
additional 32MiB is kept as buffer in case some other peripheral also
require it while VPU is running.
The reason to choose latter 1GiB is to not overlap with existing memory map
which is utilizing initial 1GiB for remoteproc firmwares as shared here
[1].
Also some drivers such as JPEG require 32bit addressing so not allocating
from higher DDR address.
Link: https://lore.kernel.org/all/20240605124859.3034-5-hnagalla@ti.com [1]
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Tested-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Randolph Sapp <rs@ti.com>
Link: https://lore.kernel.org/r/20240613150902.2173582-3-devarsht@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reserve 128MiB of global CMA which is also marked as re-usable
so that OS can also use the same if peripheral drivers are not using the
same.
AM62x supports multimedia components such as GPU, dual Display and Camera.
Assuming the worst-case scenario where all 3 are run in parallel below
is the calculation :
1) OV5640 camera sensor supports 1920x1080 resolution
-> 1920 width x 1080 height x 2 bytesperpixel x 8 buffers
(default in yavta) : 32MiB
2) 1920x1200 Microtips LVDS panel supported
-> 1920 width x 1080 height x 4 bytesperpixel x 2 buffers :
16 MiB
3) 1920x1080 HDMI display supported
-> 1920 width x 1080 height x 4 bytesperpixel x 2 buffers :
15.82 MiB which is ~16 MiB
4) IMG GPU shares with display allocated buffers while rendering
but in case some dedicated operation viz color conversion,
keeping same window of ~16 MiB for GPU too.
Total is 80 MiB and adding 32 MiB for other peripherals and extra
16 MiB to keep as buffer for fragmentation thus rounding total to 128
MiB.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Randolph Sapp <rs@ti.com>
Link: https://lore.kernel.org/r/20240613150902.2173582-2-devarsht@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The arm64 asm/arm_pmuv3.h depends on defines from
linux/perf/arm_pmuv3.h. Rather than depend on include order, follow the
usual pattern of "linux" headers including "asm" headers of the same
name.
With this change, the include of linux/kvm_host.h is problematic due to
circular includes:
In file included from ../arch/arm64/include/asm/arm_pmuv3.h:9,
from ../include/linux/perf/arm_pmuv3.h:312,
from ../include/kvm/arm_pmu.h:11,
from ../arch/arm64/include/asm/kvm_host.h:38,
from ../arch/arm64/mm/init.c:41:
../include/linux/kvm_host.h:383:30: error: field 'arch' has incomplete type
Switching to asm/kvm_host.h solves the issue.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-5-c9784b4f4065@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Replace the fixed regulator for USB VBUS and use the proper one that
controls regulator based on VBUS detection.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20240702180032.207275-5-biju.das.jz@bp.renesas.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
ASUS Vivobook S 15 is a laptop based on the Qualcomm Snapdragon X Elite
SoC (X1E78100).
Add the device tree for the laptop with support for the following features:
- CPU frequency scaling up to 3.4GHz
- NVMe storage on PCIe 6a (capable of Gen4x4, currently limited to Gen4x2)
- Keyboard and touchpad
- WCN7850 Wi-Fi
- Two Type-C ports on the left side (USB3 only in one orientation)
- internal eDP display
- ADSP and CDSP remoteprocs
Further details could be found in the cover letter.
Signed-off-by: Xilin Wu <wuxilin123@gmail.com>
Link: https://lore.kernel.org/r/20240701-asus-vivobook-s15-v4-2-ce7933b4d4e5@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
According to downstream sources, maximum current for PMI632 VBUS
is 1A.
Taken from msm-4.19 (631561973a034e46ccacd0e53ef65d13a40d87a4)
Line 685-687 in drivers/power/supply/qcom/qpnp-smb5.c
Fixes: a06a2f12f9e2 ("arm64: dts: qcom: qrb4210-rb2: enable USB-C port handling")
Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: Dang Huynh <danct12@riseup.net>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240702-qrd4210rb2-vbus-volt-v3-1-fbd24661eec4@riseup.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Now that the venus clocks are fixed, we can add the DT node.
Signed-off-by: Pierre-Hugues Husson <phhusson@freebox.fr>
Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Acked-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Link: https://lore.kernel.org/r/6d86a6a3-4d99-4fda-9a38-7688587237e6@freebox.fr
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
According to nxp,dwmac-imx.yaml, 'snps,rx-sched-sp' is not a valid
property.
Remove it from the imx8mp board devicetree files to avoid
dt-schema warnings:
... 'snps,tx-sched-sp' does not match any of the regexes
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Revision 3 of the sa8775p-ride board uses a different PHY for the two
ethernet ports and supports 2.5G speed. Create a new file for the board
reflecting the changes.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240627114212.25400-4-brgl@bgdev.pl
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
In order to support multiple revisions of the sa8775p-ride board, create
a .dtsi containing the common parts and split out the ethernet bits into
the actual board file as they will change in revision 3.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20240627114212.25400-3-brgl@bgdev.pl
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add appropriate mappings of Soundwire ports of WSA8845 speaker. This
solves second (south) speaker sound distortions when playing audio.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240627122015.30945-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add appropriate mappings of Soundwire ports of WSA8845 speaker. This
solves second (right) speaker sound distortions when playing audio.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240627122015.30945-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add appropriate mappings of Soundwire ports of WSA8845 speaker. This
solves second (south) speaker sound distortions when playing audio.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240627122015.30945-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add appropriate mappings of Soundwire ports of WSA8845 speaker
to correctly map the Speaker ports to the WSA macro ports.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240627-topic-sm8650-upstream-was-port-mapping-v1-3-4700bcc2489a@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add appropriate mappings of Soundwire ports of WSA8845 speaker
to correctly map the Speaker ports to the WSA macro ports.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240627-topic-sm8650-upstream-was-port-mapping-v1-2-4700bcc2489a@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add appropriate mappings of Soundwire ports of WSA8845 speaker
to correctly map the Speaker ports to the WSA macro ports.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240627-topic-sm8650-upstream-was-port-mapping-v1-1-4700bcc2489a@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Without explicitly specifying names for the regulators they are named
based on the DeviceTree node name. This results in multiple regulators
with the same name, making debug prints and regulator_summary impossible
to reason about.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240627-fp4-regulator-name-v1-1-66931111a006@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Correct the name for the thermal zone on PM8916 PMIC. I ended up with
c&p mistake, which wasn't noticed until the patch got merged.
Reported-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Fixes: b7a28d8a7b80 ("arm64: dts: qcom: pm8916: add temp-alarm thermal zone")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240701-fix-pm8916-tz-v1-1-02f8a713f577@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the necessary dt nodes for gpu support in X1E80100.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240629015111.264564-6-quic_akhilpo@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
According to the power grid documentation, the 0.8v HS PHY shared
regulator is actually LDO3 from PM8550ve id J. Fix both CRD and QCP
boards.
Fixes: d7e03cce0400 ("arm64: dts: qcom: x1e80100-crd: Enable more support")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240629-x1e80100-dts-fix-hsphy-0-8v-supplies-v1-1-de99ee030b27@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
A number of devicetree fixes came in for the rockchip platforms, correcting
some of the address information, and reverting a change to the MMC controller
configuration that caused regressions.
Four drivers have one code change each, addressing minor build issues for
the optee firmware driver, the litex SoC platform driver and two reset
drivers.
The riscv fixes as also simple, mainly turning off device nodes in the
canaan dts files unless they are actually usable on a particular board.
Finally, Drew takes over maintaining the THEAD RISC-V SoC platform.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmaCpVIACgkQYKtH/8kJ
UieIfQ/+KtxzYPfLsUgSZJCeKa6d1A9EgtTBtcEn6gI4HAc5NFDGvYIIetWI/RYN
2+zOLRdQ8t3CIi2c1sTqy1m+j5vX94p4/2WSW41zASHxN+ryz8VM2SKzE5TGV8IE
WyHv5fBIHY97u2zegq8K4c/ze2W7bdwBd1V5tYwk7tZnm6VFNMCESQ+Q4mu7kjdy
irCdxr0j+uDO0cGppwuGWSSR+BiCCCDhu9YjmluD9B57IIB95lyQRgdGy/V9cT9D
yJS6VwEi+EFBNbzt7TzNrPiXvymQzDeC5K7JavfSRRxW1a/rWLmkmxripiSVZirf
nHR7cIivj0gvjeZiM3UH/ZMPUdzRk4YXr9889EbO+JQ/iZy/1YIJHKuqLbCjAQZp
RgjuYYAuG91aHeCHN6cSflNoC49FmmBi9k1GkBdWviU0mhBrfaNfqspMkWUuH34g
w49H9iflFzJsh6p18h2wG3pB28zubUhLfpmbG5EOP4kXBYvgegAsY9mgSNWcdFFk
JBxcJlToCm6ooha8bBCpsnDf8/Y1LMlUIcP2Spd/iZ0pxtF2wR8Pt80KDuVko+fj
TZF3UTu3wuDCyHnSvX0Fc0YTQV0huVawd23upWBxpcdOa4vsScnUbMdKqBIjA6TX
cGK+fCtVSk45KoAlRi4eLcnNmgse1G2J+ujcrs0QakLxdCx+Ggk=
=+O9s
-----END PGP SIGNATURE-----
Merge tag 'arm-fixes-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"A number of devicetree fixes came in for the rockchip platforms,
correcting some of the address information, and reverting a change to
the MMC controller configuration that caused regressions.
Four drivers have one code change each, addressing minor build issues
for the optee firmware driver, the litex SoC platform driver and two
reset drivers.
The riscv fixes as also simple, mainly turning off device nodes in the
canaan dts files unless they are actually usable on a particular
board.
Finally, Drew takes over maintaining the THEAD RISC-V SoC platform"
* tag 'arm-fixes-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
drivers/soc/litex: drop obsolete dependency on COMPILE_TEST
tee: optee: ffa: Fix missing-field-initializers warning
arm64: dts: rockchip: Add sound-dai-cells for RK3368
arm64: dts: rockchip: Fix the i2c address of es8316 on Cool Pi 4B
reset: hisilicon: hi6220: add missing MODULE_DESCRIPTION() macro
reset: gpio: Fix missing gpiolib dependency for GPIO reset controller
MAINTAINERS: thead: update Maintainer
arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E
riscv: dts: starfive: Set EMMC vqmmc maximum voltage to 3.3V on JH7110 boards
arm64: dts: rockchip: make poweroff(8) work on Radxa ROCK 5A
Revert "arm64: dts: rockchip: remove redundant cd-gpios from rk3588 sdmmc nodes"
ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node
arm64: dts: rockchip: Fix the value of `dlg,jack-det-rate` mismatch on rk3399-gru
arm64: dts: rockchip: set correct pwm0 pinctrl on rk3588-tiger
riscv: dts: canaan: Disable I/O devices unless used
riscv: dts: canaan: Clean up serial aliases
arm64: dts: rockchip: Rename LED related pinctrl nodes on rk3308-rock-pi-s
arm64: dts: rockchip: Fix SD NAND and eMMC init on rk3308-rock-pi-s
arm64: dts: rockchip: Fix rk3308 codec@ff560000 reset-names
arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B
Both ACPI_PROCESSOR and HOTPLUG_CPU are needed by ACPI_HOTPLUG_CPU.
Otherwise, we can have compiling error with the following configurations.
CONFIG_HOTPLUG_CPU=n
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
arch/arm64/kernel/smp.c: In function ‘arch_unregister_cpu’:
arch/arm64/kernel/smp.c:563:9: error: implicit declaration of \
function ‘unregister_cpu’; did you mean ‘register_cpu’? \
[-Werror=implicit-function-declaration]
563 | unregister_cpu(c);
| ^~~~~~~~~~~~~~
| register_cpu
Fix it by enabling ACPI_HOTPLUG_CPU when both ACPI_PROCESSOR and
HOTPLUG_CPU are enabled, consistent with other architectures like
x86 and loongarch.
Fixes: 9d0873892f4d ("arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled.")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202406300437.XnuW0n34-lkp@intel.com/
Signed-off-by: Gavin Shan <gshan@redhat.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240701001132.1585153-1-gshan@redhat.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Fix the following warnings when compiling dtbs with W=1:
../arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi:343.10-353.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/tps6598x@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
../arch/arm64/boot/dts/ti/k3-am62-main.dtsi:633.22-643.5: Warning (graph_child_address): /bus@f0000/dwc3-usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
Cc: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Tested-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240626101520.1782320-3-d-gole@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Fix the following warnings that are thrown when building dtbs with W=1:
../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:367.10-376.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/usb-power-controller@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
../arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi:647.22-657.5: Warning (graph_child_address): /bus@f0000/usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
also defined at ../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:517.7-528.3
Cc: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240626101520.1782320-2-d-gole@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The AM67A/J722S/TDA4AEN platform is a derivative of AM62P platform
and we have no single 1:1 relation regarding index of GPIO and pin
controller. The GPIOs and pin controller registers have mapping and
holes in the map. These have been extracted from the J722S data
sheet. The MCU mapping is carried forward as is with J722S, however the
main GPIO block has differences that needs to be accounted for.
Mux mode input is selected as it is bi-directional. In case a specific
pull type or a specific pin level drive setting is desired, the board
device tree files will have to explicitly mux those pins for the GPIO
with the desired setting.
Ref: J722S Data sheet https://www.ti.com/lit/gpn/tda4aen-q1
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
On the AM62P platform we have no single 1:1 relation regarding index
of GPIO and pin controller. The GPIOs and pin controller registers
have mapping and holes in the map. These have been extracted from the
AM62P data sheet.
MCU pinctrl definition is shared as it is common between AM62P and
J722S, but that is not the case for main domain.
Ref: AM62P Data sheet https://www.ti.com/lit/gpn/am62p
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Introduce a GPIO mux mode macro for easier readability. All K3 devices
use mux mode 7 to switch to GPIO mux and this allows the gpio-ranges to
be defined for pinctrl-single clearly.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The WKUP system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-8-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
