[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: eata.c module and PCI setup problem (RAID SCSI card)

I only agree on the fact that if the io_port is specified as a parameter or
boot option pci_enable_device in not called.
This is easily fixed by adding this fragment of code at the
beginning of port_detect:

       return FALSE;
+   pdev = get_pci_dev(port_base);
+   if (pdev && !pci_enable_device(pdev)) {
+      printk("%s: detect, pci_enable_device failed at 0x%03lx.\n",
+             name, port_base);
+      return FALSE;
+      }
    if (do_dma(port_base, 0, READ_CONFIG_PIO)) {
 #if defined(DEBUG_DETECT)
       printk("%s: detect, do_dma failed at 0x%03lx.\n", name, port_base);

Anyway this is not sufficient to fix the problem, since the port has failed
to work even when pci_enable_device was called.


-----Original Message-----
From: Michel Lanners [mailto:mlan@cpu.lu]
Sent: Thursday, June 06, 2002 9:16 PM
To: Ballabio_Dario@emc.com
Cc: ad.l@delvaux.net; debian-powerpc@lists.debian.org
Subject: Re: eata.c module and PCI setup problem (RAID SCSI card)


On   6 Jun, this message from Ballabio_Dario@emc.com echoed through
> The eata driver really does not care whether it is using an ISA, EISA or
> board

It should, though. On most (all?) platforms besides i386, there are huge
differences between ISA/EISA and PCI. You can't just assume that IO
ports work the i386 way on all platforms. But there are ways to code it
so that it does work everywhere.

> as long as it has identified the I/O address where the EATA registers are
> available.
> The PCI detection routine find out an I/O address, nothing else. If you do
> not
> specify the io_port=0x1400 parameter at module load, it looks for all the
> possible addresses in a static list (well known ISA and EISA addresses)
> enlarged with the detected PCI addresses. Then it uses wait_on_busy
> the board until it is free or a max number of polls is reached before
> up
> (this overflows syslog buffer of messages from traps.c),
> for every address in the list. 0x330 happens to be the last address on the
> list.
> If you specify io_port=0x1400 this is the only address probed.

Well, on platforms other than i386 you can't assume that the device has
been enabled by the BIOS. The minimum you need to do is enable the
device via pci_enable_device(). You're doing that only if no io_port=
option has been specified. Problem.

> AFAIK this MAC does not respond at all to I/O port 0x1400, the inb()

Yes, because the device is not enabled. inb() does work in general (it
may not for _other_ reasons in this specific case).

> There is nothing I can do to fix the problem until inb()
> is able to read one byte from the board registers.

OK, agreed. But we may need your help to find out why the PCI device is
not enabled...
> End of story.

No, beginning of the story :)



Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: