From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 05/14] lib: Add I/O map cache implementation Date: Thu, 10 Jan 2013 11:25:44 +0100 Message-ID: <20130110102544.GA5546@avionic-0098.adnet.avionic-design.de> References: <1357764194-12677-1-git-send-email-thierry.reding@avionic-design.de> <20130109231758.GA27065@obsidianresearch.com> <20130110071937.GG15212@avionic-0098.adnet.avionic-design.de> <201301100917.19577.arnd@arndb.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0857543750375467300==" Return-path: In-Reply-To: <201301100917.19577.arnd-r2nGTMty4D4@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Arnd Bergmann Cc: Russell King , linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Jason Gunthorpe , Bjorn Helgaas , linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Murray , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org --===============0857543750375467300== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 10, 2013 at 09:17:19AM +0000, Arnd Bergmann wrote: > On Thursday 10 January 2013, Thierry Reding wrote: > > On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote: > > > On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote: > > > You could decrease the size of the mapping to only span the bus > > > numbers that are configured for use via DT. > >=20 > > That won't work, unfortunately. The mapping is such that the bus number > > is not encoded in the uppermost bits, the extended register number is. > > So the only thing that we could do is decrease the size of the extended > > register space for *all* devices. >=20 > But you could still a method to map 16 separate areas per bus, each 65536 > bytes long, which results in 1MB per bus. That is probably ok, since > very few systems have more than a handful of buses in practice. >=20 > In theory, doing static mappings on a per-page base would let you > do 16 devices at a time, but it's probably worth doing at this fine > granularity. I don't understand how this would help. The encoding is like this: [27:24] extended register number [23:16] bus number [15:11] device number [10: 8] function number [ 7: 0] register number So it doesn't matter whether I use separate areas per bus or not. As soon as the whole extended configuration space needs to be accessed a whopping 28 bits (256 MiB) are required. What you propose would work if only regular configuration space is supported. I'm not sure if that's an option. > > > Are there any concerns about these config registers being accessed > > > from a context where a new mapping can't be made? Interrupt? Machine > > > Check? PCI-E Advanced Error Reporting? > >=20 > > I haven't checked but I would expect configuration space accesses to not > > happen in interrupt context. Usually they are limited to enumeration and > > driver probe. >=20 > Actually, AER probably needs this, and I believe some broken devices=20 > need to mask interrupts using the PCI command word in the config space, > it it can happen. Ugh... that would kill any such dynamic mapping approach. Perhaps if we could mark a device as requiring a static mapping we could pin that cache entry. But that doesn't sound very encouraging. Thierry --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQ7pcoAAoJEN0jrNd/PrOhzWAQAJU8h6+cUFml8Y/ItAuxpx7X 4JokweZ46zAbLIRfTn7XVX7ICa80iPbgf0eJjno2w9mDpr1NA6DUvNg4/IWncM1t 3yQngkKc98gz0rRV7wjpzlTav8q1W5KjTK4WexEX+n6Z6rsjAtlxIzViAvSPOekH Nr/oHRaAYirdndAH8dmL8aifZKayaHDKYtVCIJ2xQOXTyplwZYIN5DWFWs4pdHta IE5ZUTc5qf8djpvrlIcjBrPPVSxS6B/04uU9ovbFxbrqIGhnnwfqlYNiU+j+p57x sRV0QsXk0XwAPvAdD3JzQsSB2U6ZEKlDleOWNO3yhFWobFQrLF9zktzm4wIvooo6 e4aekihXMHjCN2CjRl7dk/NXw2dyFY4AIc1YEdDuXXt3N8eUhamvDVV9RMvx80wK CiiKA1M1SuEqHRKK7CBPSrGMBo3alogKNwAtPPfqAjPaiELtkmgjOGa4x/rzmVBH M4VsH/C+p231Hg5vdQ+GKYgPEV0OYZ90BJpGUSZMeYliAroVenXgo37NDozD+Mdu hW8lmae/L10twv36bZu720P16aU9RF60Mqa7x/RpLePt112VgyAA6vTc5V0ARGF5 Im4zjmaPp6vG67byaXXJb5aokg0sIfo1ezFnS6oMrqV8Wg+2clhWu8KQ7JTcDjPV UhtFN0S5FBlhiZigRKGN =sViQ -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- --===============0857543750375467300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org https://lists.ozlabs.org/listinfo/devicetree-discuss --===============0857543750375467300==--