From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:43648)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TReON-00028Z-7M
	for qemu-devel@nongnu.org; Fri, 26 Oct 2012 03:31:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TReOM-0000tX-CB
	for qemu-devel@nongnu.org; Fri, 26 Oct 2012 03:31:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:54827)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TReOM-0000tT-3n
	for qemu-devel@nongnu.org; Fri, 26 Oct 2012 03:31:42 -0400
Message-ID: <508A3C58.3090805@redhat.com>
Date: Fri, 26 Oct 2012 09:31:36 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <CAEgOgz4q1oA=W2yktQ0SgZ_3WTjT9DZaDqB3r-0nfod0m1QX8Q@mail.gmail.com>
In-Reply-To: <CAEgOgz4q1oA=W2yktQ0SgZ_3WTjT9DZaDqB3r-0nfod0m1QX8Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, John Williams <john.williams@xilinx.com>, "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>

  Hi,

> For actually writing into the device registers, its just uses an array
> index, no need to switch (ret = s->regs[addr]). However for my side
> effects I will need to populate that switch. If we convert to fine
> grained memory regions then the switch goes away and my side effect
> become pretty, but my register update becomes ugly as each individual
> handler needs to index into s->regs with a constant index for the
> actual read.

In hw/intel-hda.c I went for a simliar approach (predating memory api
though).  There is a struct describing each register.  Which bits are
writable, which bits are write-1-to-clear, what is the state after
reset, what is the offset in IntelHDAState.  Alot of the access logic
can be in generic code then.

There are also (optional) per-register read/write handlers.  read
handlers rarely needed, only for registers generating content on access
such as timers.  write handlers are needed for most registers, but
certainly not all of them.  read-only registers obviously can go
without, likewise registers which hold the dma address of some data
structures.

Feel free to steal ideas there.

cheers,
  Gerd