From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhSEm-0005oC-1h for qemu-devel@nongnu.org; Tue, 06 Sep 2016 22:05:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhSEh-0008Ef-1E for qemu-devel@nongnu.org; Tue, 06 Sep 2016 22:05:14 -0400 Date: Wed, 7 Sep 2016 12:02:55 +1000 From: David Gibson Message-ID: <20160907020254.GG2780@voom.fritz.box> References: <1472661255-20160-1-git-send-email-clg@kaod.org> <1472661255-20160-4-git-send-email-clg@kaod.org> <20160905033909.GA3816@voom.fritz.box> <4e91a240-3a44-d96d-fb6e-74d9637ccd92@kaod.org> <1473198349.8689.36.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rV8arf8D5Dod9UkK" Content-Disposition: inline In-Reply-To: <1473198349.8689.36.camel@kernel.crashing.org> Subject: Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: =?iso-8859-1?Q?C=E9dric?= Le Goater , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf --rV8arf8D5Dod9UkK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 07, 2016 at 07:45:49AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-09-06 at 16:42 +0200, C=E9dric Le Goater wrote: > > > Alternatively.. it might be simpler to just drop the SCOM as a > > > separate device.=A0 I think you could just hang the scom bus directly > > > off the chip object.=A0 IIUC the scom is basically the only chip- > > level > > > control mechanism, so this does make a certain amount of sense. > >=20 > > yes. I am exposing more and more stuff of the chip object under the=A0 > > xscom object so we should merge them. I agree. We will still need=A0 > > some XScomDevice of some sort. >=20 > What you can do is split it this way which matches the HW: >=20 > =A0- The chip object is the XSCOM parent, it owns the XSCOM bus, > and expose functions (methods) to read/write XSCOMs. WE could rename > XSCOM to "PIB" or "PCB" which is the real name of the bus ;-) But that > might confuse things more than help . >=20 > =A0- A separate ADU object on each chip that is a SysDevice and does the > MMIO bridge to XSCOM. It decodes the MMIO range for that chip and calls > the above accessors. >=20 > That makes it easy to generate XSCOMs using different mechanisms if we > wish to do so, which could come in handy, such as monitor commands, or > if we ever do cosimulation with a separate BMC, a simulated FSI, all by > just calling the first object's methods. Not what I had in mind - I still was thinking of having the xscom access unit do the translation and re-issue into the pcb bus address space. But sounds like this other approach could have some advantages. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --rV8arf8D5Dod9UkK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJXz3VOAAoJEGw4ysog2bOS0ssQAMkvOPNPbSdoOR1ZAaaDRAep IQmNytLdZJw6ZwEvEBVTmAgV8FZI0tEtidGgfk5gykRDgzXwWPGlNPMIsUYroLCy E79I0Hqp1K1Xgyi3wh8a5E3gk2UxAiARq7iFWslYU6ydAg72dMQVuiBL+7Oekpdh 4KOjUVySrvAk3X8HMEAiS78Z1hTbM1o39DM1fqVwyK0uqrH0P2/DwPlkzhGYIMho SAU/GtjepXeHke6XdP1wUqRnXTBsnozwaJOPj1pAYpTcoM4NDi9hzi2sHDnoaQ4G MQKWPuzBiIB8F1NLeN/FceN6GjOcQtAWul674Of7f2ClbA5m+vWVP4LT8zdGUfft FeyyJhdJsEq5jyF39fe8R1B0ajdXf3sS16/MFLQk31mOnGMpNXjo/tZQFz5UjBCE 6ZxDIqjwHw0wtvNCL5J9muTK0J+x3D5i60AvSpWsJKoFr+m9RoQx/Qg7fMbDHAIZ i1MUFyAmOd/7ZVTZLSJt6Om9B8llcxpx7peeaMI5fJlqdVQZ2TLvJLKa+eFQkMJh /C5GWXCq7Wr51+y9BKoTFflSHgHlyhAiAxRoKZun6ram1I8AZSix/8tN+7FdEnKg V5/MjjbeWwfZuEDLL27lYMb6IesoIUrP38aPRYQK5fXHpbxzhqfev7PVsf+FapRc OfoFu4KBqOl9nPwyxB34 =GxEf -----END PGP SIGNATURE----- --rV8arf8D5Dod9UkK--