[Qemu-devel] Avoiding memory API conversion races

[Qemu-devel] Avoiding memory API conversion races

[Benoît Canet]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

The following files still contains references to cpu_register_io_memory.

hw/bonito.c
hw/lm32_sys.c
hw/lm32_timer.c
hw/lm32_uart.c
hw/mcf5206.c
hw/mcf_fec.c
hw/mcf_intc.c
hw/mcf_uart.c
hw/omap2.c
hw/omap_dma.c
hw/omap_dss.c
hw/omap_gpio.c
hw/omap.h
hw/omap_i2c.c
hw/omap_l4.c
hw/omap_lcdc.c
hw/omap_mmc.c
hw/omap_sdrc.c
hw/omap_sx1.c
hw/omap_uart.c
hw/openpic.c
hw/ppc4xx_pci.c
hw/ppce500_pci.c
hw/prep_pci.c

I'll do the following leaving omap to Peter and the rest to Avi.

hw/bonito.c
hw/lm32_sys.c
hw/lm32_timer.c
hw/lm32_uart.c
hw/mcf5206.c
hw/mcf_fec.c
hw/mcf_intc.c
hw/mcf_uart.c

Regards

Benoît

[-- Attachment #2: Type: text/html, Size: 1075 bytes --]

Re: [Qemu-devel] Avoiding memory API conversion races

[Andreas Färber]

Am 18.11.2011 15:05, schrieb Benoît Canet:
> 
> The following files still contains references to cpu_register_io_memory.

> hw/openpic.c
> hw/ppc4xx_pci.c
> hw/ppce500_pci.c
> hw/prep_pci.c
> 
> I'll do the following leaving omap to Peter and the rest to Avi.

Is this for 1.0 or 1.1? If the latter, I'll take care of prep_pci.c, I
have changes to that in my queue but they broke horribly last time I
tried to rebase.

Andreas

Re: [Qemu-devel] Avoiding memory API conversion races

[Benoît Canet]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

I believe it's 1.1.

2011/11/18 Andreas Färber <andreas.faerber@web.de>

> Am 18.11.2011 15:05, schrieb Benoît Canet:
> >
> > The following files still contains references to cpu_register_io_memory.
>
> > hw/openpic.c
> > hw/ppc4xx_pci.c
> > hw/ppce500_pci.c
> > hw/prep_pci.c
> >
> > I'll do the following leaving omap to Peter and the rest to Avi.
>
> Is this for 1.0 or 1.1? If the latter, I'll take care of prep_pci.c, I
> have changes to that in my queue but they broke horribly last time I
> tried to rebase.
>
> Andreas
>

[-- Attachment #2: Type: text/html, Size: 953 bytes --]

Re: [Qemu-devel] Avoiding memory API conversion races

[Peter Maydell]

2011/11/18 Benoît Canet <benoit.canet@gmail.com>:
> I'll do the following leaving omap to Peter and the rest to Avi.

My schedule's looking pretty stuffed full so I'm not sure I'll
have much or any time for omap in the next three months. I'll
see if I can squeeze out some time for doing this conversion,
but at some point you should just go ahead and convert the
omap devices and I'll pick up the pieces when I next rebase
my omap patchstack.

Incidentally, another cleanup that would be nice:
there are currently two users of sysbus_init_mmio_cb2():
hw/ppce500_pci.c and hw/sh_pci.c. I think these should be
rewritable to either use one memory region with some
subregions, or to expose multiple sysbus mmios for the
user to map appropriately. That would let us get rid of
the mmio_cb2 stuff completely. (cf commit 7d6e771 where
I did this for versatile_pci.c.)

-- PMM

Re: [Qemu-devel] Avoiding memory API conversion races

[Avi Kivity]

On 11/18/2011 04:38 PM, Peter Maydell wrote:

> Incidentally, another cleanup that would be nice:
> there are currently two users of sysbus_init_mmio_cb2():
> hw/ppce500_pci.c and hw/sh_pci.c. I think these should be
> rewritable to either use one memory region with some
> subregions, or to expose multiple sysbus mmios for the
> user to map appropriately. That would let us get rid of
> the mmio_cb2 stuff completely. (cf commit 7d6e771 where
> I did this for versatile_pci.c.)

Those cleanups are fine, but not through my tree please.  Each should go
through the respective maintainer, I'd like to restrict my tree to the
bare minimum needed for the conversion.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Avoiding memory API conversion races

[Benoît Canet]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

We are left with :


hw/omap2.c
hw/omap_dma.c
hw/omap_dss.c
hw/omap_gpio.c

and

hw/omap_i2c.c
hw/omap_l4.c
hw/omap_lcdc.c
hw/omap_spi.c
hw/omap_sx1.c

I'll try to do the bottom stack.

2011/11/20 Avi Kivity <avi@redhat.com>

> On 11/18/2011 04:38 PM, Peter Maydell wrote:
>
> > Incidentally, another cleanup that would be nice:
> > there are currently two users of sysbus_init_mmio_cb2():
> > hw/ppce500_pci.c and hw/sh_pci.c. I think these should be
> > rewritable to either use one memory region with some
> > subregions, or to expose multiple sysbus mmios for the
> > user to map appropriately. That would let us get rid of
> > the mmio_cb2 stuff completely. (cf commit 7d6e771 where
> > I did this for versatile_pci.c.)
>
> Those cleanups are fine, but not through my tree please.  Each should go
> through the respective maintainer, I'd like to restrict my tree to the
> bare minimum needed for the conversion.
>
> --
> error compiling committee.c: too many arguments to function
>
>

[-- Attachment #2: Type: text/html, Size: 1581 bytes --]

Re: [Qemu-devel] Avoiding memory API conversion races

[Avi Kivity]

On 11/24/2011 04:29 PM, Benoît Canet wrote:
>
> We are left with :
>
>
> hw/omap2.c
> hw/omap_dma.c
> hw/omap_dss.c
> hw/omap_gpio.c
>
> and
>
> hw/omap_i2c.c
> hw/omap_l4.c
> hw/omap_lcdc.c
> hw/omap_spi.c
> hw/omap_sx1.c
>
> I'll try to do the bottom stack.

Thanks.

Peter, please have a look at 8ed014d2553bc (and a couple of following
patches).  I don't think they'll be contentious, but they aren't the
standard stuff either.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Avoiding memory API conversion races

[Peter Maydell]

2011/11/24 Avi Kivity <avi@redhat.com>:
> Peter, please have a look at 8ed014d2553bc (and a couple of following
> patches).  I don't think they'll be contentious, but they aren't the
> standard stuff either.

Looks OK to me, but I haven't really looked very hard at the OMAP L4
code at all. Feel free to just post the patches :-)

Andrzej might have an opinion.

-- PMM

Re: [Qemu-devel] Avoiding memory API conversion races

[Benoît Canet]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

We have a common functions to refactor used in both half of the files.
omap_l4_attach

2011/11/24 Avi Kivity <avi@redhat.com>

> On 11/24/2011 04:29 PM, Benoît Canet wrote:
> >
> > We are left with :
> >
> >
> > hw/omap2.c
> > hw/omap_dma.c
> > hw/omap_dss.c
> > hw/omap_gpio.c
> >
> > and
> >
> > hw/omap_i2c.c
> > hw/omap_l4.c
> > hw/omap_lcdc.c
> > hw/omap_spi.c
> > hw/omap_sx1.c
> >
> > I'll try to do the bottom stack.
>
> Thanks.
>
> Peter, please have a look at 8ed014d2553bc (and a couple of following
> patches).  I don't think they'll be contentious, but they aren't the
> standard stuff either.
>
> --
> error compiling committee.c: too many arguments to function
>
>

[-- Attachment #2: Type: text/html, Size: 1164 bytes --]

Re: [Qemu-devel] Avoiding memory API conversion races

[Avi Kivity]

On 11/24/2011 06:47 PM, Benoît Canet wrote:
>
> We have a common functions to refactor used in both half of the files.
> omap_l4_attach

Already done.  See omap_l4_attach_region() and omap_l4_region_size().

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Avoiding memory API conversion races

[Peter Maydell]

2011/11/24 Benoît Canet <benoit.canet@gmail.com>:
>
> We have a common functions to refactor used in both half of the files.
> omap_l4_attach

I assume the idea is that omap_l4_attach() can eventually disappear
when all the l4 devices are converted to memory regions...

-- PMM

Re: [Qemu-devel] Avoiding memory API conversion races

[Avi Kivity]

On 11/18/2011 04:05 PM, Benoît Canet wrote:
>
> I'll do the following leaving omap to Peter and the rest to Avi.
>
> hw/bonito.c
> hw/lm32_sys.c
> hw/lm32_timer.c
> hw/lm32_uart.c
> hw/mcf5206.c
> hw/mcf_fec.c
> hw/mcf_intc.c
> hw/mcf_uart.c
>
>

I already have lm32_timer.c in my tree (not yet committed).  I'll commit
it and stay away from the rest here.

-- 
error compiling committee.c: too many arguments to function