From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LzuaD-0005DF-Pp
	for qemu-devel@nongnu.org; Fri, 01 May 2009 11:23:25 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lzua8-0005Bz-OJ
	for qemu-devel@nongnu.org; Fri, 01 May 2009 11:23:24 -0400
Received: from [199.232.76.173] (port=55056 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lzua8-0005Bw-Hw
	for qemu-devel@nongnu.org; Fri, 01 May 2009 11:23:20 -0400
Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]:43821)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <reif@earthlink.net>) id 1Lzua8-00007A-B0
	for qemu-devel@nongnu.org; Fri, 01 May 2009 11:23:20 -0400
Message-ID: <49FB1302.4090904@earthlink.net>
Date: Fri, 01 May 2009 11:19:30 -0400
From: Robert Reif <reif@earthlink.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7
References: <49EDB109.5010009@earthlink.net>
	<200905011514.21072.paul@codesourcery.com>
	<49FB09B9.7020701@earthlink.net>
	<200905011552.48991.paul@codesourcery.com>
In-Reply-To: <200905011552.48991.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

Paul Brook wrote:
>> Here is a patch for most of the sparc32 hardware drivers.  It's
>> a very trivial and mechanical process for these drivers.  The one
>> driver that does 64 bit accesses just adds 64 bit access functions
>> because it's broken now and has no workaround to remove.  I don't
>> think converting most other drivers will be much harder.
>>     
>
> sparc hardware is rather abnormal (for qemu at least) because it cares what 
> happens when you use the wrong width. Most devices don't care, and having any 
> NULL functions is liable to introduce significant overhead.
>
> Paul
>
>   
Ok, so that explains the curious code in m48t59.c:

static void nvram_writeb (void *opaque, target_phys_addr_t addr, 
uint32_t value)
{
    m48t59_t *NVRAM = opaque;

    m48t59_write(NVRAM, addr, value & 0xff);
}

static void nvram_writew (void *opaque, target_phys_addr_t addr, 
uint32_t value)
{
    m48t59_t *NVRAM = opaque;

    m48t59_write(NVRAM, addr, (value >> 8) & 0xff);
    m48t59_write(NVRAM, addr + 1, value & 0xff);
}

static void nvram_writel (void *opaque, target_phys_addr_t addr, 
uint32_t value)
{
    m48t59_t *NVRAM = opaque;

    m48t59_write(NVRAM, addr, (value >> 24) & 0xff);
    m48t59_write(NVRAM, addr + 1, (value >> 16) & 0xff);
    m48t59_write(NVRAM, addr + 2, (value >> 8) & 0xff);
    m48t59_write(NVRAM, addr + 3, value & 0xff);
}

So nvram_writeq should be present on non sparc architectures
and actually should be doing 8 byte accesses?  How do we handle
architecture differences like this?  On sparc, it looks like the
sbus controller does this because the actual hardware really
only has an 8 bit bus.