Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Dec 1999 13:47:12 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Warner Losh <imp@village.org>
Cc:        new-bus@freebsd.org
Subject:   Re: How do I map attribute memory...
Message-ID:  <Pine.BSF.4.10.9912030941020.23924-100000@salmon.nlsystems.com>
In-Reply-To: <199912022030.NAA04669@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2 Dec 1999, Warner Losh wrote:

> 
> Thanks for the responces to the irq activation question.  In newcard
> I'll move the activation to when the ISV is registered via
> bus_setup_intr.  I may do this in oldcard as well, depending on how
> much I wanna work on the old code...
> 
> Now, on to other matters.  Different resource spaces.
> 
> pccards have three resource spaces.  They have shared memory,
> programmed I/O and attribute memory.  The bridge chips support mapping
> the I/O ports into the host's I/O space.  They also support mapping
> the shared memory and the attribute memory into the host's memory
> space.  My question is how does newbus handle this?
> 
> I don't see any place in the bus_alloc_resource to hang this
> information.  One could add it as the resource argument, but that
> would require more hacking than I want to do to map a new type at the
> pcic bridge to the system space, and might have some undesirable side
> effects elsewhere.  Overloading rid doesn't seem the right thing to
> do.  I suppose I could add a flag bit, but what I really want is a
> parameter that says which address space is being allocated/activated,
> but that would force a lot of driver changes.
> 
> My feeling is that a flag bit in the flags word, eg RF_ATTRIBUTE_MEM
> would be how I'd go and have the pcic (or any pccard bridge) driver
> look for this and do special things.  I need this functionality
> generically for the pccard configuration code anyway...
> 
> However, that seems the least wrong way to do it rather than actually
> being right.
> 
> Comments?

If we use flags for this (I think I would prefer RF_PCCARD_ATTR or
something similar), and a device has both an attribute memory resource and
a normal memory resource, then the two must have different rids otherwise
things start to go downhill fast.

For the driver, does it need to do anything special when it maps the
attribute memory resource? If its just like memory, then why not just
treat it like a SYS_RES_MEMORY resource. The special code for mapping the
thing can be hidden inside the pccard driver.

How many regular memory regions and how many attribute regions can there
be?

> 
> Warner
> 
> P.S.  Most normal pccards don't need this.  The only thing that lives
> in the attribute space for them is the CIS and some write-only
> registers to activate the card, set which config to use, etc.  There
> exists at least one modern pccard that uses it to control packets to
> be send or recieved :-(.  Also the xircom folks need something
> similar, iirc.

:-)

--
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 181 442 9037





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-new-bus" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9912030941020.23924-100000>