From owner-freebsd-hackers Sun Sep 8 12:17: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 727FC37B400 for ; Sun, 8 Sep 2002 12:16:59 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A63AA43E42 for ; Sun, 8 Sep 2002 12:16:54 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g88JGfGq027687; Sun, 8 Sep 2002 13:16:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 08 Sep 2002 13:16:33 -0600 (MDT) Message-Id: <20020908.131633.124488233.imp@bsdimp.com> To: bms@spc.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? From: "M. Warner Losh" In-Reply-To: <20020908190057.GE3235@spc.org> References: <20020906093215.GI15218@spc.org> <20020906.235110.108188889.imp@bsdimp.com> <20020908190057.GE3235@spc.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020908190057.GE3235@spc.org> Bruce M Simpson writes: : This all works a treat. I have the driver attached and am in the process : of working the bugs out of the code. : : The ISA-routed function interrupts are firing fine with my device! : However I have yet to confirm whether this is solely due to spring-cleaning : pccard.conf - or if my ISA routing patch for the RL5C475 is making a : difference here. I still don't understand why you need ISA routed interrupts. What was wrong with sharing a PCI one? I had nothing but grief trying to make ISA interrupts even come close working on some chipsets. The fact that there's functions to make the function interrupts isa doesn't necessarily mean that they work :-(. Of course function interrupts were a little easier to route than card status change interrupts, which really want to only be PCI on some bridges. So I'm a little reluctant to integrate your patches at the present time, but that attitude might change in the fullness of time (eg, I gotta get used to the idea and revisit them in a few weeks after I've had a chance to look for other issues). : Many thanks! The only other question I have is - how would I go about : doing a bus_space_mmap() to be able to copy the attribute memory off : to a calling process? You don't need a bus_space_mmap. Once the device is memory mapped, the usual means of doing mmap work. To answer that question, let's look at the agp driver for guidance: static d_mmap_t agp_mmap; <<< declare mmap function ... static struct cdevsw agp_cdevsw = { /* open */ agp_open, /* close */ agp_close, /* read */ noread, /* write */ nowrite, /* ioctl */ agp_ioctl, /* poll */ nopoll, /* mmap */ agp_mmap, <<<< Add a mmap entry to cdevsw /* strategy */ nostrategy, /* name */ "agp", /* maj */ CDEV_MAJOR, /* dump */ nodump, /* psize */ nopsize, /* flags */ D_TTY, }; ... static int agp_mmap(dev_t kdev, vm_offset_t offset, int prot) { device_t dev = KDEV2DEV(kdev); struct agp_softc *sc = device_get_softc(dev); if (offset > AGP_GET_APERTURE(dev)) return -1; return atop(rman_get_start(sc->as_aperture) + offset); } ... So in your case, you'd get the softc for device via some means specific to your driver, check to make sure that the offset is less than 4k (since that's the size of the block of memory that you are allocating to the attribute memory) and then do the return like agp does with the appropriate attribute and/or commom memory resource. Note: if you have more than 4k in the attribute memory, and your driver moves the window around, that will impact the mmap'd memory in the application in what might seem to be unpredictable ways. Does that help at all? Warner P.S. I really should be saving all these answers, as well as Duncan's clarifications. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message