From owner-freebsd-arch@FreeBSD.ORG Wed Mar 17 18:18:30 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCC961065670 for ; Wed, 17 Mar 2010 18:18:30 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A0F0C8FC1A for ; Wed, 17 Mar 2010 18:18:30 +0000 (UTC) Received: by pwj4 with SMTP id 4so1090326pwj.13 for ; Wed, 17 Mar 2010 11:18:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.210.21 with SMTP id i21mr675580wfg.265.1268849910071; Wed, 17 Mar 2010 11:18:30 -0700 (PDT) X-Originating-IP: [196.210.136.150] In-Reply-To: <201003170840.57911.jhb@freebsd.org> References: <9f206d1a1003170250r2727a55ajb636a0bdf1a2f137@mail.gmail.com> <201003170840.57911.jhb@freebsd.org> Date: Wed, 17 Mar 2010 20:18:30 +0200 Message-ID: <9f206d1a1003171118x6bf16f9crba0063c550c3b007@mail.gmail.com> From: Cole To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: PCI and Resouce question X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 18:18:30 -0000 Hi. Thanks for explaining it and making it clearer, and thanks to everyone who commented. It makes things a lot easier to understand I know now how to sort this out. Thanks again /Cole On 17 March 2010 14:40, John Baldwin wrote: > On Wednesday 17 March 2010 5:50:14 am Cole wrote: >> Hi. >> >> Sorry if this is not the correct list, I have tried posting to >> freebsd-hackers, and didnt get a response. Maybe im being stupid and >> not connecting something, or just not understanding, in which case >> sorry again. >> >> What im trying to achieve is writing to a few registers/memory >> addresses for the memory location of BAR 0 for a pci card. I do not >> want to modify the drivers source code, since it might become >> unavailable sometime in the future. So what im looking to do is write >> another kernel module, that can obtain the cards device_t structure, >> as well as the resource structure of the card. My aim is to obtain the >> resource structure so that I can then obtain the bus_tag and >> bus_handle, and use those to write to the BAR 0 memory space. >> >> My understanding is that I would use pci_find_device to obtain the >> device_t, then I think I can use bus_alloc_resource_any to obtain the >> resource, I see there used to be a bus_get_resource, but the man page >> for that no longer seems to exist, and references to it seem to have >> been removed. If there is another way or better way of doing this, >> please let me know. Also im not familiar with the specifics of >> bus_alloc_resouce_any, and I dont know if calling this function from >> another kernel module will give me the already allocated memory for >> this pci card, or will it create a new one and assign it to the BAR 0 >> register on the card? > > The PCI bus expects that only the driver calls bus_alloc_resource_any(), = and > that it only does this once. =A0bus_get_resource() does not return the ac= tual > 'struct resource *r', so it will not do you any good. =A0If you know for = certain > that the existing driver has not called 'bus_alloc_resource_any()', then = you > can call it from your module. =A0Note that if the device driver is unload= ed, the > PCI bus may unmap the resource out from under your module (the PCI bus as= sumes > that only the child device_t uses the resources, so it cleans up allocate= d > resources when a driver unloads). > > Really, the clean way to handle something like this is to have your new c= ode > to share the device_t with the other driver. =A0You can do this by using = an > approach similar to the vga_pci driver and changing the existing driver t= o > attach to your device instead. =A0So long as you propogate/emulate the pr= oper > PCI and bus methods, the child device driver can work fine with only a on= e- > line change to add a new DRIVER_MODULE() that attaches to your device as = the > bus instead of pci. =A0For, example, if your driver creates 'foo0' device= s and > the existing driver is called 'bar', you would create a new line: > > DRIVER_MODULE(bar, foo, ...); > > where the rest of the fields are copied from the existing 'DRIVER_MODULE(= bar, > pci)' line. =A0Your foo driver will have to have a higher probe priority = than > the real driver, and you will have to load your driver before the real dr= iver. > > Another alternative would be to make the real driver become the proxy dri= ver. > Attach your driver as a child of it. =A0You will have to add bus and PCI = methods > to the real driver to satisfy the needs of your device. =A0Mostly you jus= t want > this driver to have a custom methods for allocating resources where it sh= ares > a resource it has already allocated with your driver. > > -- > John Baldwin >