Date: Fri, 6 Sep 2002 10:32:15 +0100 From: Bruce M Simpson <bms@spc.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-hackers@freebsd.org Subject: Re: PCMCIA questions: mapping attribute and common memory? Message-ID: <20020906093215.GI15218@spc.org> In-Reply-To: <20020905.145936.39157187.imp@bsdimp.com> References: <20020905191546.GF15218@spc.org> <20020905.145936.39157187.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020906093215.GI15218>