Re: [PATCH 2/2] hw/arm/palm.c: Encapsulate misc GPIO handling in a device
On 7/13/20 12:31 PM, Peter Maydell wrote: > On Mon, 13 Jul 2020 at 11:21, Philippe Mathieu-Daudé wrote: >> >> On 7/13/20 12:05 PM, Peter Maydell wrote: >>> On Mon, 13 Jul 2020 at 09:57, Philippe Mathieu-Daudé >>> wrote: Why not make it a generic container in the MachineState and create the container in hw/core/machine.c::machine_initfn()? >>> >>> I don't think we create containers like that for any other >>> machine, do we? >> >> No but maybe we could. Most boards have some GPIO/LED/reset switch >> button. Do all machines have a NUMA memory device? Do all machines >> have a dtb? Do all machines use NVDIMM devices? I think we have >> more machines using GPIOs than machine using NVDIMM. Anyway I don't >> mind, I was just trying to figure where this container belong on QOM. > > I think that if machines were qdev objects with the usual > reset/gpio/etc capabilities, I might have just implemented > this as part of the machine object; but they aren't, and > it didn't really seem like the right approach to create an > ad-hoc "container that sort of corresponds to the whole > machine". Also, since these machines are largely orphan > I tend to favour smaller-scale interventions that push them > in a better direction rather than more sweeping changes. Fair enough. There is something that bugs me in the MachineClass, but this is not this series fault. I guess by adding such containers in machines, we'll eventually figure out what is the best QOM design for it. Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 2/2] hw/arm/palm.c: Encapsulate misc GPIO handling in a device
On Mon, 13 Jul 2020 at 11:21, Philippe Mathieu-Daudé wrote: > > On 7/13/20 12:05 PM, Peter Maydell wrote: > > On Mon, 13 Jul 2020 at 09:57, Philippe Mathieu-Daudé > > wrote: > >> Why not make it a generic container in the MachineState and create > >> the container in hw/core/machine.c::machine_initfn()? > > > > I don't think we create containers like that for any other > > machine, do we? > > No but maybe we could. Most boards have some GPIO/LED/reset switch > button. Do all machines have a NUMA memory device? Do all machines > have a dtb? Do all machines use NVDIMM devices? I think we have > more machines using GPIOs than machine using NVDIMM. Anyway I don't > mind, I was just trying to figure where this container belong on QOM. I think that if machines were qdev objects with the usual reset/gpio/etc capabilities, I might have just implemented this as part of the machine object; but they aren't, and it didn't really seem like the right approach to create an ad-hoc "container that sort of corresponds to the whole machine". Also, since these machines are largely orphan I tend to favour smaller-scale interventions that push them in a better direction rather than more sweeping changes. thanks -- PMM
Re: [PATCH 2/2] hw/arm/palm.c: Encapsulate misc GPIO handling in a device
On 7/13/20 12:05 PM, Peter Maydell wrote: > On Mon, 13 Jul 2020 at 09:57, Philippe Mathieu-Daudé wrote: >> Why not make it a generic container in the MachineState and create >> the container in hw/core/machine.c::machine_initfn()? > > I don't think we create containers like that for any other > machine, do we? No but maybe we could. Most boards have some GPIO/LED/reset switch button. Do all machines have a NUMA memory device? Do all machines have a dtb? Do all machines use NVDIMM devices? I think we have more machines using GPIOs than machine using NVDIMM. Anyway I don't mind, I was just trying to figure where this container belong on QOM.
Re: [PATCH 2/2] hw/arm/palm.c: Encapsulate misc GPIO handling in a device
On Mon, 13 Jul 2020 at 09:57, Philippe Mathieu-Daudé wrote: > Why not make it a generic container in the MachineState and create > the container in hw/core/machine.c::machine_initfn()? I don't think we create containers like that for any other machine, do we? thanks -- PMM
Re: [PATCH 2/2] hw/arm/palm.c: Encapsulate misc GPIO handling in a device
Hi Peter,
On 6/28/20 11:42 PM, Peter Maydell wrote:
> Replace the free-floating set of IRQs and palmte_onoff_gpios()
> function with a simple QOM device that encapsulates this
> behaviour.
>
> This fixes Coverity issue CID 1421944, which points out that
> the memory returned by qemu_allocate_irqs() is leaked.
>
> Signed-off-by: Peter Maydell
> ---
> hw/arm/palm.c | 61 +++
> 1 file changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/hw/arm/palm.c b/hw/arm/palm.c
> index 569836178f6..e7bc9ea4c6a 100644
> --- a/hw/arm/palm.c
> +++ b/hw/arm/palm.c
> @@ -124,6 +124,21 @@ static void palmte_button_event(void *opaque, int
> keycode)
> !(keycode & 0x80));
> }
>
> +/*
> + * Encapsulation of some GPIO line behaviour for the Palm board
> + *
> + * QEMU interface:
> + * + unnamed GPIO inputs 0..6: for the various miscellaneous input lines
> + */
> +
> +#define TYPE_PALM_MISC_GPIO "palm-misc-gpio"
> +#define PALM_MISC_GPIO(obj) \
> +OBJECT_CHECK(PalmMiscGPIOState, (obj), TYPE_PALM_MISC_GPIO)
> +
> +typedef struct PalmMiscGPIOState {
> +SysBusDevice parent_obj;
> +} PalmMiscGPIOState;
> +
> static void palmte_onoff_gpios(void *opaque, int line, int level)
> {
> switch (line) {
> @@ -151,23 +166,44 @@ static void palmte_onoff_gpios(void *opaque, int line,
> int level)
> }
> }
>
> +static void palm_misc_gpio_init(Object *obj)
> +{
> +DeviceState *dev = DEVICE(obj);
> +
> +qdev_init_gpio_in(dev, palmte_onoff_gpios, 7);
> +}
> +
> +static const TypeInfo palm_misc_gpio_info = {
> +.name = TYPE_PALM_MISC_GPIO,
> +.parent = TYPE_SYS_BUS_DEVICE,
> +.instance_size = sizeof(PalmMiscGPIOState),
> +.instance_init = palm_misc_gpio_init,
> +/*
> + * No class init required: device has no internal state so does not
> + * need to set up reset or vmstate, and has no realize method.
> + */
> +};
> +
> static void palmte_gpio_setup(struct omap_mpu_state_s *cpu)
> {
> -qemu_irq *misc_gpio;
> +DeviceState *misc_gpio;
> +
> +misc_gpio = sysbus_create_simple(TYPE_PALM_MISC_GPIO, -1, NULL);
Why not make it a generic container in the MachineState and create
the container in hw/core/machine.c::machine_initfn()?
>
> omap_mmc_handlers(cpu->mmc,
> qdev_get_gpio_in(cpu->gpio, PALMTE_MMC_WP_GPIO),
> qemu_irq_invert(omap_mpuio_in_get(cpu->mpuio)
> [PALMTE_MMC_SWITCH_GPIO]));
>
> -misc_gpio = qemu_allocate_irqs(palmte_onoff_gpios, cpu, 7);
> -qdev_connect_gpio_out(cpu->gpio, PALMTE_MMC_POWER_GPIO,
> misc_gpio[0]);
> -qdev_connect_gpio_out(cpu->gpio, PALMTE_SPEAKER_GPIO,
> misc_gpio[1]);
> -qdev_connect_gpio_out(cpu->gpio, 11,
> misc_gpio[2]);
> -qdev_connect_gpio_out(cpu->gpio, 12,
> misc_gpio[3]);
> -qdev_connect_gpio_out(cpu->gpio, 13,
> misc_gpio[4]);
> -omap_mpuio_out_set(cpu->mpuio, 1,
> misc_gpio[5]);
> -omap_mpuio_out_set(cpu->mpuio, 3,
> misc_gpio[6]);
> +qdev_connect_gpio_out(cpu->gpio, PALMTE_MMC_POWER_GPIO,
> + qdev_get_gpio_in(misc_gpio, 0));
> +qdev_connect_gpio_out(cpu->gpio, PALMTE_SPEAKER_GPIO,
> + qdev_get_gpio_in(misc_gpio, 1));
> +qdev_connect_gpio_out(cpu->gpio, 11, qdev_get_gpio_in(misc_gpio, 2));
> +qdev_connect_gpio_out(cpu->gpio, 12, qdev_get_gpio_in(misc_gpio, 3));
> +qdev_connect_gpio_out(cpu->gpio, 13, qdev_get_gpio_in(misc_gpio, 4));
> +omap_mpuio_out_set(cpu->mpuio, 1, qdev_get_gpio_in(misc_gpio, 5));
> +omap_mpuio_out_set(cpu->mpuio, 3, qdev_get_gpio_in(misc_gpio, 6));
>
> /* Reset some inputs to initial state. */
> qemu_irq_lower(qdev_get_gpio_in(cpu->gpio, PALMTE_USBDETECT_GPIO));
> @@ -276,3 +312,10 @@ static void palmte_machine_init(MachineClass *mc)
> }
>
> DEFINE_MACHINE("cheetah", palmte_machine_init)
> +
> +static void palm_register_types(void)
> +{
> +type_register_static(_misc_gpio_info);
> +}
> +
> +type_init(palm_register_types)
>
Re: [PATCH 2/2] hw/arm/palm.c: Encapsulate misc GPIO handling in a device
Peter Maydell 于2020年6月29日周一 上午5:43写道：
>
> Replace the free-floating set of IRQs and palmte_onoff_gpios()
> function with a simple QOM device that encapsulates this
> behaviour.
>
> This fixes Coverity issue CID 1421944, which points out that
> the memory returned by qemu_allocate_irqs() is leaked.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Li Qiang
> ---
> hw/arm/palm.c | 61 +++
> 1 file changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/hw/arm/palm.c b/hw/arm/palm.c
> index 569836178f6..e7bc9ea4c6a 100644
> --- a/hw/arm/palm.c
> +++ b/hw/arm/palm.c
> @@ -124,6 +124,21 @@ static void palmte_button_event(void *opaque, int
> keycode)
> !(keycode & 0x80));
> }
>
> +/*
> + * Encapsulation of some GPIO line behaviour for the Palm board
> + *
> + * QEMU interface:
> + * + unnamed GPIO inputs 0..6: for the various miscellaneous input lines
> + */
> +
> +#define TYPE_PALM_MISC_GPIO "palm-misc-gpio"
> +#define PALM_MISC_GPIO(obj) \
> +OBJECT_CHECK(PalmMiscGPIOState, (obj), TYPE_PALM_MISC_GPIO)
> +
> +typedef struct PalmMiscGPIOState {
> +SysBusDevice parent_obj;
> +} PalmMiscGPIOState;
> +
> static void palmte_onoff_gpios(void *opaque, int line, int level)
> {
> switch (line) {
> @@ -151,23 +166,44 @@ static void palmte_onoff_gpios(void *opaque, int line,
> int level)
> }
> }
>
> +static void palm_misc_gpio_init(Object *obj)
> +{
> +DeviceState *dev = DEVICE(obj);
> +
> +qdev_init_gpio_in(dev, palmte_onoff_gpios, 7);
> +}
> +
> +static const TypeInfo palm_misc_gpio_info = {
> +.name = TYPE_PALM_MISC_GPIO,
> +.parent = TYPE_SYS_BUS_DEVICE,
> +.instance_size = sizeof(PalmMiscGPIOState),
> +.instance_init = palm_misc_gpio_init,
> +/*
> + * No class init required: device has no internal state so does not
> + * need to set up reset or vmstate, and has no realize method.
> + */
> +};
> +
> static void palmte_gpio_setup(struct omap_mpu_state_s *cpu)
> {
> -qemu_irq *misc_gpio;
> +DeviceState *misc_gpio;
> +
> +misc_gpio = sysbus_create_simple(TYPE_PALM_MISC_GPIO, -1, NULL);
>
> omap_mmc_handlers(cpu->mmc,
> qdev_get_gpio_in(cpu->gpio, PALMTE_MMC_WP_GPIO),
> qemu_irq_invert(omap_mpuio_in_get(cpu->mpuio)
> [PALMTE_MMC_SWITCH_GPIO]));
>
> -misc_gpio = qemu_allocate_irqs(palmte_onoff_gpios, cpu, 7);
> -qdev_connect_gpio_out(cpu->gpio, PALMTE_MMC_POWER_GPIO,
> misc_gpio[0]);
> -qdev_connect_gpio_out(cpu->gpio, PALMTE_SPEAKER_GPIO,
> misc_gpio[1]);
> -qdev_connect_gpio_out(cpu->gpio, 11,
> misc_gpio[2]);
> -qdev_connect_gpio_out(cpu->gpio, 12,
> misc_gpio[3]);
> -qdev_connect_gpio_out(cpu->gpio, 13,
> misc_gpio[4]);
> -omap_mpuio_out_set(cpu->mpuio, 1,
> misc_gpio[5]);
> -omap_mpuio_out_set(cpu->mpuio, 3,
> misc_gpio[6]);
> +qdev_connect_gpio_out(cpu->gpio, PALMTE_MMC_POWER_GPIO,
> + qdev_get_gpio_in(misc_gpio, 0));
> +qdev_connect_gpio_out(cpu->gpio, PALMTE_SPEAKER_GPIO,
> + qdev_get_gpio_in(misc_gpio, 1));
> +qdev_connect_gpio_out(cpu->gpio, 11, qdev_get_gpio_in(misc_gpio, 2));
> +qdev_connect_gpio_out(cpu->gpio, 12, qdev_get_gpio_in(misc_gpio, 3));
> +qdev_connect_gpio_out(cpu->gpio, 13, qdev_get_gpio_in(misc_gpio, 4));
> +omap_mpuio_out_set(cpu->mpuio, 1, qdev_get_gpio_in(misc_gpio, 5));
> +omap_mpuio_out_set(cpu->mpuio, 3, qdev_get_gpio_in(misc_gpio, 6));
>
> /* Reset some inputs to initial state. */
> qemu_irq_lower(qdev_get_gpio_in(cpu->gpio, PALMTE_USBDETECT_GPIO));
> @@ -276,3 +312,10 @@ static void palmte_machine_init(MachineClass *mc)
> }
>
> DEFINE_MACHINE("cheetah", palmte_machine_init)
> +
> +static void palm_register_types(void)
> +{
> +type_register_static(_misc_gpio_info);
> +}
> +
> +type_init(palm_register_types)
> --
> 2.20.1
>
>
