From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDZf3-0005oC-R1 for qemu-devel@nongnu.org; Tue, 20 Jan 2015 09:20:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDZf3-0001WH-0H for qemu-devel@nongnu.org; Tue, 20 Jan 2015 09:20:05 -0500 Message-ID: <54BE63E2.5060802@ilande.co.uk> Date: Tue, 20 Jan 2015 14:19:14 +0000 From: Mark Cave-Ayland MIME-Version: 1.0 References: <1421667328-11800-1-git-send-email-mark.cave-ayland@ilande.co.uk> <54BD7E35.40108@reactos.org> In-Reply-To: <54BD7E35.40108@reactos.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/2] m48t59: add year offset and MMIO ISA mapping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, agraf@suse.de, afaerber@suse.de, atar4qemu@gmail.com On 19/01/15 21:59, Hervé Poussineau wrote: > Le 19/01/2015 12:35, Mark Cave-Ayland a écrit : >> This patch lays the groundwork for switching sun4u over from ioport NVRAM >> access to MMIO NVRAM access. >> >> Patch 1 introduces a new year_offset property which is the offset >> between the >> year value stored in hardware and the actual year. In particular, Sun >> hardware >> has a 68 year offset used to extend the date range of the IC. While the >> kernel sources I have viewed contain this offset within a #ifdef >> CONFIG_SPARC >> block, I've updated all the callers so that no change in behaviour >> will be >> seen across all platforms. PPC users may wish to alter the callers to >> change >> this behaviour as required. >> >> Patch 2 mimics the mem_base parameter from m48t59_init() to >> m48t59_init_isa() >> so that MMIO can be used for sun4u where the NVRAM is attached to the >> ebus >> which is essentially the same as an ISA bus. > > I've a patch which QOM'ifies m48t59, that I'll send to the list. > If you apply it, you'll be then able to create a sysbus-m48t02 device, > and then to add it to ebus memory region. > IMO, there is no need to add a new parameter to m48t59_init_isa device. > > Tell me what do you think of it. It took me a while to go through these patches, but yes I think that would work (i.e. create the sysbus-m48t59 device and then map it's MemoryRegion directly into I/O space). If these patches can be applied then I'm happy to rebase and resubmit my patchset for the year_offset property. Who's tree should these changes go through? Andreas' QOM tree? ATB, Mark.