Swap USART3 and UART8 aliases on STM32MP15xx DHCOM SoM,
make sure UART8 is listed first, USART3 second, because
the UART8 is labeled as UART2 on the SoM pinout, while
USART3 is labeled as UART3 on the SoM pinout.
Fixes: 34e0c7847d ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V.
This property will stop the LDO regulator from switching to 1.8V when the
MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the
SDMMC interface pins in GPIO mode (PA0 - PA13).
On this board, PA10 is used as GPIO to enable the power switch controlling
USB Vbus for the USB Host. The change is needed to fix the PA10 voltage
level to 3.3V instead of 1.8V.
Fixes: 5d4c3cfb63 ("ARM: dts: at91: sama5d27_wlsom1: add SAMA5D27 wlsom1 and wlsom1-ek")
Suggested-by: Mihai Sain <mihai.sain@microchip.com>
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
Tested-by: Andrei Simion <andrei.simion@microchip.com>
Link: https://lore.kernel.org/r/20241119160107.598411-3-cristian.birsan@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V.
This property will stop the LDO regulator from switching to 1.8V when the
MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the
SDMMC interface pins in GPIO mode (PA0 - PA13).
On this board, PA6 is used as GPIO to enable the power switch controlling
USB Vbus for the USB Host. The change is needed to fix the PA6 voltage
level to 3.3V instead of 1.8V.
Fixes: d85c4229e9 ("ARM: dts: at91: sama5d29_curiosity: Add device tree for sama5d29_curiosity board")
Suggested-by: Mihai Sain <mihai.sain@microchip.com>
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
Tested-by: Andrei Simion <andrei.simion@microchip.com>
Link: https://lore.kernel.org/r/20241119160107.598411-2-cristian.birsan@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Enable the counter nodes without dedicated pins. With such configuration,
the counter interface can be used on internal clock to generate events.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Enable the counter nodes without dedicated pins. With such configuration,
the counter interface can be used on internal clock to generate events.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Enable the counter nodes without dedicated pins. With such configuration,
the counter interface can be used on internal clock to generate events.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Counter driver originally had support limited to quadrature interface
and simple counter. It has been improved[1], so add the remaining
stm32 timer counter nodes.
[1] https://lore.kernel.org/linux-arm-kernel/20240307133306.383045-1-fabrice.gasnier@foss.st.com/
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Counter driver originally had support limited to quadrature interface
and simple counter. It has been improved[1], so add the remaining
stm32 timer counter nodes.
[1] https://lore.kernel.org/linux-arm-kernel/20240307133306.383045-1-fabrice.gasnier@foss.st.com/
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The ARM PL081 DMA controller can be found in the BCM6846
memory map, and it turns out to work.
The block may be used as DMA engine for some of the
peripherals (maybe the EMMC controller found in the same
group of peripherals?) but it can always be used as a
memcpy engine, which is a generic "blitter".
I tested it with the dmatest module, and it copies
lots of data very fast and fires hundreds of thousands
of interrupts so it works just fine.
Add it to the BCM6846 DTSI file.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20241019-genexis-xg6846b-base-v3-6-8375a0e1f89f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
This adds the MDIO block found in the BCM6846. Use the new
"brcm,bcm6846-mdio" compatible (merged to the networking tree)
for this block.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20241019-genexis-xg6846b-base-v3-4-8375a0e1f89f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
The BCM6846 has the same simplistic GPIOs as some other
Broadcom SoCs: plain memory-mapped registers with up to
8 blocks of 32 GPIOs each totalling 256 GPIOs.
Users of the SoC can selectively enable the GPIO blocks
actually used with a certain design.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20241019-genexis-xg6846b-base-v3-3-8375a0e1f89f@linaro.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Remove properties which are both unused in the kernel and undocumented.
Most likely they are leftovers from downstream.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20241115193904.3624350-1-robh@kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Since these properties are common for all i2c subnodes,
move them to SoC dtsi from board dts.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://lore.kernel.org/r/20241122080523.3941-2-mihai.sain@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
at24.yaml defines the node name for at24 EEPROMs as 'eeprom'.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20240910215905.823337-1-robh@kernel.org
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add support for the lxa-tac generation 3 board based on the
STM32MP153c.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
This is a preparation patch in order to add lxa-tac generation 3
board.
As the gen3 board has a different adc and gpio{e,g} setups, move these
from the stm32mp15xc-lxa-tac.dtsi to the gen{1,2}.dts files.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Allow providing the Ethernet and mass storage functions on the USB
peripheral port at the same time.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Some of the userspace software and tests depend on the can/i2c/spi
devices having the same name on every boot. This may not always be the
case based on e.g. parallel probe order.
Assign static device numbers to all can/i2c/spi devices.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The RTC was enabled under the false assumption that the SoM already
contains a suitable 32.768 kHz crystal.
It does however not contain such a crystal and since none is fitted
externally to the SoM the RTC can not be used on the hardware.
Reflect that in the devicetree.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The GIC IRQ type used for IPCC RX should be IRQ_TYPE_LEVEL_HIGH.
Replacing the interrupt with the EXTI event changes the type to
the numeric value 1, meaning IRQ_TYPE_EDGE_RISING.
The issue is that EXTI event 61 is a direct event.The IRQ type of
direct events is not used by EXTI and is propagated to the parent
IRQ controller of EXTI, the GIC.
Align the IRQ type to the value expected by the GIC by replacing
the second parameter "1" with IRQ_TYPE_LEVEL_HIGH.
Fixes: 7d9802bb0e ("ARM: dts: stm32: remove the IPCC "wakeup" IRQ on stm32mp151")
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Move the M24256E write-lockable page subnode after RTC subnode in
DH STM32MP13xx DHCOR SoM DT to keep the list of nodes sorted by I2C
address. No functional change.
Fixes: 3f2e7d1673 ("ARM: dts: stm32: Describe M24256E write-lockable page in DH STM32MP13xx DHCOR SoM DT")
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The STM32MP13xx DHCOR DHSBC is populated with STM32MP13xx part capable
of 1 GHz operation, increase the CPU core voltage to 1.35 V to make
sure the SoC is stable even if the blobs unconditionally force the CPU
to 1 GHz operation.
It is not possible to make use of CPUfreq on the STM32MP13xx because
the SCMI protocol 0x13 is not implemented by upstream OpTee-OS which
is the SCMI provider.
Fixes: 6331bddce6 ("ARM: dts: stm32: Add support for STM32MP13xx DHCOR SoM and DHSBC board")
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Deduplicate /aliases { serialN = ... } and /chosen node into
stm32mp15xx-dhcom-som.dtsi , since the content is identical
on all carrier boards using the STM32MP15xx DHCOM SoM. No
functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
One of the usdhc1 controller's clocks should be IMXRT1050_CLK_AHB_PODF not
IMXRT1050_CLK_OSC.
Fixes: 1c4f01be34 ("ARM: dts: imx: Add i.MXRT1050-EVK support")
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The regulator-fec*-pwdn regulators were used to deassert the PWDN signal
of ethernet PHY, e.g. not powering. This is not necessary as the line
has a pull-up already.
Instead of the combo pad of the PHY for IRQ support.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Markus Niebel <markus.niebel@ew.tq-group.com>
Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
VCC3V3 is used twice, resulting in the debugfs warning:
debugfs: Directory 'VCC3V3' with parent 'regulator' already present!
The power supply provided by reg_vcc_3v3 is actually the same as
reg_mba_3v3.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Markus Niebel <markus.niebel@ew.tq-group.com>
Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
