Date: Sat, 07 Jul 2001 14:53:44 -0700 From: Peter Wemm <peter@wemm.org> To: Warner Losh <imp@harmony.village.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, Makoto MATSUSHITA <matusita@jp.FreeBSD.org>, sos@freebsd.dk, current@FreeBSD.ORG Subject: Re: Problems with ata probing twice. Message-ID: <20010707215344.4B1F2380F@overcee.netplex.com.au> In-Reply-To: <200107072102.f67L2QJ72605@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
> In message <200107072004.f67K4S701211@mass.dis.org> Mike Smith writes:
> : >
> : > sos> Well, sortof, the ata driver doesn't allow for sharing irq14&15
> : > sos> since lots of boards doesn't work that way. However if you need
> : > sos> it you can try to add the shared flag in the driver and see if
> : > sos> it works on yours. Hmm, maybe I should make this tunable...
> : >
> : > It this patch OK? I've tested a kernel with this patch and it works.
> : >
> : > This patch simply adds a new kernel MIB (hw.ata.shareable in this
> : > patch, but I have no idea about its name), and if this MIB value is
> : > non-zero, ata driver doesn't drop RF_SHAREABLE bit for BUS_ALLOC_RESOURCE
().
> :
> : No. This is utterly bogus.
> :
> : There is absolutely no reason for the ata driver not to simply set
> : RF_SHAREABLE and be done with it. It's up to the driver's parent (isa,
> : pci, etc) to decide whether the interrupt is in fact shareable or not.
> :
> : The ata driver itself can share interrupts just fine, and it should
> : reflect this in its interrupt allocation.
>
> Actually, there is a reason. Ata is special like pcic is special.
> Both of them can have multiple interrupt routing methods. When ata is
> connected directly to the south bridge, it can route ISA interrupts,
> even though it is a pci device. In this case, it is unsafe to share
> interrupts between the ata device and anything else. Even though it
> looks like a pci device, the interrupt routing is ISA.
This series of issues burns the SMP folk regularly. A quick backgrounder
for the gallery:
- pre EISA/PCI systems: only had ISA. The interrupt was high-edge triggered.
ie: the act of the PIC signal being pushed high caused the event.
- EISA era: EISA supported level triggering, usually active low I think.
A device was added in the interrupt pin path and it had an 'ELCR' (Edge/
Level Control Register). This lives at IO port 0x4d0/4d1. A single
bit per interrupt determines if the IRQ is reshaped from low-level
trigger to high-edge. The PIC is still programmed in high-edge mode for
DOS compatability etc.
- PCI era: interrupt routing was added, sometimes within the south bridge,
other times as a seperate ASIC. The ELCR is still present at the same
IO ports, but the ASIC that does the routing (if it exists) is at different
locations. Later chipsets mostly did the routing within the south bridge,
and with a limited number of pins on the chip. Quite often a bunch of
'GPIO' (General Purpose IO) pins could be assigned for various things
including routable interrupt sources.
- SMP era: a seperate PIC (APIC) was added. There is now a seperate interrupt
pathway from the PCI slots to the APIC and from the ISA slots to the APIC.
There is a "magic" device that does the bridging between the two systems.
This gets complicated because we have to emulate the EISA level sensitive
interrupts by reading the ELCR and programming the corresponding ISA sources
in level mode vs the usual edge trigger mode.
However, things have got really interesting lately. Some motherboards are
setting up shareable level triggered interrupts for the onboard ISA
devices. eg: fdc, com1, com2, lpt, etc. These show up in the MPTABLE as
level triggered mode, and are programmed in the ELCR as level triggered.
ie: many of the 'traditional ISA' interrupt nubmers are actually shareable.
If my memory serves me correctly, some Intel and Serverworks south bridges
can be programmed to use one GPIO pin as a shareable IRQ 15 input. The ATA
controller can even be programmed to use a single IRQ (IRQ 14 only) for
both channels because it is level triggered internally within the south
bridge.
The upshot of this is that drivers should be setting RF_SHAREABLE if they
themselves can handle the possibility that the motherboard is wired up for
sharing their IRQ. It is up to the bus controller to sort out what is
really electrically shareable and what is not... the drivers themselves do
not have this information (and should not be looking for it). I expect
the bus drivers need more work in this area.
The mere fact that the ata driver has calls into the Alpha IDE interrupt
routing code alone indicates that the bus bridge drivers need more work.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010707215344.4B1F2380F>