From: Peter Maydell <peter.maydell@linaro.org> To: Alistair Francis <alistair@alistair23.me> Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "alistair23@gmail.com" <alistair23@gmail.com> Subject: Re: [Qemu-devel] [PATCH v1 3/5] hw/misc: Add the STM32F4xx EXTI device Date: Tue, 30 Apr 2019 16:48:47 +0100 [thread overview] Message-ID: <CAFEAcA_T7-+de9=V=hnku9f0BXdpLfz6wLFFZYp9LyYDx2KLCw@mail.gmail.com> (raw) In-Reply-To: <PSXP216MB0277D0653D098FF32C5DC07DDD390@PSXP216MB0277.KORP216.PROD.OUTLOOK.COM> On Mon, 29 Apr 2019 at 06:37, Alistair Francis <alistair@alistair23.me> wrote: > > Signed-off-by: Alistair Francis <alistair@alistair23.me> > --- > default-configs/arm-softmmu.mak | 1 + > hw/misc/Kconfig | 3 + > hw/misc/Makefile.objs | 1 + > hw/misc/stm32f4xx_exti.c | 175 +++++++++++++++++++++++++++++++ > include/hw/misc/stm32f4xx_exti.h | 57 ++++++++++ > 5 files changed, 237 insertions(+) > create mode 100644 hw/misc/stm32f4xx_exti.c > create mode 100644 include/hw/misc/stm32f4xx_exti.h Minor comments here only. (If Thomas's kconfig patchset gets into master before this there might be some minor fixups required to the kconfig stuff, but it shouldn't be too hard to adapt.) > +#include "qemu/osdep.h" > +#include "hw/sysbus.h" > +#include "qemu/log.h" > +#include "hw/misc/stm32f4xx_exti.h" > + > +#ifndef STM_EXTI_ERR_DEBUG > +#define STM_EXTI_ERR_DEBUG 0 > +#endif > + > +#define DB_PRINT_L(lvl, fmt, args...) do { \ > + if (STM_EXTI_ERR_DEBUG >= lvl) { \ > + qemu_log("%s: " fmt, __func__, ## args); \ > + } \ > +} while (0) > + > +#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args) Could we use a tracepoint instead? > + > +#define NUM_GPIO_EVENT_IN_LINES 16 > +#define NUM_INTERRUPT_OUT_LINES 16 > + > +static void stm32f4xx_exti_reset(DeviceState *dev) > +{ > + STM32F4xxExtiState *s = STM32F4XX_EXTI(dev); > + > + s->exti_imr = 0x00000000; > + s->exti_emr = 0x00000000; > + s->exti_rtsr = 0x00000000; > + s->exti_ftsr = 0x00000000; > + s->exti_swier = 0x00000000; > + s->exti_pr = 0x00000000; > +} > + > +static void stm32f4xx_exti_set_irq(void *opaque, int irq, int level) > +{ > + STM32F4xxExtiState *s = opaque; > + > + DB_PRINT("Set EXTI: %d to %d\n", irq, level); > + > + if (level) { > + qemu_irq_pulse(s->irq[irq]); > + s->exti_pr |= 1 << irq; > + } > +} Just to check -- this should definitely be a pulse? I'm always a little bit wary of uses of qemu_irq_pulse(), though some hardware does pulse IRQ lines rather than holding them until dismissed. > +static void stm32f4xx_exti_init(Object *obj) > +{ > + STM32F4xxExtiState *s = STM32F4XX_EXTI(obj); > + int i; > + > + s->irq = g_new0(qemu_irq, NUM_INTERRUPT_OUT_LINES); You could just have the array be inline in the STM32F4xxExtiState rather than allocating it separately, right? > + for (i = 0; i < NUM_INTERRUPT_OUT_LINES; i++) { > + sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq[i]); > + } > + > + memory_region_init_io(&s->mmio, obj, &stm32f4xx_exti_ops, s, > + TYPE_STM32F4XX_EXTI, 0x400); > + sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio); > + > + qdev_init_gpio_in(DEVICE(obj), stm32f4xx_exti_set_irq, > + NUM_GPIO_EVENT_IN_LINES); > +} > + > +static void stm32f4xx_exti_class_init(ObjectClass *klass, void *data) > +{ > + DeviceClass *dc = DEVICE_CLASS(klass); > + > + dc->reset = stm32f4xx_exti_reset; This one's missing vmstate too. > +} > + > +static const TypeInfo stm32f4xx_exti_info = { > + .name = TYPE_STM32F4XX_EXTI, > + .parent = TYPE_SYS_BUS_DEVICE, > + .instance_size = sizeof(STM32F4xxExtiState), > + .instance_init = stm32f4xx_exti_init, > + .class_init = stm32f4xx_exti_class_init, > +}; > + > +static void stm32f4xx_exti_register_types(void) > +{ > + type_register_static(&stm32f4xx_exti_info); > +} > + thanks -- PMM
WARNING: multiple messages have this Message-ID (diff)
From: Peter Maydell <peter.maydell@linaro.org> To: Alistair Francis <alistair@alistair23.me> Cc: "alistair23@gmail.com" <alistair23@gmail.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org> Subject: Re: [Qemu-devel] [PATCH v1 3/5] hw/misc: Add the STM32F4xx EXTI device Date: Tue, 30 Apr 2019 16:48:47 +0100 [thread overview] Message-ID: <CAFEAcA_T7-+de9=V=hnku9f0BXdpLfz6wLFFZYp9LyYDx2KLCw@mail.gmail.com> (raw) Message-ID: <20190430154847.GHTJUEyLxSooL1ERTt5QlV2w9Ouz9wElTLfaB4To8zo@z> (raw) In-Reply-To: <PSXP216MB0277D0653D098FF32C5DC07DDD390@PSXP216MB0277.KORP216.PROD.OUTLOOK.COM> On Mon, 29 Apr 2019 at 06:37, Alistair Francis <alistair@alistair23.me> wrote: > > Signed-off-by: Alistair Francis <alistair@alistair23.me> > --- > default-configs/arm-softmmu.mak | 1 + > hw/misc/Kconfig | 3 + > hw/misc/Makefile.objs | 1 + > hw/misc/stm32f4xx_exti.c | 175 +++++++++++++++++++++++++++++++ > include/hw/misc/stm32f4xx_exti.h | 57 ++++++++++ > 5 files changed, 237 insertions(+) > create mode 100644 hw/misc/stm32f4xx_exti.c > create mode 100644 include/hw/misc/stm32f4xx_exti.h Minor comments here only. (If Thomas's kconfig patchset gets into master before this there might be some minor fixups required to the kconfig stuff, but it shouldn't be too hard to adapt.) > +#include "qemu/osdep.h" > +#include "hw/sysbus.h" > +#include "qemu/log.h" > +#include "hw/misc/stm32f4xx_exti.h" > + > +#ifndef STM_EXTI_ERR_DEBUG > +#define STM_EXTI_ERR_DEBUG 0 > +#endif > + > +#define DB_PRINT_L(lvl, fmt, args...) do { \ > + if (STM_EXTI_ERR_DEBUG >= lvl) { \ > + qemu_log("%s: " fmt, __func__, ## args); \ > + } \ > +} while (0) > + > +#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args) Could we use a tracepoint instead? > + > +#define NUM_GPIO_EVENT_IN_LINES 16 > +#define NUM_INTERRUPT_OUT_LINES 16 > + > +static void stm32f4xx_exti_reset(DeviceState *dev) > +{ > + STM32F4xxExtiState *s = STM32F4XX_EXTI(dev); > + > + s->exti_imr = 0x00000000; > + s->exti_emr = 0x00000000; > + s->exti_rtsr = 0x00000000; > + s->exti_ftsr = 0x00000000; > + s->exti_swier = 0x00000000; > + s->exti_pr = 0x00000000; > +} > + > +static void stm32f4xx_exti_set_irq(void *opaque, int irq, int level) > +{ > + STM32F4xxExtiState *s = opaque; > + > + DB_PRINT("Set EXTI: %d to %d\n", irq, level); > + > + if (level) { > + qemu_irq_pulse(s->irq[irq]); > + s->exti_pr |= 1 << irq; > + } > +} Just to check -- this should definitely be a pulse? I'm always a little bit wary of uses of qemu_irq_pulse(), though some hardware does pulse IRQ lines rather than holding them until dismissed. > +static void stm32f4xx_exti_init(Object *obj) > +{ > + STM32F4xxExtiState *s = STM32F4XX_EXTI(obj); > + int i; > + > + s->irq = g_new0(qemu_irq, NUM_INTERRUPT_OUT_LINES); You could just have the array be inline in the STM32F4xxExtiState rather than allocating it separately, right? > + for (i = 0; i < NUM_INTERRUPT_OUT_LINES; i++) { > + sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq[i]); > + } > + > + memory_region_init_io(&s->mmio, obj, &stm32f4xx_exti_ops, s, > + TYPE_STM32F4XX_EXTI, 0x400); > + sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio); > + > + qdev_init_gpio_in(DEVICE(obj), stm32f4xx_exti_set_irq, > + NUM_GPIO_EVENT_IN_LINES); > +} > + > +static void stm32f4xx_exti_class_init(ObjectClass *klass, void *data) > +{ > + DeviceClass *dc = DEVICE_CLASS(klass); > + > + dc->reset = stm32f4xx_exti_reset; This one's missing vmstate too. > +} > + > +static const TypeInfo stm32f4xx_exti_info = { > + .name = TYPE_STM32F4XX_EXTI, > + .parent = TYPE_SYS_BUS_DEVICE, > + .instance_size = sizeof(STM32F4xxExtiState), > + .instance_init = stm32f4xx_exti_init, > + .class_init = stm32f4xx_exti_class_init, > +}; > + > +static void stm32f4xx_exti_register_types(void) > +{ > + type_register_static(&stm32f4xx_exti_info); > +} > + thanks -- PMM
next prev parent reply other threads:[~2019-04-30 15:49 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <cover.1556515687.git.alistair@alistair23.me> 2019-04-29 5:29 ` [Qemu-devel] [PATCH v1 1/5] armv7m: Allow entry information to be returned Alistair Francis 2019-04-29 5:29 ` Alistair Francis 2019-04-29 5:32 ` Alistair Francis 2019-04-29 5:32 ` Alistair Francis 2019-04-30 16:04 ` Peter Maydell 2019-04-30 16:04 ` Peter Maydell 2019-05-01 3:54 ` Alistair Francis 2019-05-01 3:54 ` Alistair Francis 2019-04-29 5:32 ` [Qemu-devel] [PATCH v1 2/5] hw/misc: Add the STM32F4xx Sysconfig device Alistair Francis 2019-04-29 5:32 ` Alistair Francis 2019-04-30 15:44 ` Peter Maydell 2019-04-30 15:44 ` Peter Maydell 2019-04-29 5:33 ` [Qemu-devel] [PATCH v1 3/5] hw/misc: Add the STM32F4xx EXTI device Alistair Francis 2019-04-29 5:33 ` Alistair Francis 2019-04-30 15:48 ` Peter Maydell [this message] 2019-04-30 15:48 ` Peter Maydell 2019-05-02 4:28 ` Alistair Francis 2019-05-02 4:28 ` Alistair Francis 2019-04-29 5:33 ` [Qemu-devel] [PATCH v1 4/5] hw/arm: Add the STM32F4xx SoC Alistair Francis 2019-04-29 5:33 ` Alistair Francis 2019-04-29 12:38 ` KONRAD Frederic 2019-04-29 12:38 ` KONRAD Frederic 2019-04-29 17:00 ` Alistair Francis 2019-04-29 17:00 ` Alistair Francis 2019-04-30 18:10 ` KONRAD Frederic 2019-04-30 18:10 ` KONRAD Frederic 2019-04-29 12:43 ` Philippe Mathieu-Daudé 2019-04-29 12:43 ` Philippe Mathieu-Daudé 2019-04-29 17:01 ` Alistair Francis 2019-04-29 17:01 ` Alistair Francis 2019-04-30 15:51 ` Peter Maydell 2019-04-30 15:51 ` Peter Maydell 2019-04-30 15:59 ` Peter Maydell 2019-04-30 15:59 ` Peter Maydell 2019-05-02 5:04 ` Alistair Francis 2019-05-02 5:04 ` Alistair Francis 2019-04-29 5:33 ` [Qemu-devel] [PATCH v1 5/5] hw/arm: Add the Netduino Plus 2 Alistair Francis 2019-04-29 5:33 ` Alistair Francis 2019-04-30 16:01 ` Peter Maydell 2019-04-30 16:01 ` Peter Maydell 2019-04-30 20:27 ` Alistair Francis 2019-04-30 20:27 ` Alistair Francis 2019-05-02 10:05 ` Peter Maydell 2019-05-02 10:05 ` Peter Maydell 2019-05-04 4:25 ` Alistair 2019-05-04 4:25 ` Alistair 2019-05-04 5:25 ` Alistair Francis 2019-05-04 5:25 ` Alistair Francis 2019-05-05 15:34 ` Peter Maydell 2019-05-05 15:34 ` Peter Maydell 2019-06-19 1:04 ` Alistair Francis
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='CAFEAcA_T7-+de9=V=hnku9f0BXdpLfz6wLFFZYp9LyYDx2KLCw@mail.gmail.com' \ --to=peter.maydell@linaro.org \ --cc=alistair23@gmail.com \ --cc=alistair@alistair23.me \ --cc=qemu-devel@nongnu.org \ /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: linkBe 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).