Date: Sun, 08 Sep 2002 13:16:33 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: bms@spc.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? Message-ID: <20020908.131633.124488233.imp@bsdimp.com> In-Reply-To: <20020908190057.GE3235@spc.org> References: <20020906093215.GI15218@spc.org> <20020906.235110.108188889.imp@bsdimp.com> <20020908190057.GE3235@spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20020908190057.GE3235@spc.org>
Bruce M Simpson <bms@spc.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020908.131633.124488233.imp>