From owner-freebsd-hackers Fri Sep 6 2:34: 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 6622A37B400 for ; Fri, 6 Sep 2002 02:34:00 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 6E69F43E42 for ; Fri, 6 Sep 2002 02:33:59 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 4160 invoked by uid 1031); 6 Sep 2002 09:32:16 -0000 Date: Fri, 6 Sep 2002 10:32:15 +0100 From: Bruce M Simpson To: "M. Warner Losh" Cc: freebsd-hackers@freebsd.org Subject: Re: PCMCIA questions: mapping attribute and common memory? Message-ID: <20020906093215.GI15218@spc.org> Mail-Followup-To: Bruce M Simpson , "M. Warner Losh" , freebsd-hackers@freebsd.org References: <20020905191546.GF15218@spc.org> <20020905.145936.39157187.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020905.145936.39157187.imp@bsdimp.com> User-Agent: Mutt/1.3.28i 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 Warner, Thanks for your informative response. On Thu, Sep 05, 2002 at 02:59:36PM -0600, M. Warner Losh wrote: > You generally don't map attribute memory. With one exception (the > raylan cards), there's no hardware in the attribute memory section and > it is just used to store the cis. ... [ray(4) and xe(4)] > Those are the two worst ones to look at. Don't do what they do, as > the ray(4) hardware is weird and the xe(4) driver was written before > we could read the cis from the kernel. The particular device I'm working with is the Gemplus GPR400 PCMCIA Smart Card Reader. It has hardware registers in the attribute memory. One of these registers tells me when a card is inserted/ejected, and there are also some bits in that space which are used to handle suspending and resuming the card. What's the best way for me to do this, whilst being OLDCARD and NEWCARD compatible? (And just out of interest, is it possible to read the CIS from the kernel easily whilst still being OLDCARD friendly?) > : If so, how do I get at the resource? > : If not, how would I go about doing this myself in the driver? > > bus_alloc_resource() Ok. Say I have my first two tuples and they look like this:- Tuple #1, code = 0x1 (Common memory descriptor), length = 3 000: d4 00 ff Common memory device information: Device number 1, type Function specific, WPS = OFF Speed = 100nS, Memory block size = 512b, 1 units Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3 000: 64 10 ff Attribute memory device information: Device number 1, type SRAM, WPS = OFF Speed = 100nS, Memory block size = 512b, 3 units How will these blocks be mapped when I allocate the resource? Are they coalesced into a single memory map in the order in which they appear in the CIS? Thing is, 2KB is 0x800 hex, and the register addresses I see in this Linux code I'm porting all start at 0xFA0. This would seem to indicate that a 2KB memory window is needed. [(3+1)*512]. The Linux code asks for a window size of 0x1000, which is 4KB, yet the comment says it's asking for 2KB. Bizarre. Once I've allocated the window as a resource, how would I go about accessing that memory directly? Would I need to establish a page mapping? [probe] > Ideally, you'd just match the OEM ID and vendor info of the card. > Less ideally, you'd match the strings in the CIS. So why do many pccard driver probes allocate and deallocate their card's resources? Is this merely to make sure they're available in anticipation of attach? BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message