Date: Tue, 23 Sep 1997 23:00:18 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Nate Williams <nate@mt.sri.com> Cc: mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG> Subject: Re: PCCARD in -current broken Message-ID: <19970923230018.00034@mi.uni-koeln.de> In-Reply-To: <199709231929.NAA08312@rocky.mt.sri.com>; from Nate Williams on Tue, Sep 23, 1997 at 01:29:37PM -0600 References: <199709231929.NAA08312@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 23, Nate Williams <nate@mt.sri.com> wrote:
> It has been for some time (May). If it works on your box, you're
> lucky! (PHK is one of the lucky ones, and it may be related to using
> more PCI-like machines, unlike older 'straight-ISA' laptops).
Hmmm, I'm surprised to hear that ...
You are the first to report such a problem.
> The change to the 'generic' shared interrupt code broke some assumptions
> I had about 'register_intr()' and 'unregister_intr()' in
> /sys/pccard/pcic.c. Basically, I had assumed the register_intr() would
> fail if I wanted access to an interrupt that was already taken, and now
> it succeeds so I add it to my list of 'available' IRQ's (I'd give it
> back, but at this point the freemask is really hosed). This assumption
> leads to all sorts of problems, of which I haven't completely thought
> about.
There should not be a problem. ISA does not
(should not, I didn't check the sources
recently) register the handler as shared,
and this will prevent another handler (both
shared or exclusive) to be registered.
I assume this does not work for you ?
> In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by
> 'RESOURCE_CHECK' is finished, or something else is done to make sure
The code is finished, but I did not commit
it to -current, since I was waiting for the
new ISA device probe/attach code to become
available.
Several concepts have been discussed, with
the "extent registration" of NetBSD being
mentioned very often.
My concept is quite different, in that I'd
rather have a functional interface, which
works on bus-dependent data structures that
have to exist anyway, while the extent data
does exist independently of device data.
I have outlined this before ...
> that 'ISA/Exclusive' interrupts are not allowed to be registered as
> 'shared' resources, I think there are potential problems with the
Well, ISA interrupts should be registered in
a way that guarantees they are not shared.
> current scheme, and may even effect 'normal' (non-laptop) systems who
> use ISA devices, though it's doubtful they do silly things like I'm
> doing in the PCCARD code.
>
> I don't have any solutions in the short-term, but I wanted to let folks
> know about the possible problems.
Hmmm, I just checked the sources and I can't
see what's wrong. Please tell me why the
following is not sufficient:
config_isadev_c() calls register_intr()
register_intr() contains the following lines:
flags |= INTR_EXCL;
idesc = intr_create((void *)device_id, intr, handler,
(void*)unit, maskptr, flags);
return (intr_connect(idesc));
intr_create() just stores the flag in the
interrupt descriptor, intr_connect() calls
add_intrdesc(), which has:
if ((idesc->flags & INTR_EXCL) != 0
|| (head->flags & INTR_EXCL) != 0) {
/*
* can't append new handler, if either list head or
* new handler do not allow interrupts to be shared
*/
printf("\tdevice combination doesn't support shared irq%d\n",
irq);
return (-1);
}
As soon as some ISA device got an interrupt
registered, no second handler will be added.
I've checked, that pccard.c also uses the
register_intr() compatibility call, and thus
it will also get INTR_EXCL added to the flags
value supplied (which is a constant "0").
Please tell me what's wrong with this ...
Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970923230018.00034>