From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60933)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bhkmk-0002v8-31
	for qemu-devel@nongnu.org; Wed, 07 Sep 2016 17:53:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bhkme-0002dD-1e
	for qemu-devel@nongnu.org; Wed, 07 Sep 2016 17:53:33 -0400
Message-ID: <1473285193.8689.84.camel@kernel.crashing.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 08 Sep 2016 07:53:13 +1000
In-Reply-To: <5a384cf3-7a63-77c1-2a9b-30f81d05296e@kaod.org>
References: <1472661255-20160-1-git-send-email-clg@kaod.org>
	<1472661255-20160-4-git-send-email-clg@kaod.org>
	<20160905033909.GA3816@voom.fritz.box>
	<1473059513.2313.44.camel@kernel.crashing.org>
	<20160906004847.GB2900@voom.fritz.box>
	<3af4c2d9-7263-7c54-0a12-c0b4108c65bd@kaod.org>
	<1473198436.8689.38.camel@kernel.crashing.org>
	<5a384cf3-7a63-77c1-2a9b-30f81d05296e@kaod.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure
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: =?ISO-8859-1?Q?C=E9dric?= Le Goater <clg@kaod.org>, David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>

On Wed, 2016-09-07 at 17:47 +0200, C=C3=A9dric Le Goater wrote:
>=C2=A0
> +static uint64_t pnv_lpc_xscom_mr_read(void *opaque, hwaddr addr,
> unsigned size)
> +{
> +=C2=A0=C2=A0=C2=A0=C2=A0XScomDevice *xd =3D XSCOM_DEVICE(opaque);
> +=C2=A0=C2=A0=C2=A0=C2=A0uint64_t val =3D 0;
> +
> +=C2=A0=C2=A0=C2=A0=C2=A0pnv_lpc_xscom_read(xd, 0, xscom_to_pcb_addr(xd=
->chip_type,
> addr), &val);
> +=C2=A0=C2=A0=C2=A0=C2=A0return val;
> +}
> +
> +static void pnv_lpc_xscom_mr_write(void *opaque, hwaddr addr,
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uint64_t v=
al, unsigned size)
> +{
> +=C2=A0=C2=A0=C2=A0=C2=A0XScomDevice *xd =3D XSCOM_DEVICE(opaque);
> +=C2=A0=C2=A0=C2=A0=C2=A0pnv_lpc_xscom_write(xd, 0, xscom_to_pcb_addr(x=
d->chip_type,
> addr), val);
> +}
>=20

I don't understand. That's not at all why I suggested or I'm missing
something.

What I suggest is that you have a memory region per-chip (which is NOT
hooked onto the main address space) which represents the PCB space.
Calling xscom_region. Hook it up to its own address_space.

Thus, the various devices (LPC, OCC, etc...) all just register a sub-
region of that address space using the PCB addresses directly (well,
shifted left by 3 because it's 8 bytes registers but that's it).

The XSCOM "controller" AKA ADU is the one doing the bridge. It
registers an MMIO region in the main address space (SysBusDevice ?)
and from the MMIO accessors, it does the address mangling, and use
address_space_rw() to trigger accesses onto that chip's xscom_region.

Ben.