| Message ID | 873c17a5-28d5-9261-f691-1b917611c932@foss.st.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | fcc3e3c3a4a2b05c8775ecddbef56ff1dcca31c2 |
| Headers | show |
| Series | [GIT,PULL] STM32 DT changes for v5.11 #1 | expand |
Hello: This pull request was applied to soc/soc.git (refs/heads/for-next): On Fri, 27 Nov 2020 09:54:22 +0100 you wrote: > Hi ARM SoC maintainers, > > > Please consider this first round of STM32 DT updates for v5.11. As usual > main changed concern MPU part. Various fixes have been done, a new board > has been added for DH and USB type C support has been added for ST DK > boards. > > [...] Here is the summary with links: - [GIT,PULL] STM32 DT changes for v5.11 #1 https://git.kernel.org/soc/soc/c/fcc3e3c3a4a2 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
On Fri, Nov 27, 2020 at 9:54 AM Alexandre TORGUE <alexandre.torgue@foss.st.com> wrote: > > Please consider this first round of STM32 DT updates for v5.11. As usual > main changed concern MPU part. Various fixes have been done, a new board > has been added for DH and USB type C support has been added for ST DK > boards. Out of curiosity, what is your impression of the state of the MCU port? It seems to me that STM32H7/STM32F7 is by far the most active NOMMU platform in mainline Linux (with some activity for j2 and recently rv64), but it's also much less active than it was a few years ago and slowly winding down further, presumably as other OSs are getting better and full-featured MPUs are getting almost as cheap. I also tried to find modern distro support, but I couldn't find anything that has the elf-fdpic changes that were merged into mainline gcc, instead it seems any user space is either on binfmt-flat or using elf-fdpic with ancient patched compilers that can build user space but no longer build the kernel (which now requires gcc-4.9 or higher), so I wonder if I'm looking in the wrong places, or if this just doesn't work. Overall, is this something where you only support existing users for as long as they are around, or do you keep seeing new products based on STM32F4/F7/H7? > Due to company IT changes, for upstream "process" my mail address in no > longer alexandre.torgue@st.com but alexandre.torgue@foss.st.com. Let me > know if it causes issue for tag signature. On my side I updated GPG key > with this new address and it seems ok. It's no problem on my end, thanks for letting me know. Arnd
Hi Arnd On 11/27/20 8:42 PM, Arnd Bergmann wrote: > On Fri, Nov 27, 2020 at 9:54 AM Alexandre TORGUE > <alexandre.torgue@foss.st.com> wrote: >> >> Please consider this first round of STM32 DT updates for v5.11. As usual >> main changed concern MPU part. Various fixes have been done, a new board >> has been added for DH and USB type C support has been added for ST DK >> boards. > > Out of curiosity, what is your impression of the state of the MCU port? > > It seems to me that STM32H7/STM32F7 is by far the most active NOMMU > platform in mainline Linux (with some activity for j2 and recently rv64), but > it's also much less active than it was a few years ago and slowly winding down > further, presumably as other OSs are getting better and full-featured MPUs > are getting almost as cheap. There is 2 kinds of activity around our MCU products: one coming from ST team (as most of peripherals are common with our MPU, changes done for MPU are reported to MCU). And another coming from external people using those MCU boards (few people). There are still improvements to do for those platforms like adding dma support on cortex-M7 (which implies to use dedicated MPU region ...) but I don't have as much time as I would like to work on this subject so it is still pending. I would say that stm32 mcu linux support continues to survive with incoming patches and at rhythm of the incoming patches. > I also tried to find modern distro support, but I couldn't find anything that > has the elf-fdpic changes that were merged into mainline gcc, instead > it seems any user space is either on binfmt-flat or using elf-fdpic with > ancient patched compilers that can build user space but no longer > build the kernel (which now requires gcc-4.9 or higher), so I wonder if > I'm looking in the wrong places, or if this just doesn't work. Some STM32 MCU are supported in buildroot (not all), using u-boot as bootloader and binfmt-flat for user space. Concerning fdpic, IIRC support has been added in buildroot but we don't use it yet for our STM32. > Overall, is this something where you only support existing users for > as long as they are around, or do you keep seeing new products based > on STM32F4/F7/H7? I just continue to support existing users and I don't plan to push another STM32 MCU. Do you think we should better promote/support NOMMU platform in mainline? regards Alex > >> Due to company IT changes, for upstream "process" my mail address in no >> longer alexandre.torgue@st.com but alexandre.torgue@foss.st.com. Let me >> know if it causes issue for tag signature. On my side I updated GPG key >> with this new address and it seems ok. > > It's no problem on my end, thanks for letting me know. > > Arnd >
On Wed, Dec 2, 2020 at 12:00 PM Alexandre TORGUE <alexandre.torgue@foss.st.com> wrote: > On 11/27/20 8:42 PM, Arnd Bergmann wrote: > > On Fri, Nov 27, 2020 at 9:54 AM Alexandre TORGUE > > <alexandre.torgue@foss.st.com> wrote: > >> > >> Please consider this first round of STM32 DT updates for v5.11. As usual > >> main changed concern MPU part. Various fixes have been done, a new board > >> has been added for DH and USB type C support has been added for ST DK > >> boards. > > > > Out of curiosity, what is your impression of the state of the MCU port? > > > > It seems to me that STM32H7/STM32F7 is by far the most active NOMMU > > platform in mainline Linux (with some activity for j2 and recently rv64), but > > it's also much less active than it was a few years ago and slowly winding down > > further, presumably as other OSs are getting better and full-featured MPUs > > are getting almost as cheap. > > There is 2 kinds of activity around our MCU products: one coming from ST > team (as most of peripherals are common with our MPU, changes done for > MPU are reported to MCU). And another coming from external people using > those MCU boards (few people). > There are still improvements to do for those platforms like adding dma > support on cortex-M7 (which implies to use dedicated MPU region ...) but > I don't have as much time as I would like to work on this subject so it > is still pending. > I would say that stm32 mcu linux support continues to survive with > incoming patches and at rhythm of the incoming patches. Ok, thanks for the background! > > I also tried to find modern distro support, but I couldn't find anything that > > has the elf-fdpic changes that were merged into mainline gcc, instead > > it seems any user space is either on binfmt-flat or using elf-fdpic with > > ancient patched compilers that can build user space but no longer > > build the kernel (which now requires gcc-4.9 or higher), so I wonder if > > I'm looking in the wrong places, or if this just doesn't work. > > Some STM32 MCU are supported in buildroot (not all), using u-boot as > bootloader and binfmt-flat for user space. Concerning fdpic, IIRC > support has been added in buildroot but we don't use it yet for our STM32. > > > Overall, is this something where you only support existing users for > > as long as they are around, or do you keep seeing new products based > > on STM32F4/F7/H7? > > I just continue to support existing users and I don't plan to push > another STM32 MCU. > > Do you think we should better promote/support NOMMU > platform in mainline? No, I think what you do is absolutely appropriate given the current state: keep the existing users happy but minimise the work needed for that. It would however be good if you could let everyone know once you notice a further decrease in interest over time, as I think we do want to retire NOMMU kernels eventually, and confine the users to stable kernels once there are few enough of them. Out of the remaining NOMMU architectures, this is what I observe: - ARM: most activity is on stm32, once this one gets retired, the other ones can probably go as well - m68k: actively maintained, but aging: the newest NOMMU chip (MCF537x) is from 2007. - SuperH: SH2/SH2A is practically dead, minimal J2 support was added in 2016, apparently it is still work-in-progress but progressing slowly - riscv: K210 support was only added in 2020 and is actively being worked on at the moment, as there are very few affordable RISC-V systems at all. This might change as soon as one can easily buy a cheap RV64 board with an MMU. - microblaze: NOMMU support to be removed in v5.11 or v5.12 - h8300: there is talk of removing the architecture - c6x: still (barely) maintained, but I could find no indication of actual users - xtensa: one defconfig has MMU disabled, but has always failed to build as far as I can tell. Max has an out-of-tree patch series for the ESP32, but has not updated it since v5.6. Overall, there is clearly still enough going on to keep it around for a while, but not much that anyone gets excited about. If you ever stop testing and updating the STM32 MCU platform, I think we should ask the other maintainers if any of the remaining platforms are important enough to keep NOMMU supported at all, or if one of the future LTS releases should be planned as the last one to have a NOMMU option. Arnd
Hi Arnd On 12/2/20 2:32 PM, Arnd Bergmann wrote: > On Wed, Dec 2, 2020 at 12:00 PM Alexandre TORGUE > <alexandre.torgue@foss.st.com> wrote: >> On 11/27/20 8:42 PM, Arnd Bergmann wrote: >>> On Fri, Nov 27, 2020 at 9:54 AM Alexandre TORGUE >>> <alexandre.torgue@foss.st.com> wrote: >>>> >>>> Please consider this first round of STM32 DT updates for v5.11. As usual >>>> main changed concern MPU part. Various fixes have been done, a new board >>>> has been added for DH and USB type C support has been added for ST DK >>>> boards. >>> >>> Out of curiosity, what is your impression of the state of the MCU port? >>> >>> It seems to me that STM32H7/STM32F7 is by far the most active NOMMU >>> platform in mainline Linux (with some activity for j2 and recently rv64), but >>> it's also much less active than it was a few years ago and slowly winding down >>> further, presumably as other OSs are getting better and full-featured MPUs >>> are getting almost as cheap. >> >> There is 2 kinds of activity around our MCU products: one coming from ST >> team (as most of peripherals are common with our MPU, changes done for >> MPU are reported to MCU). And another coming from external people using >> those MCU boards (few people). >> There are still improvements to do for those platforms like adding dma >> support on cortex-M7 (which implies to use dedicated MPU region ...) but >> I don't have as much time as I would like to work on this subject so it >> is still pending. >> I would say that stm32 mcu linux support continues to survive with >> incoming patches and at rhythm of the incoming patches. > > Ok, thanks for the background! > >>> I also tried to find modern distro support, but I couldn't find anything that >>> has the elf-fdpic changes that were merged into mainline gcc, instead >>> it seems any user space is either on binfmt-flat or using elf-fdpic with >>> ancient patched compilers that can build user space but no longer >>> build the kernel (which now requires gcc-4.9 or higher), so I wonder if >>> I'm looking in the wrong places, or if this just doesn't work. >> >> Some STM32 MCU are supported in buildroot (not all), using u-boot as >> bootloader and binfmt-flat for user space. Concerning fdpic, IIRC >> support has been added in buildroot but we don't use it yet for our STM32. >> >>> Overall, is this something where you only support existing users for >>> as long as they are around, or do you keep seeing new products based >>> on STM32F4/F7/H7? >> >> I just continue to support existing users and I don't plan to push >> another STM32 MCU. >> >> Do you think we should better promote/support NOMMU >> platform in mainline? > > No, I think what you do is absolutely appropriate given the current > state: keep the existing users happy but minimise the work needed > for that. > > It would however be good if you could let everyone know once > you notice a further decrease in interest over time, as I think we > do want to retire NOMMU kernels eventually, and confine the users > to stable kernels once there are few enough of them. Out of the > remaining NOMMU architectures, this is what I observe: > > - ARM: most activity is on stm32, once this one gets retired, the > other ones can probably go as well > > - m68k: actively maintained, but aging: the newest NOMMU > chip (MCF537x) is from 2007. > > - SuperH: SH2/SH2A is practically dead, minimal J2 support > was added in 2016, apparently it is still work-in-progress > but progressing slowly > > - riscv: K210 support was only added in 2020 and is > actively being worked on at the moment, as there are > very few affordable RISC-V systems at all. This might > change as soon as one can easily buy a cheap RV64 > board with an MMU. > > - microblaze: NOMMU support to be removed in v5.11 or v5.12 > > - h8300: there is talk of removing the architecture > > - c6x: still (barely) maintained, but I could find no indication of > actual users > > - xtensa: one defconfig has MMU disabled, but has always > failed to build as far as I can tell. Max has an out-of-tree > patch series for the ESP32, but has not updated it since > v5.6. > > Overall, there is clearly still enough going on to keep it around > for a while, but not much that anyone gets excited about. > If you ever stop testing and updating the STM32 MCU platform, > I think we should ask the other maintainers if any of the > remaining platforms are important enough to keep NOMMU > supported at all, or if one of the future LTS releases should be > planned as the last one to have a NOMMU option. So let's continue like that for now. I'll keep you aware if I get new inputs on my side and if we observe some PR without MCU patches we could reconsider the question. Cheers Alex > Arnd >
On Mon, Dec 7, 2020 at 5:20 PM Alexandre TORGUE <alexandre.torgue@foss.st.com> wrote: > On 12/2/20 2:32 PM, Arnd Bergmann wrote: > > On Wed, Dec 2, 2020 at 12:00 PM Alexandre TORGUE > > So let's continue like that for now. I'll keep you aware if I get new > inputs on my side and if we observe some PR without MCU patches we could > reconsider the question. Yes, sounds good to me. Arnd
Hi ARM SoC maintainers, Please consider this first round of STM32 DT updates for v5.11. As usual main changed concern MPU part. Various fixes have been done, a new board has been added for DH and USB type C support has been added for ST DK boards. Due to company IT changes, for upstream "process" my mail address in no longer alexandre.torgue@st.com but alexandre.torgue@foss.st.com. Let me know if it causes issue for tag signature. On my side I updated GPG key with this new address and it seems ok. regards Alex The following changes since commit f4c7fa39415da6db1fa0bc26162ac23a0fbae8bb: ARM: dts: stm32: Keep VDDA LDO1 always on on DHCOM (2020-11-09 14:36:50 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git tags/stm32-dt-for-v5.11-1 for you to fetch changes up to 6660e2445523a57410de008a9b137d2c0a66e94a: ARM: dts: stm32: lxa-mc1: add OSD32MP15x to list of compatibles (2020-11-26 14:42:41 +0100) ---------------------------------------------------------------- STM32 DT updates for v5.11, round 1 Highlights: ---------- MCU part: -Fix dmamux reg property (length) on stm32h743. -Explicitly set DCMI bus type on stm32429i eval board. MPU part: -Enable FIFO mode with half-full threshold for DCMI. -Harmonize EHCI/OHCI nodes. -Move SDMMC IP version to v2.0 to get features improvements. -Add LP-timer wakeup support. -Enable crypto/hash/crc support. -Explicitly set DCMI bus type on stm32mp157 eval board. -Add USB type-c controller (STUSB1600) on stm32mp15 DK boards (It is connected to I2C4). -Fix dmamux reg property (length) on stm32mp151. -Optimize USB OTG FIFO sizes on stm32mp151. -Declare tamp node also as "simple-mfd". -LXA: -Document Octavo vendor-prefixes yaml file. -Document lxa,stm32mp157c-mc1 in STM32 yaml file. -DH: -Connect PHY IRQ line on DH SoM. -Add KS8851 Ethernet support on DHCOM which is mapped to FMC2. -Document all DH compatible strings in STM32 yaml file. -Add DHCOM based PicoITX board. This board embeds ethernet port, USB, CAN LEDS and a custom board-to-board connector. ---------------------------------------------------------------- Ahmad Fatoum (5): dt-bindings: arm: stm32: add simple-mfd compatible for tamp node ARM: dts: stm32: support child mfd cells for the stm32mp1 TAMP syscon dt-bindings: vendor-prefixes: document Octavo Systems oct prefix dt-bindings: arm: stm32: add extra SiP compatible for lxa,stm32mp157c-mc1 ARM: dts: stm32: lxa-mc1: add OSD32MP15x to list of compatibles Amelie Delaunay (7): dt-bindings: connector: add typec-power-opmode property to usb-connector dt-bindings: usb: Add DT bindings for STUSB160x Type-C controller ARM: dts: stm32: add STUSB1600 Type-C using I2C4 on stm32mp15xx-dkx ARM: dts: stm32: fix mdma1 clients channel priority level on stm32mp151 ARM: dts: stm32: fix dmamux reg property on stm32mp151 ARM: dts: stm32: fix dmamux reg property on stm32h743 ARM: dts: stm32: adjust USB OTG gadget fifo sizes in stm32mp151 Arnaud Pouliquen (1): ARM: dts: stm32: update stm32mp151 for remote proc synchronization support Fabrice Gasnier (2): ARM: dts: stm32: Add LP timer irqs on stm32mp151 ARM: dts: stm32: Add LP timer wakeup-source on stm32mp151 Hugues Fruchet (3): ARM: dts: stm32: fix DCMI DMA features on stm32mp15 family ARM: dts: stm32: set bus-type in DCMI endpoint for stm32mp157c-ev1 board ARM: dts: stm32: set bus-type in DCMI endpoint for stm32429i-eval board Lionel Debieve (2): ARM: dts: stm32: enable HASH by default on stm32mp15 ARM: dts: stm32: enable CRYP by default on stm32mp15 Marek Vasut (5): ARM: dts: stm32: Connect PHY IRQ line on DH STM32MP1 SoM ARM: dts: stm32: Add alternate pinmux for FMC EBI bus ARM: dts: stm32: Add KS8851 on FMC2 to STM32MP1 DHCOM dt-bindings: arm: stm32: Add compatible strings for DH SoMs and boards ARM: dts: stm32: Add DHCOM based PicoITX board Nicolas Toromanoff (1): ARM: dts: stm32: enable CRC1 by default on stm32mp15 Patrick Delaunay (1): ARM: dts: stm32: reorder spi4 within stm32mp15-pinctrl Serge Semin (1): ARM: dts: stm32: Harmonize EHCI/OHCI DT nodes name on stm32mp15 Yann Gautier (1): ARM: dts: stm32: update sdmmc IP version for STM32MP15 .../bindings/arm/stm32/st,stm32-syscon.yaml | 4 + .../devicetree/bindings/arm/stm32/stm32.yaml | 23 +++- .../bindings/connector/usb-connector.yaml | 24 ++++ .../devicetree/bindings/usb/st,stusb160x.yaml | 87 +++++++++++++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/stm32429i-eval.dts | 1 + arch/arm/boot/dts/stm32h743.dtsi | 2 +- arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 90 +++++++++++-- arch/arm/boot/dts/stm32mp151.dtsi | 41 ++++-- arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts | 35 +++++ arch/arm/boot/dts/stm32mp157c-dk2.dts | 4 + arch/arm/boot/dts/stm32mp157c-ed1.dts | 12 ++ arch/arm/boot/dts/stm32mp157c-ev1.dts | 1 + arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts | 2 +- arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi | 143 +++++++++++++++++++++ arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi | 37 ++++++ arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 38 ++++++ 18 files changed, 517 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/st,stusb160x.yaml create mode 100644 arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi