From: "Inès Varhol" <ines.varhol@telecom-paris.fr>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Arnaud Minier <arnaud.minier@telecom-paris.fr>,
Paolo Bonzini <pbonzini@redhat.com>,
qemu-arm <qemu-arm@nongnu.org>, Samuel Tardieu <sam@rfc1149.net>,
peter maydell <peter.maydell@linaro.org>,
Alistair Francis <alistair@alistair23.me>,
Thomas Huth <thuth@redhat.com>,
Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH 2/3] hw/arm : Connect DM163 to STM32L4x5
Date: Wed, 7 Feb 2024 18:25:08 +0100 (CET) [thread overview]
Message-ID: <2124605303.230522.1707326708850.JavaMail.zimbra@enst.fr> (raw)
In-Reply-To: <22defe7a-6c67-4aae-b028-838ee6aa4e1a@linaro.org>
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
next prev parent reply other threads:[~2024-02-07 17:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 19:31 [PATCH 0/3] Add device DM163 (led driver, matrix colors shield & display) Inès Varhol
2024-01-26 19:31 ` [PATCH 1/3] hw/display : Add device DM163 Inès Varhol
2024-02-05 0:09 ` Alistair Francis
2024-01-26 19:31 ` [PATCH 2/3] hw/arm : Connect DM163 to STM32L4x5 Inès Varhol
2024-02-05 0:14 ` Alistair Francis
2024-02-05 13:46 ` Philippe Mathieu-Daudé
2024-02-07 17:25 ` Inès Varhol [this message]
2024-01-26 19:31 ` [PATCH 3/3] tests/qtest : Add testcase for DM163 Inès Varhol
2024-02-05 13:52 ` Philippe Mathieu-Daudé
2024-02-05 14:03 ` [PATCH 0/3] Add device DM163 (led driver, matrix colors shield & display) Philippe Mathieu-Daudé
2024-02-07 19:27 ` Inès Varhol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2124605303.230522.1707326708850.JavaMail.zimbra@enst.fr \
--to=ines.varhol@telecom-paris.fr \
--cc=alistair@alistair23.me \
--cc=arnaud.minier@telecom-paris.fr \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sam@rfc1149.net \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).