ide_init_hwif_ports

ide_init_hwif_ports

[Paul Mackerras]

I have looked at all the different ide_init_hwif_ports implementations
in the linuxppc_2_4_devel tree.  They are all remarkably similar with
the exception of four: 8xx, lopec, mcpn765 and sandpoint.  The 8xx one
seems to be PCMCIA and the other three all have a PCI IDE controller
(82c105 or 82c586).

Now, ide_init_hwif_ports is really only used in two situations: when
you have IDE controllers at well-known I/O port addresses, or when you
are using the pci-ide driver.  In both cases an implementation like
this (from the prep) is fine, on any platform:

static __inline__ void ide_init_hwif_ports(hw_regs_t *hw,
					   ide_ioreg_t data_port,
					   ide_ioreg_t ctrl_port, int *irq)
{
	ide_ioreg_t reg = data_port;
	int i;

	for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
		hw->io_ports[i] = reg;
		reg += 1;
	}
	if (ctrl_port) {
		hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
	} else {
		hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206;
	}
	if (irq != NULL)
		*irq = 0;
	hw->io_ports[IDE_IRQ_OFFSET] = 0;
}

For platforms that have weird register layouts or whatever, we should
have a probe routine that finds the device and sets up the ports.  See
drivers/ide/ide-pmac.c for an example.  IOW, it would be good if
drivers/ide/ide-m8xx.c could be converted to have an m8xx_ide_probe
routine that would work out how many 8xx-style IDE interfaces there
are, and for each one find a slot in ide_hwifs and initialize it like
m8xx_ide_init_hwif_ports now does.

Platforms with a PCI IDE controller should use the pci-ide driver
instead of trying to use ide_default_io_base and ide_init_hwif_ports
to point the IDE code at the IDE registers.  In other words, only
those platforms with an ISA IDE controller (prep, any others?) should
ever need to have their ide_default_io_base return anything other than
0.

So I am proposing to drop ppc_md.ide_init_hwif_ports and change the
definition of ide_init_hwif_ports in include/asm-ppc/ide.h to the one
above.

Comments?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Adrian Cox]

Paul Mackerras wrote:


> Platforms with a PCI IDE controller should use the pci-ide driver
> instead of trying to use ide_default_io_base and ide_init_hwif_ports
> to point the IDE code at the IDE registers.  In other words, only
> those platforms with an ISA IDE controller (prep, any others?) should
> ever need to have their ide_default_io_base return anything other than
> 0.
>
> So I am proposing to drop ppc_md.ide_init_hwif_ports and change the
> definition of ide_init_hwif_ports in include/asm-ppc/ide.h to the one
> above.


The one important thing that the ide_init_hwif function handles for one
of my boards (and for the sandpoint) is the knowledge that the irqs are
14 and 15. If left to its own devices the pci-ide code  will assume that
both channels are on the same irq, which leaves the second channel
running without interrupts.

But I'd be happy with any simpler way of communicating "just use 14 and
15" to the pci-ide driver.

--
Adrian Cox   http://www.humboldt.co.uk/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Paul Mackerras]

Adrian Cox writes:

> The one important thing that the ide_init_hwif function handles for one
> of my boards (and for the sandpoint) is the knowledge that the irqs are
> 14 and 15. If left to its own devices the pci-ide code  will assume that
> both channels are on the same irq, which leaves the second channel
> running without interrupts.

Ah, OK.  Is this the 82c105?  Are the two channels separate PCI
functions in the device, or are they the same function?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Joseph P. Garcia]

On Thu, 29 Nov 2001 16:41:19 +1100 (EST)
Paul Mackerras <paulus@samba.org> wrote:
> So I am proposing to drop ppc_md.ide_init_hwif_ports and change the
> definition of ide_init_hwif_ports in include/asm-ppc/ide.h to the one
> above.
>
> Comments?

I'm not sure about details, so bare with my ignorance. :)

Will a call to ide.c:ide_register() then be using a generic ide_init_hwif_ports?

If so, since the pmac mediabay has a pmac port arrangement, it will need a modification.  It's call to ide_register() would be replaced with a direct call to pmac_ide_init_hwif_ports() followed by ide_register_hw().

While ide_pmac.c registers mediabay's inserted before booting, anything hotswapped is handled by mediabay.c.  There was a time (maybe still now) that some source trees made the pmac's entry in ppc.md_ide_init_hwif_ports generic, breaking the existing code in mediabay.

--
Joseph P. Garcia
http://www.lycestra.com/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Dan Malek]

Paul Mackerras wrote:


> Ah, OK.  Is this the 82c105?  Are the two channels separate PCI
> functions in the device, or are they the same function?

