Re: yenta_socket rapid fires interrupts

From: Linus Torvalds <torvalds@osdl.org>
To: DHollenbeck <dick@softplc.com>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	magnus.damm@gmail.com
Subject: Re: yenta_socket rapid fires interrupts
Date: Tue, 11 Jan 2005 13:40:34 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0501111322060.2373@ppc970.osdl.org> (raw)
In-Reply-To: <41E44248.2000500@softplc.com>

On Tue, 11 Jan 2005, DHollenbeck wrote:
> 
> only the last several lines were caught.  There is toggling between two 
> states, the very first state was not captured.

That's fine. This is interesting:

> yenta: event 00000000 state 30000006 csc 00

30000006 means (apart from the socket voltage information) "CB_CDETECT1 | 
CB_CDETECT2", which just means that a socket detect is pending.

> yenta: event 00000000 state 30000829 csc 00

And this means "CB_CARDSTS | CB_PWRCYCLE | CB_CBCARD | CB_3VCARD", ie that
it's become ready, powered, 32-bit card at 3.3V. Goodie. Everything looks 
fine, as far as I can tell.

But then something makes it back to detect pending again:

> yenta: event 00000000 state 30000006 csc 00

and it bounces between those two states forever. 

That certainly would seem to explain why you get a lot of interrupts, 
except the actual "event" flags are never set, so afaik it wasn't actually 
this yenta controller that sent those events in the first place. In fact, 
at no point would "yenta_events()" have returned non-zero, which is why 
the Yenta driver says "this interrupt was not for me".

What I don't see is why the port changes state, then. Since the yenta 
driver doesn't care for the interrupt anyway, it shouldn't be touching the 
hardware, and if it doesn't touch the hardware, then the pcmcia thing 
should eventually just calm down, even if it were to de-bounce a few 
times.

The above is what you'd likely see if somebody was forcing a reset on the
card or a card voltage re-interrogation all the time, which I don't see
why it would happen.

Can you change the "#if 0" at top of yenta_socket.c (around the debug 
thing), into a "#if 1"? That will make it _really_ noisy and totally 
unusable, but since it's unusable already.. I'd like to see what the 
accesses are in a full "cycle" of those bounces.

And don't worry about capturing the whole log - the only thing that I'm 
interested in is one full cycle (from likely 5000 of them - since every 
other interrupt is in the reset state, and every other is PWRCYCLE).

		Linus