From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwBbX-00024n-VK for qemu-devel@nongnu.org; Wed, 24 Aug 2011 07:26:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwBbW-0000lP-TH for qemu-devel@nongnu.org; Wed, 24 Aug 2011 07:26:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwBbW-0000lJ-MD for qemu-devel@nongnu.org; Wed, 24 Aug 2011 07:26:42 -0400 Message-ID: <4E54DFEE.6030904@redhat.com> Date: Wed, 24 Aug 2011 14:26:38 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1314180683-8227-1-git-send-email-avi@redhat.com> <1314180683-8227-12-git-send-email-avi@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/24] integratorcp: convert to memory API (RAM/flash only) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org On 08/24/2011 02:22 PM, Peter Maydell wrote: > On 24 August 2011 11:11, Avi Kivity wrote: > > @@ -108,9 +111,15 @@ static uint32_t integratorcm_read(void *opaque, target_phys_addr_t offset) > > static void integratorcm_do_remap(integratorcm_state *s, int flash) > > { > > if (flash) { > > - cpu_register_physical_memory(0, 0x100000, IO_MEM_RAM); > > + if (s->flash_mapped) { > > + sysbus_del_memory(&s->busdev,&s->flash); > > + s->flash_mapped = false; > > + } > > } else { > > - cpu_register_physical_memory(0, 0x100000, s->flash_offset | IO_MEM_RAM); > > + if (!s->flash_mapped) { > > + sysbus_add_memory_overlap(&s->busdev, 0,&s->flash, 1); > > + s->flash_mapped = true; > > + } > > } > > This is introducing a new field in the device state which is actually > just tracking s->cm_init bit 2. At least it would be, except that > in integratorcm_set_ctrl this line: > s->cm_init = (s->cm_init& ~ 5) | (value ^ 5); > > appears to be using ^ when it meant& ... > > This isn't a nak -- I'm happy for this to get committed and I'll fix > things up later, since the device doesn't have a VMStateDescription > that would be broken by the extra state field. Even with vmstate, nothing would break since the field would be recovered on restore. > (Or if I get round to > it before the series gets committed I'll send you a fix to squash > into this patch.) That would be best. Please post the &/^ fixup separately (if needed) since it isn't strictly related to the conversion. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.