It's part of the 83c553 bridge.  IIRC, the interrupts from the IDE
can be routed in a couple of different ways, including directly into
the EPIC.  You can kind of pretend it is a PCI-IDE controller, but there
isn't any PCI config register to read that will tell you the interrupt
number, so we need a way to tell the generic IDE code what to use (and
of course this number is suitably "faked" so it generates the proper
EPIC interrupt).  The reason you want to use this configuration mode
on the Sandpoint is because it eliminates some other interrupt
multiplexing problems and board resource conflicts.

Custom boards that don't have a regular appearance in the source tree
have copied a similar design.  I would like to vote for leaving this
interrupt mapping function in place as well.

Thanks.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Armin Kuster]

Paul Mackerras wrote:
>
> I have looked at all the different ide_init_hwif_ports implementations
> in the linuxppc_2_4_devel tree.
> So I am proposing to drop ppc_md.ide_init_hwif_ports and change the
> definition of ide_init_hwif_ports in include/asm-ppc/ide.h to the one
> above.
>
> Comments?
>

works for  me.

---armin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Michael Sokolov]

On the IDE issue, unfortunately the world is not perfect and I'm afraid we do
need some of the ugliness we have for IDE. One critter for which you need this
ugliness is the VT82C686B south bridge. It has two IDE interfaces like all
those PeeCee south bridges and from the PCI side shows up as one PCI IDE
device. For a number of good reasons I've made StarMON put it in PCI native
mode and map the IDE ports to floating PCI addresses.

The trouble begins with interrupts. Anybody who has used the VT82C686B in a
non-PeeCee design knows that its interrupt handling is wacky. The component has
one IDSEL pin, but puts a whopping 7 functions on it. Function 0 is the actual
south bridge, and all other functions are regular PCI devices "included for
free". Those regular PCI functions are supposed to signal regular PCI
interrupts. If they were separate components they would have INTA#, etc.
outputs. But remember that the VT82C686B was designed with the idea that it
would be *fielding* the INTA-D# interrupts, not generating them. It has these 4
pins as *inputs*, but non-PeeCee designs like ours simply don't use them (we
have our own interrupt controller for all regular PCI interrupts). But what do
the internal PCI functions do with their "PCI" interrupts? They do something
very novel. They took PCI config space register 3C (Interrupt Line) and gave it
a whole new meaning. While by the spec this register is for BIOS use only and
should have no effect on any hardware, the PCI functions inside the VT82C686B
use the contents of this register to route their interrupts to one of 16 IRQs
on the internal 8259 pair. Interrresting...

It gets even worse in function 1, PCI IDE. While the other internal PCI
functions (USB and audio) generate their interrupts themselves and then route
them in a novel way, the IDE function doesn't even generate its interrupts. The
IDE interrupts come straight from the IDE port connectors. And the kicker is,
the VT82C686B component does not have dedicated pins for the interrupts coming
from the IDE connectors! Instead they tell board designers to tie these lines
to IRQ 14 and IRQ 15 using the VT82C686B IRQ pins, the same ones that would go
to ISA slot connectors. This is what the Adirondack does, and the result is
that no matter what you do in the PCI domain, the primary IDE interrupt will
always come in as IRQ 14 and the secondary IDE interrupt will always come in as
IRQ 15.

How does this trouble Linux? Linux sees a PCI device with a PCI IDE class code
in PCI native mode. It assumes that it will signal a PCI interrupt, one for
both channels. It asks the PPC PCI interrupt routing code what that interrupt
is. But whatever number I return there, it will be wrong. If I return 14, the
primary channel will work, but not the secondary channel. Bummer.

I couldn't find any way to tell the PCI IDE code that a certain PCI IDE device
is to be treated specially in that it has different IRQs for the two channels.
The only way I could find is to have my setup_arch or some other early code
read the VT82C686B function 1 BARs to find out the on-board IDE addresses
(remember, StarMON puts it in PCI native mode and maps them to floating PCI
addresses), have ppc_ide_md.default_io_base report these addresses as standard
ports 0 and 1, and have ppc_ide_md.ide_init_hwif know about these two magic
addresses and their associated IRQs. So I'm afraid we'll have to keep this
ugliness.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[mod+linuxppc-dev]

On Thu, 29 Nov 1901 11:00:09 PST msokolov@ivan.Harhan.ORG wrote:
> and the result is that no matter what you do in the
> PCI domain, the primary IDE interrupt will always
> come in as IRQ 14 and the secondary IDE interrupt
> will always come in as IRQ 15.
>
> How does this trouble Linux?  Linux sees a PCI
> device with a PCI IDE class code in PCI native mode.
> It assumes that it will signal a PCI interrupt, one
> for both channels.  It asks the PPC PCI interrupt
> routing code what that interrupt is.  But whatever
> number I return there, it will be wrong.  If I
> return 14, the primary channel will work, but not
> the secondary channel.  Bummer.


