qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/3] hw/arm : Connect DM163 to STM32L4x5


From: Inès Varhol
Subject: Re: [PATCH 2/3] hw/arm : Connect DM163 to STM32L4x5
Date: Wed, 7 Feb 2024 18:25:08 +0100 (CET)

Hello !

> De: "Philippe Mathieu-Daudé" <philmd@linaro.org>
> Envoyé: Lundi 5 Février 2024 14:46:58
>
> Hi Inès,
> 
> On 26/1/24 20:31, Inès Varhol wrote:
> > Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr>
> > Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>
> > ---
> >   hw/arm/Kconfig                 |  1 +
> >   hw/arm/stm32l4x5_soc.c         | 55 +++++++++++++++++++++++++++++++++-
> >   include/hw/arm/stm32l4x5_soc.h |  3 ++
> >   3 files changed, 58 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> > index 3e49b913f8..818aa2f1a2 100644
> > --- a/hw/arm/Kconfig
> > +++ b/hw/arm/Kconfig
> > @@ -463,6 +463,7 @@ config STM32L4X5_SOC
> >       select STM32L4X5_SYSCFG
> >       select STM32L4X5_RCC
> >       select STM32L4X5_GPIO
> > +    select DM163
> 
> 
> > +/*
> > + * There are actually 14 input pins in the DM163 device.
> > + * Here the DM163 input pin EN isn't connected to the STM32L4x5
> > + * GPIOs as the IM120417002 colors shield doesn't actually use
> > + * this pin to drive the RGB matrix.
> > + */
> > +#define NUM_DM163_INPUTS 13
> > +
> > +static const int dm163_input[NUM_DM163_INPUTS] = {
> > +    1 * 16 + 2,  /* ROW0  PB2       */
> > +    0 * 16 + 15, /* ROW1  PA15      */
> > +    0 * 16 + 2,  /* ROW2  PA2       */
> > +    0 * 16 + 7,  /* ROW3  PA7       */
> > +    0 * 16 + 6,  /* ROW4  PA6       */
> > +    0 * 16 + 5,  /* ROW5  PA5       */
> > +    1 * 16 + 0,  /* ROW6  PB0       */
> > +    0 * 16 + 3,  /* ROW7  PA3       */
> > +    0 * 16 + 4,  /* SIN (SDA) PA4   */
> > +    1 * 16 + 1,  /* DCK (SCK) PB1   */
> > +    2 * 16 + 3,  /* RST_B (RST) PC3 */
> > +    2 * 16 + 4,  /* LAT_B (LAT) PC4 */
> > +    2 * 16 + 5,  /* SELBK (SB)  PC5 */
> > +};
> > +
> > +
> >   static const uint32_t gpio_addr[] = {
> >       0x48000000,
> >       0x48000400,
> > @@ -116,6 +143,8 @@ static void stm32l4x5_soc_initfn(Object *obj)
> >           g_autofree char *name = g_strdup_printf("gpio%c", 'a' + i);
> >           object_initialize_child(obj, name, &s->gpio[i], 
> > TYPE_STM32L4X5_GPIO);
> >       }
> > +
> > +    object_initialize_child(obj, "dm163", &s->dm163, TYPE_DM163);
> 
> The DM163 is another chip, not a component part of the SoC;
> it belongs to the machine and should be created/wired in
> b_l475e_iot01a_init(). Similarly to the IRQ splitters.
> 
> Keeping board component states in a Bl475eMachineState structure
> could help organizing your model. You can find an example on how
> extend the MachineState in hw/avr/arduino.c.
> 

Yes thank you ! that's done :)

> You might call qdev_pass_gpios() to exposes the SysCfg lines out
> of the SoC.

I was wondering what's the reason to expose Syscfg lines and not Gpio lines?
(Should GPIOs also be moved to the machine ?)

Best regards,

Ines



reply via email to

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