Date: Sat, 11 Oct 1997 19:00:01 +0930 From: Mike Smith <mike@smith.net.au> To: "Fred L. Templin" <templin@erg.sri.com> Cc: freebsd-hackers@freebsd.org Subject: Re: pccard driver questions (FreeBSD 2.2.2-RELEASE + PAO-970616) Message-ID: <199710110930.TAA01051@word.smith.net.au> In-Reply-To: Your message of "Fri, 10 Oct 1997 13:15:15 MST." <199710102015.NAA01520@grayling.erg.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Redirected to -hackers, where IMHO this really belongs.
> So, in short, I need to be able to use 'uiomove()' to copy data/commands
> into/out of the card's common memory space from an application using the
> open, close read, write, and ioctl semantics and I need to be able to switch
> between attribute memory space and ccommon memory space. But, in order to do
> this I need to manipulate the per-slot window mappings which get set up when
> the card is found by pccardd and which are managed by the slot controller
> code in sys/pccard/{pccard,pcic}.c and my fear is that by doing so I would
> risk a system crash if a pccard event caused the slot controller code to
> yank it's resource allocations out from under my driver while it was
> accessing them.
I'm not sure I understand why you want to manipulate the per-slot
mappings. The card offers a window of some fixed size, which you can
relocate over its internal address space, correct? If this is the
case, then you only map this window once, and subsequently fiddle the
cards internals to shift the window around.
> running" which makes me nervous about following their model. So my first
> question is - how can I write a driver for a memory-mapped PCMCIA card
> which can disassociate itself from the slot controller driver when the
> device is probed, yet still allow me to manipulate the per-slot window
> mappings?
Again I'm not sure I understand why you want this dissociation. You
are concerned with what will happen if the card is ripped out from
under you, which is fair enough. You can expect something like the
following sequence:
- talking to card, all is OK.
- card is removed.
- talking to card, not responding.
- driver removal hook is called.
Effectively, you will need to code your driver defensively; you should
be prepared to handle completely bogus responses from the card on the
basis that shortly after the bogus response you will receive removal
notification.
You can test this behaviour very easily once you have the skeleton of
your driver running; poll an address on a fast timeout, rip the card
and see how many polls (if any) you get with a bogus value before your
removal hook is called.
Note that it's possible (not having checked the code) that the memory
mapped for the card is revoked before the removal hook is called (it
shouldn't be, but it might). If that's the case, polling as above may
cause a kernel fault, and the unmapping will have to be fixed.
> statically-allocated "slot_ctrl" struct). Is it true that FreeBSD
> currently only supports one slot controller chip (which controls two
> slots), or am I missing something? (I'm hoping the folks working on
> -current might have some knowledge on this...)
FreeBSD currently only supports one controller; docking bays with extra
PCICs are a relatively new innovation, and the PCCARD code is a little
older than that.
mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710110930.TAA01051>