[GIT PULL] STM32 DT changes for v5.11 #1

[GIT PULL] STM32 DT changes for v5.11 #1

[Alexandre TORGUE]

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

Re: [GIT PULL] STM32 DT changes for v5.11 #1

[patchwork-bot+linux-soc]

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

Re: [GIT PULL] STM32 DT changes for v5.11 #1

[Arnd Bergmann]

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

Re: [GIT PULL] STM32 DT changes for v5.11 #1

[Alexandre TORGUE]

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
> 

Re: [GIT PULL] STM32 DT changes for v5.11 #1

[Arnd Bergmann]

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

Re: [GIT PULL] STM32 DT changes for v5.11 #1

[Alexandre TORGUE]

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
> 

Re: [GIT PULL] STM32 DT changes for v5.11 #1

[Arnd Bergmann]

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