qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 09/24] omap_gpmc/nseries/tusb6010: convert to me


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 09/24] omap_gpmc/nseries/tusb6010: convert to memory API
Date: Tue, 09 Aug 2011 09:34:31 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0

On 08/08/2011 08:43 PM, Peter Maydell wrote:
On 8 August 2011 18:06, Avi Kivity<address@hidden>  wrote:
>  Somewhat clumsy since it needs a variable sized region.

>  @@ -119,7 +120,7 @@ void omap_sdrc_reset(struct omap_sdrc_s *s);
>    struct omap_gpmc_s;
>    struct omap_gpmc_s *omap_gpmc_init(target_phys_addr_t base, qemu_irq irq);
>    void omap_gpmc_reset(struct omap_gpmc_s *s);
>  -void omap_gpmc_attach(struct omap_gpmc_s *s, int cs, int iomemtype,
>  +void omap_gpmc_attach(struct omap_gpmc_s *s, int cs, MemoryRegion *iomem,
>                   void (*base_upd)(void *opaque, target_phys_addr_t new),
>                   void (*unmap)(void *opaque), void *opaque);

I have a pile of omap_gpmc patches almost ready to submit which
are mostly waiting on my figuring out how to get them to work
with the new memory API.

In particular I think this is wrong -- omap_gpmc_attach should
just take a MemoryRegion*, and there should be standard APIs
for "resize this memory region" and "unmap this memory region",
[we have the latter but not the former currently], at which point
there's no need to pass in base_upd or unmap function pointers.


I agree we need better support for this in the core. But I'm limiting core updates so I can continue to convert users, without which the entire effort is useless, and so I can collect additional requirements.

Also, my patchset focuses on mechanical transformations. It is already risky enough in terms of regressions, I'm not going to rewrite/improve all of qemu; if you want those callbacks removed, you will have to remove them yourself.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]