From owner-freebsd-mobile Fri Oct 10 14:34:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11444 for mobile-outgoing; Fri, 10 Oct 1997 14:34:24 -0700 (PDT) (envelope-from owner-freebsd-mobile) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA11357; Fri, 10 Oct 1997 14:33:27 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id XAA05727; Fri, 10 Oct 1997 23:32:18 +0200 (CEST) To: "Fred L. Templin" cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: pccard driver questions (FreeBSD 2.2.2-RELEASE + PAO-970616) In-reply-to: Your message of "Fri, 10 Oct 1997 13:15:15 PDT." <199710102015.NAA01520@grayling.erg.sri.com> Date: Fri, 10 Oct 1997 23:32:17 +0200 Message-ID: <5725.876519137@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I'm using FreeBSD 2.2.2-RELEASE with PAO-970616, and I'm writing a >new device driver for a PCMCIA card which is not currently supported in >either of these packages. The card is strictly a memory-mapped device, >and has no I/O mapping or interrupt capability. The card is programmed >by writing command(s) and data into the card's common memory space, then >setting a bit in the function configuration registers in attribute memory >space to tell the card to begin, then polling another bit in the registers >to ascertain when the card is done executing the command(s). Sounds like a linear flash card, doesn't it :-) Go for it, I have an Intel 2+ 8M card here, but have never had til to make a driver. >The only other driver I've seen in the FreeBSD source pool which seems >to want to play with 'uiomove()' and window mappings like this is >sys/i386/isa/scc.c, but the driver is rife with comments of the form: >"bad things will happen if you pull the card out while the system is >running" This you can write above any instruction which accesses a pccard. With the "surprise style" (as opposed to "VCR-style") eject mechanism the hardware may be gone without notice from one instruction to the next. Nothing you can do about it. >My second question has to do with the way slot controller chips are >probed. From looking at 'pcic_probe()' in sys/pccard/pcic.c, it looks >for all the world to me that only a single slot controller chip is >supported (i.e., there are no unit numbers, and there is only one >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...) Well, the overall framework does support it, the actual code may not. I should be a minor thing to get it fixed, give a little bit of hardware and time. I don't actually know if we have the necessary callbacks into the pcic driver to modify the memory windows on the fly. If not we will need to add them. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."