Re: [PATCH RESEND 0/9] ARM: stm32: add STM32H7R7 and ART-Pi2 support
Alexandre TORGUE <[email protected]> Mon, 10 Aug 2026 10:28:33 +0200
| Newsgroups | org.kernel.vger.linux-clk,dev.linux.lists.mfd,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,org.kernel.vger.linux-gpio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi Liu On 7/26/26 17:49, Liu Changjie wrote: > Resending to repair threading after Outlook rewrote the cover Message-ID > during SMTP submission. Patch contents are unchanged. > Add initial mainline support for the STM32H7R7 and the Ruiside ART-Pi2 > development board. > > The ART-Pi2 boots through first-stage firmware in the STM32 internal flash. > That firmware configures the PLLs and memory interfaces before Linux > executes in place from external XSPI NOR, with 32 MiB of HyperRAM used as > system RAM. Reprogramming the PLLs from Linux could therefore stop the > instruction stream. > > The RCC driver in this series intentionally reconstructs the active clock > rates from the firmware-programmed RCC registers. It exposes the resulting > SYSCLK, bus, timer, UART and SDMMC clocks, while Linux owns only the > peripheral clock gates used by the initial device tree. It also exposes > the RCC reset registers through the existing reset-simple driver. The > first reset consumer is SDMMC1. > > The pinctrl driver covers GPIOA-H and GPIOM-P, including the AF0 trace > functions described by the STM32H7RS pin-control data. The board device > tree enables UART4, TIM5, twelve GPIO banks, two LEDs, the user button and > the four-bit SDMMC1 interface used by the microSD socket. The socket has > no card detect signal connected to the MCU, so the board uses broken-cd. > > ARM noMMU selects DMA_GLOBAL_POOL. The board therefore reserves a 2 MiB > shared DMA pool for the SDMMC internal DMA descriptor and bounce buffer. > The pool is required before the mainline mmci-pl18x driver can probe. > Please, have a look on this series from Arnd: https://lore.kernel.org/all/[email protected]/ "Regarding actually removing the code, I would suggest linux-7.4 (January 2027), removing both the board files and any drivers that have either become newly unused or were missed in a previous machine removal series, followed by removing support for then unused CPUs a release later." To be short, cortex-v7M CPUs are now deprecated and board support will be deleting beginning of next year. So, I'll not take new cortex-v7M board. regards Alex