From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45975)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bhODL-0004VV-4a
	for qemu-devel@nongnu.org; Tue, 06 Sep 2016 17:47:32 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bhODH-0002T6-VY
	for qemu-devel@nongnu.org; Tue, 06 Sep 2016 17:47:31 -0400
Message-ID: <1473198436.8689.38.camel@kernel.crashing.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 07 Sep 2016 07:47:16 +1000
In-Reply-To: <3af4c2d9-7263-7c54-0a12-c0b4108c65bd@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>
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 Tue, 2016-09-06 at 16:42 +0200, C=C3=A9dric Le Goater wrote:
>=20
> The change does seem too invasive. I can give it a try in next
> version.
>=20
> When a memory region is triggered, the impacted device will have
> to convert the address with xscom_to_pcb_addr(). There is some=C2=A0
> dependency on the chip model because the translation is different.=C2=A0
> That would be an extra op in the xscom device model I guess.=C2=A0

No. If you split the XSCOM bus from the MMIO -> XSCOM bridge (the ADU)
then the conversion only happens in the former. You don't directly
route the MMIOs over ! You intercept the MMIOs and use use the
address_space_rw to "generate" the XSCOM accesses on the other side,
like I do for the LPC bus.

We need that anyway because of the way XSCOMs can manipulate the HMER
etc...

> Also, the main purpose of the XscomBus is to loop on the devices=C2=A0
> to populate the device tree. I am wondering if we could just use=C2=A0
> a simple list under the chip for that purpose.