[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 2/5] hw/arm : Pass STM32L4x5 SYSCFG gpios to STM32L4x5 SoC
From: |
Peter Maydell |
Subject: |
Re: [PATCH v3 2/5] hw/arm : Pass STM32L4x5 SYSCFG gpios to STM32L4x5 SoC |
Date: |
Tue, 12 Mar 2024 14:49:22 +0000 |
On Wed, 28 Feb 2024 at 12:02, Inès Varhol <ines.varhol@telecom-paris.fr> wrote:
>
> Exposing SYSCFG inputs to the SoC is practical in order to wire the SoC
> to the optional DM163 display from the board code (GPIOs outputs need
> to be connected to both SYSCFG inputs and DM163 inputs).
>
> STM32L4x5 SYSCFG in-irq interception needed to be changed accordingly.
>
> Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr>
> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>
> ---
>
> Hello,
>
> If SYSCFG inputs are exposed, should GPIOs be part of the board
> rather than the SoC?
I generally approach this kind of question from the starting point
of "what does the hardware we're modelling do?". Does the actual
SoC expose these lines as pins? If so, QEMU's model reasonably
should too. If the hardware SoC doesn't expose the lines, then
presumably it handles the DM163 in some other way, in which case
QEMU's model should follow whatever that other way is. This isn't
always feasible, but it's usually a good guiding principle.
If you can explain in more detail what's going on with this
particular board/device I can maybe give more specific advice.
thanks
-- PMM
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v3 2/5] hw/arm : Pass STM32L4x5 SYSCFG gpios to STM32L4x5 SoC,
Peter Maydell <=