Hello !
> De: "Philippe Mathieu-Daudé" <phi...@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.min...@telecom-paris.fr>
> > Signed-off-by: Inès Varhol <ines.var...@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
