From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhSEJ-0005RF-09 for qemu-devel@nongnu.org; Tue, 06 Sep 2016 22:04:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhSEE-00082u-Bo for qemu-devel@nongnu.org; Tue, 06 Sep 2016 22:04:45 -0400 Date: Wed, 7 Sep 2016 12:01:19 +1000 From: David Gibson Message-ID: <20160907020119.GF2780@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> <1473059513.2313.44.camel@kernel.crashing.org> <20160906004847.GB2900@voom.fritz.box> <3af4c2d9-7263-7c54-0a12-c0b4108c65bd@kaod.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rMWmSaSbD7nr+du9" Content-Disposition: inline In-Reply-To: <3af4c2d9-7263-7c54-0a12-c0b4108c65bd@kaod.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: =?iso-8859-1?Q?C=E9dric?= Le Goater Cc: Benjamin Herrenschmidt , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf --rMWmSaSbD7nr+du9 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 06, 2016 at 04:42:58PM +0200, C=E9dric Le Goater wrote: > On 09/06/2016 02:48 AM, David Gibson wrote: > > On Mon, Sep 05, 2016 at 05:11:53PM +1000, Benjamin Herrenschmidt wrote: > >> On Mon, 2016-09-05 at 13:39 +1000, David Gibson wrote: > >>>> +static XScomDevice *xscom_find_target(XScomState *s, uint32_t > >>> pcb_addr, > >>>> + uint32_t *range) > >>>> +{ > >>>> + BusChild *bc; > >>>> + > >>>> + QTAILQ_FOREACH(bc, &s->bus->bus.children, sibling) { > >>>> + DeviceState *qd =3D bc->child; > >>>> + XScomDevice *xd =3D XSCOM_DEVICE(qd); > >>>> + unsigned int i; > >>>> + > >>>> + for (i =3D 0; i < MAX_XSCOM_RANGES; i++) { > >>>> + if (xd->ranges[i].addr <=3D pcb_addr && > >>>> + (xd->ranges[i].addr + xd->ranges[i].size) > > >>> pcb_addr) { > >>>> + *range =3D i; > >>>> + return xd; > >>>> + } > >>>> + } > >>>> + } > >>> > >>> Hmm.. you could set up a SCOM local address space using the > >>> infrastructure in memory.c, rather than doing your own dispatch. > >> > >> There are pros and cons to this approach. The memory.c stuff comes with > >> quite a lot of baggage, not all of it very shinny to be honest ;-) I > >> still *hate* how it forces upon us a whole 128-bit integer arithmetic > >> library just so that it can represent 1_0000_0000_0000_0000 ...=20 > >=20 > > Ugh, yeah. I tried to argue against this when it first came in, but > > was overruled. > >=20 > >> It would be make more sense to use inclusive start/end instead and > >> stick to 64-bits. > >> > >> That being said, we could do that. We'd have to shift the XSCOM > >> addresses left by 3 since each address is an 8 bytes reigster and > >> forbid non-8-bytes accesses. > >=20 > > Ok. I'm not particularly fussed either way. >=20 >=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=20 > dependency on the chip model because the translation is different.=20 > That would be an extra op in the xscom device model I guess.=20 Actually, I was still thinking of having an MR for the scom interface unit, which does the xscom_to_pcb_addr() then re-issues the access in the PCB address space. But your suggestion might work too. > Also, the main purpose of the XscomBus is to loop on the devices=20 > to populate the device tree. I am wondering if we could just use=20 > a simple list under the chip for that purpose.=20 >=20 > Thanks, >=20 > C.=20 >=20 --=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 --rMWmSaSbD7nr+du9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJXz3TvAAoJEGw4ysog2bOSSEoQALeelh6hASTd5gUAEijMv41p 2Sv0sSTfSSlDux/z2/aFXhnhLaP+BDs3GcH563g1nEzv2SpZKFRnnlHPNjyFq+yF DldKxCfdSy1OKEGO+N8lON4h7tcYl255w2TWWNJ1S51y1WE20fC5F+gADa2TvxKM HN5SEgjiXCoIRmeNJCj1PLeIfaSnzd8vQx39+FC+lHZUYMavCGS922xpIsOoWiXn Q/O9vfwlbhp9BnYZK2H/JQkGuvACPehxS6TUuj2o1CEusc2UEgreOSTb4f+fWd2/ eeCAojl8L+V8CQ3+oNKPJ/JKxoZzDDnMJv76Slvom8GxoXDAoMA+oRSOvWYpBwiL Vm1mi/2wg+Cmaz7e8IvsDxa4FLgOzYnEGPtj8uQHotLkLOOwZky9wmCCtPHBMHbM WMyJiZFxYdnVUHyCcrURgdWB0CKcr92AMHR/CnP+R80yM11FPrc4yv7Xv+nvC/A/ jKIe7PvehD0pfNdgwtDq5Fe7hXfJkLK34tiofPx1AmptpN+pccwZ+UdOrCYf2qD1 b9msioXbqVDDJat3Ea9Znnip6qPEb55vwR0gFqWWIBHwUL3kJvTg07mA1ClQ9S1Y rinoljQnbeu4CgHdLwbnSQ3GjBVSrYG1Z8rNNY39SRnLD/Juz252JmugJhKZzcmG 4ynkReXJtirOOuOgUgbp =Y90l -----END PGP SIGNATURE----- --rMWmSaSbD7nr+du9--