qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]