Russell King wrote:
>On Thu, Aug 07, 2003 at 02:02:22PM +0100, Tim Small wrote:
>
>
>>"device control register bits2,1: R/W, Interrupt mode.
>>Bits 2 1 select the interrupt mode used by the PCI1031. Bits 2 1 are
>>encoded as: 00 = No interrupts enabled (default) 01 = ISA 10 =
>>Serialized IRQ type interrupt scheme 11 = Reserved"
>>
>>
>
>When you look at some other TI device, you'll notice that these bits
>have a similar meaning, but, for instance 10 will be reserved (because
>the device doesn't support Serialised ISA IRQs) but supports 11 (serial
>PCI IRQs.) 00 means PCI IRQ mode only on some TI devices, and is a
>valid setting.
>
OK, but you could check various registers to see if the device is in the
default power-on state, and only then probe. This will make sure that
it Just Works for devices which are already correctly configured - which
should be the majority. It may turn out to be possible to probe for the
correct settings on some bridge chips, and not others, but this would
still be better than nothing..
>You can do what you're suggesting as long as you take account of the
>device itself. However, once you've decided the device isn't setup,
>how can the kernel determine exactly what the _correct_ setup of the
>device is? You can't say "well, its a PCI1031 device, therefore I'll
>select ISA interrupt mode" because you don't know if it has been
>wired up that way.
>
>
I think you can assume that a parallel ISA interrupt wiring scheme, or
an IRQSER wiring scheme is not possible for an add-in device (i.e. one
that the system BIOS is unaware of), because there are no pins for these
signals on a standard PCI slot, making these schemes physically
impossible (unless an ISA 'paddle board', or similar was used - I've
never see such a device, but I suppose it would be possible to build
one). Does this also cover the hotplug cases? What about ACPI resume?
If not, you could probably probe for the valid method, by forcing card
status events, and seeing if the interrupts get delivered. Of course,
the trick is to do this in a way which will not cause trouble, and
potentially lock up the system by triggering incorrect interrupts etc.
. On the PCI1031, you'd need to do this:
. Set up the bridge for parallel ISA IRQ delivery, and see if IRQ
delivery works by generating a status event (skip this test and quit
here with a useful error message* with a warning if no safe IRQs
available for this test (5,12,14 - not a particularly hopeful list, I
grant you, but possibly, you could also probe IRQ3, IRQ4 in this manner,
and you'd get PCI interrupts generated if the bridge is wired for
parallel PCI IRQs))
- if this fails, it must be wired either IRQSER, or parallel PCI
interrupts:
. Set up the bridge for parallel PCI IRQ delivery, and see if IRQ
delivery works by generating a status event
- if this fails, it must be wired for IRQSER interrupts:
. Set up the bridge for IRQSER delivery, and see if IRQ delivery works
by generating a status event
- if this doesn't work, disable interrupts again, and print a message
stating that interrupts failed (you could still use memory devices, as
Pavel suggested).
* The error message could say that we were unable to probe interrupts
because no safe interrupts were available, and say which ones we wanted
so that the user could make them available by making sure the yenta
driver was loaded before other drivers and/or disabling devices which
are already on these IRQs and/or telling the BIOS to reserve them, or
maybe we could grab these interrupts if available, or tell the user to
load the module with the module option "yenta_ti_unsafeIRQprobe" enabled.
I am just brainstorming here, so please forgive me if I'm talking bollox ;-)
Tim.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:38 EST