Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jan 1999 15:00:28 +0000
From:      Scott Mitchell <scott@dcs.qmw.ac.uk>
To:        Mike Smith <mike@smith.net.au>, Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Bill Trost <trost@cloud.rain.com>, mobile@FreeBSD.ORG
Subject:   Re: Reclaiming irqs for unsupported PCI hardware?
Message-ID:  <19990122150028.G22912@dcs.qmw.ac.uk>
In-Reply-To: <199901220158.RAA12743@dingo.cdrom.com>; from Mike Smith on Thu, Jan 21, 1999 at 05:58:34PM -0800
References:  <802.916962709@critter.freebsd.dk> <199901220158.RAA12743@dingo.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 21, 1999 at 05:58:34PM -0800, Mike Smith wrote:
> > In message <199901211928.LAA10433@dingo.cdrom.com>, Mike Smith writes:
> > 
> > >Once the card is gone, all of the 
> > >registers in the mapped space read all-1s.
> > 
> > This should not be relied on.  It is my understanding that you will
> > get fireworks bus-cycles on CardBus in this situation, and it will
> > be left to the BIOS writer to figure out what should happen since
> > I belive we end up in SMM mode in that case...
> 
> Cardbus is completely different.  I can hardly wait to see what happens 
> when you pull a cardbus card.
> 
> > Also I have not seen any documentation saying the all-1s is a standard,
> > but would accept a survey of pcic's which show this to be universal
> > so far.
> 
> The input drivers are pulled up, IIRC, so in the absence of anything 
> driving them, and modulo noise from the card departing, I'd expect an 
> *eventaul* all-1s.  I certainly wouldn't want to rely on it though.
> 
> > > - Polling for the card's presence every iteration of the interrupt 
> > >   handler loop.  This is absurdly expensive.  Don't suggest polling 
> > >   once on interrupt entry, unless you can guarantee the card won't be 
> > >   pulled during the interrupt handler's execution.
> > 
> > There is no way to guarantee that the card will not be pulled in the
> > next N microseconds.
> 
> Rrrg.  This is actually a really good point, and I can see where this 
> leads to.
> 
>  1) DO NOT REMOVE THE CARD UNTIL YOU HAVE SHUT IT DOWN.
>  2) Poll for insertions/removals since the cards are never active in
>     either state (see point 1).
> 
> Perhaps we're just looking at this the wrong way?  We don't try to 
> detect when floppies are stupidly removed, perhaps we shouldn't try to 
> do it with pccard/cardbus cards either?
> 
> Commentary?  Are we trying too hard to do something that's not worth 
> the effort?

Probably.  There's no way to gracefully deal with a card getting yanked
while you're servicing an interrupt from it, and no technical means to
prevent such a thing from happening, so anything beyond the current 'gone'
flag kludge is likely to be wasted effort.  Of course even that minimal
check is gone if you only check for card removals on inactive cards.

Speaking of which, how *do* you shut down a card/slot from userland other
than by using zzz?  The last version of PAO I played with had a 'power'
option to pccardc (and presumably an associated ioctl) that did this, but I
can't find anything like that in 3.0.  If no-one else is already tackling
it, I might start looking at this and the other annoying interactions
between my ThinkPad and the pccard/apm drivers once I get my Xircom driver
finished.

Cheers,

	Scott

-- 
===========================================================================
Scott Mitchell          | PGP Key ID |"If I can't have my coffee, I'm just 
<scott@dcs.qmw.ac.uk>   | 0x54B171B9 | like a dried up piece of roast goat"
QMW College, London, UK | 0xAA775B8B |     -- J. S. Bach.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990122150028.G22912>