Date: Thu, 21 Apr 2016 13:53:28 +0800 (CST) From: pagaled1 <pagaled1@saifunguo.com> To: freebsd-arch@FreeBSD.org Subject: Enquiry Paragliding Message-ID: <2e30a0a1.a2fb.15437615df3.Coremail.pagaled1@saifunguo.com>
next in thread | raw e-mail | index | archive | help
RGVhciBDRU8sCiAgICAgICAKUGxlYXNlIHNlZSB0aGUgYXR0YWNobWVudCBvZiBQYXJhZ2xpZGlu Zy4KCgoKCi0tCgpCZXN0IHJlZ2FyZHMKCgoKClVzaGVyIENhZ2UKClRlbKO6IDAwODYtNzU1LTM2 NjIxNzM2CgpNb2IgIDowMDg2LTE1OSA4OTQ0IDExNzUKCkUtbWFpbDogYWRtaW5AcGFnYWxlZC5j b20KCiAgICAgICAgICAgICB1c2hlckBwZWdhbGVkLmNvbQ== From owner-freebsd-arch@freebsd.org Fri Apr 22 19:01:46 2016 Return-Path: <owner-freebsd-arch@freebsd.org> Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B78C4B192D5 for <freebsd-arch@mailman.ysv.freebsd.org>; Fri, 22 Apr 2016 19:01:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92F8519C6 for <freebsd-arch@freebsd.org>; Fri, 22 Apr 2016 19:01:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C0D6B96C for <freebsd-arch@freebsd.org>; Fri, 22 Apr 2016 15:01:45 -0400 (EDT) From: John Baldwin <jhb@freebsd.org> To: 'freebsd-arch' <freebsd-arch@freebsd.org> Subject: bus_map_resource Date: Fri, 22 Apr 2016 11:54:53 -0700 Message-ID: <4660875.ZpJTJgz4hU@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 22 Apr 2016 15:01:45 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 22 Apr 2016 19:01:46 -0000 Yet another extension I've long wanted to make to new-bus is to split out the part of bus_activate_resource() that establishes a valid mapping for use with bus_space_* (or the bus_* wrappers) from activating / detactivating. In particular, making a resource "active" is orthogonal to having a mapping (e.g. for a PCI BAR, a resource is "active" if the appropriate IO or mem decoding bit is set in the device's command register. Whether or not the CPU has a valid mapping for that range doesn't matter). Secondly, there is a need to be able to specify optional parameters of mappings. Some drivers may wish to only map a portion of a resource instead of all of it (e.g. the AGP driver wishes to only map the first page of the aperture instead of all of the aperture to avoid wasting a lot of KVA on 32- bit systems). Some drivers may wish to map a memory resource with non-default memory attributes (e.g. WC). I have a strawman with an implementation on x86 to permit this. In this model, a new RF_UNMAPPED flag is added that asks bus_activate_resource() to not setup the implicit mapping in 'struct resource'. Instead, a driver requests explicit mappings via bus_map_resource() and is responsible for calling bus_unmap_resource() to tear them down. A driver should allocate a 'struct resource_map' for each mapping (probably by putting it in its softc) and then passing a pointer to that object to both routines. This structure's members are named so that you can use the bus_* convenience API on it the same way you can with 'struct resource' for the implicit mapping. bus_map_resource() accepts an optional 'args' argument that defines optional properties of the mapping request. A driver can request a mapping of a subset of a resource or a specific memory attribute. The 'args' argument is defined as a structure headed by a size similar to the scheme Konstantin recently used for make_dev_s(). One use case for this is that I'd like to fix the NEW_PCIB bits in the PCI-PCI bridge driver to request a mapping in the subset of the resource on the "parent" bus for the mapping window used by a resource for a child device instead of passing up that child resource directly to the nexus. The idea is that any bus driver that creates its own rman and resources should not be passing those resources up to any of its parents. Another use case that would benefit from this are bridges that do address translations (such as the ThunderX Host-PCI bridge driver recently committed). It can allocate a resource from its parent representing the "parent" side of its resource window and request mappings for regions of that window corresponding to child resources when creating mappings of child resources. What I'd like feedback on now is the API. If we decide to go forward I would also like help fixing bus drivers to use this. Some sample code for mapping a resource that uses a WC mapping: struct foo_softc { ... struct resource *sc_regs_res; struct resource_map sc_regs; ... }; foo_attach(device_t dev) { struct resource_map_request args; ... sc->sc_regs_res = bus_alloc_resource(dev, ..., RF_ACTIVE | RF_UNMAPPED); resource_init_map_request(&args, sizeof(args)); args.memattr = VM_MEMATTR_WRITE_COMBINING; error = bus_map_resource(dev, SYS_RES_MEMORY, sc->regs_res, &args, &sc->sc_regs); ... } foo_something(struct foo_softc *sc) { x = bus_read_4(&sc->sc_regs, MY_CSR); } foo_detach(device_t dev) { bus_unmap_resource(dev, SYS_RES_MEMORY, sc->regs_res, &sc->sc_regs); bus_release_resource(dev, SYS_RES_MEMORY, rman_get_rid(sc->regs_res), sc->regs_res); } There is a review with the current WIP code that includes the API and an implementation for x86. It does not yet have manual page updates. https://reviews.freebsd.org/D5237 -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2e30a0a1.a2fb.15437615df3.Coremail.pagaled1>