Date: Mon, 13 Oct 1997 10:39:49 -0700 From: "Fred L. Templin" <templin@erg.sri.com> To: Mike Smith <mike@smith.net.au> Cc: freebsd-hackers@freebsd.org, templin@erg.sri.com Subject: Re: pccard driver questions (FreeBSD 2.2.2-RELEASE + PAO-970616) Message-ID: <199710131739.KAA03124@grayling.erg.sri.com> In-Reply-To: Your message of "Sat, 11 Oct 1997 19:00:01 %2B0930." <199710110930.TAA01051@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. The problem is that the card really doesn't have any internals to shift around. It presents itself as a contiguous chunk of approx. 96KB of common memory and expects the host to write data and commands into the correct locations. Is there any other way to handle this besides re- mapping the 4KB window that gets set up when the card is inserted? > > 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. None of the above concerns me; this is the standard operating environment for a PC-CARD driver, and I understand the perils involved here. > 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. This is what concerns me; de-referencing bogus pointers while manipulating the per-slot window mappings in my driver after the slot driver disappears and takes it's data structures with it. This concern goes away if there is some other way for me to program my card besides fiddling with the window mapping, or if some mutual exclusion can be provided between the slot driver and my driver while dealing with the per-slot data structures. Any ideas on either approach would be welcome... > > 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. Mr. Hosokawa also posted a response to this in which he claims to have added support for multiple controllers in the latest test version of PAO. This is good news, and I intend to go check his new code out soon. > mike Thanks, Fred templin@erg.sri.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710131739.KAA03124>