Not to quibble with your painfully accurate
description of the VT82C686B, but might it be
possible (using the IDE Interrupt Routing register
at offset 0x4a in function 1) to arrange for both
channels to use the same interrupt routing?
Like force both to IRQ14?  Just a thought...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Paul Mackerras]

Michael Sokolov writes:

> to ISA slot connectors. This is what the Adirondack does, and the result is
> that no matter what you do in the PCI domain, the primary IDE interrupt will
> always come in as IRQ 14 and the secondary IDE interrupt will always come in as
> IRQ 15.

Thanks for the explanation.  I'll ask Vojtech Pavlik and Andre Hedrick
if they can suggest a better way (drivers/ide/via82cxxx.c has
Vojtech's name on it).

Actually, I have just noticed this code in drivers/ide/ide-pci.c:

                if (IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8886A) ||
                    IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8886BF) ||
                    IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8673F)) {
                        hwif->irq = hwif->channel ? 15 : 14;
                        goto bypass_umc_dma;
                }

We may be able to get something similar added for our case(s).

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Michael Sokolov]

mod+linuxppc-dev@MissionCriticalLinux.com wrote:

> Not to quibble with your painfully accurate
> description of the VT82C686B, but might it be
> possible (using the IDE Interrupt Routing register
> at offset 0x4a in function 1) to arrange for both
> channels to use the same interrupt routing?
> Like force both to IRQ14?  Just a thought...

>From what I could tell the IDE interrupt routing is fixed by the board
circuitry *outside* the chip and cannot be changed by any register diddling. As
I said, I don't think the VT82C686B even knows when an IDE interrupt has
occurred. The interrupt lines from the IDE connectors are tied directly to the
IRQ14 and IRQ15 pins, the same ones that go to the ISA slot connectors. If one
of these pins goes high, the VT82C686B has no way of knowing that it's IDE or
something else on ISA using this IRQ is signaling an interrupt.

Then what does the supposed IDE Interrupt Routing register (at offset 0x4A in
function 0, I assume that's what you really meant) do? I have no idea. I
suspect that Via *tried* to make it standards-compliant and support both AT-
compatible and pure PCI IDE interrupt routing, but never fully got it. Consider
function 1's Interrupt Pin register (offset 0x3D). The Via manual says:

00h Legacy mode interrupt routing
01h Native mode interrupt routing

Yet it always reads as 00 and I couldn't get it to read as 01 or as anything
else.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Adrian Cox]

mod+linuxppc-dev@MissionCriticalLinux.com wrote:


> Not to quibble with your painfully accurate
> description of the VT82C686B, but might it be
> possible (using the IDE Interrupt Routing register
> at offset 0x4a in function 1) to arrange for both
> channels to use the same interrupt routing?
> Like force both to IRQ14?  Just a thought...


Tried that on my 686A board. As far as I can tell that register does
nothing at all, and the physical wiring on the board is the only thing
that influences the interrupts. I think that register may  be useful on
an i386 with IO-APIC, but I'm not sure.

--
Adrian Cox   http://www.humboldt.co.uk/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_init_hwif_ports

[Michael Sokolov]

Paul Mackerras <paulus@samba.org> wrote:

> Thanks for the explanation.  I'll ask Vojtech Pavlik and Andre Hedrick
> if they can suggest a better way (drivers/ide/via82cxxx.c has
                                    ^^^^^^^^^^^^^^^^^^^^^^^
> Vojtech's name on it).

That VIA82CXXX fast mode code makes the Adirondack *hang* on the partition
check if enabled... I'm keeping it out of the picture for now.

> Actually, I have just noticed this code in drivers/ide/ide-pci.c:
>
>                 if (IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8886A) ||
>                     IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8886BF) ||
>                     IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8673F)) {
>                         hwif->irq = hwif->channel ? 15 : 14;
>                         goto bypass_umc_dma;
>                 }
>
> We may be able to get something similar added for our case(s).

Keep in mind that, as I just said, from what I could tell the IDE interrupt
routing is fixed by the board circuitry *outside* the chip, although I doubt
that anyone out there has routed the IDE interrupts anywhere other than IRQ14
and IRQ15... But never say never, we have some new boards coming up with a
GT64260 and a VT82C686B, and it seems like they want to avoid using the PeeCee
dual 8259 PIC as much as possible, so who knows, maybe they'll route the IDE
interrupts upstairs bypassing the VT82C686B altogether... Didn't I just hear
someone on this list talk about their IDE interrupts going to an EPIC?

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/