Date: Tue, 9 Jan 2001 20:39:39 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Wemm <peter@netplex.com.au> Cc: Wilko Bulte <wkb@freebie.demon.nl>, freebsd-alpha@FreeBSD.ORG Subject: Re: debugging fpa / FDDI panic Message-ID: <14939.47709.724577.4054@grasshopper.cs.duke.edu> In-Reply-To: <200101062231.f06MVCq68942@mobile.wemm.org> References: <14935.34600.806565.787237@grasshopper.cs.duke.edu> <200101062231.f06MVCq68942@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm writes: > > Actually, what I think we should be doing is the same as how the interrupt > resources are handled... ie: seperate allocation and activation. > > ie: res = bus_alloc_resource(dev, SYS_RES_IRQ, ....) > bus_setup_intr(dev, res, flags, irqhandler, handlerargs, &irqhandle); > > IMHO, we should do the same with memory and IO space. > we presently have: > res = bus_alloc_resource(dev, SYS_RES_MEMORY, ...., RF_ACTIVE|magic_flags); > va = rman_get_virtual(res); > IMHO, this is wrong. We are allocating space within the scope of the bus > and expecting it to silently appear in CPU addressable space and then use > backdoor methods to grab it. > > I think it would be better like this: > > res = bus_alloc_resource(dev, SYS_RES_MEMORY, .... RF_ACTIVE) > bus_map_space(dev, res, magicflags, &bushandle, &bustag, &mappinghandle); > > or something along those lines. > > The allocation would be to reserve the space in the bus, and the > bus_map_space() would be to arrange for it to appear into CPU addressable > space, get the handles, choose convenient mapping modes (dense or sparse - > this is a CPU/core chipset *mapping* property, not a "pci bus resource" > property). The pci space on the alphas appears in several forms in the CPU > space. <...> I think I agree with you for the most part. Layering violations don't concern me as much as they probably should. The only caveat that I have is that the "magicflags" should not be platform dependent. A reasonably well written driver should work without the author having to or in different flags for each platform. Eg, there should be something like RF_MEMORYLIKE and RF_BUSLIKE. (Bad names, I know). RF_MEMORYLIKE means your going to treat the space like memory and do loads/stores from/to it (bad practice, but damned convenient sometimes). RF_BUSLIKE means you promise to go through the buspace interfaces. My main objection is rman_get_virtual() returning an address which will cause a memory management fault if you load or store from/to it on an alpha. This is a big POLA for a driver author. :-( Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14939.47709.724577.4054>