linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Sealey <matt@genesi-usa.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: linuxppc-dev@ozlabs.org, linux-ide@vger.kernel.org
Subject: Re: adding Pegasus IDE quirk for pata_via
Date: Mon, 09 Apr 2007 14:13:52 +0100	[thread overview]
Message-ID: <461A3C10.3050104@genesi-usa.com> (raw)
In-Reply-To: <20070404111635.GA1855@aepfle.de>

Hi Olaf, IDE guys,

I believe that this quirk is not Pegasos-specific. It will also affect any
Via VT8231 controller (and perhaps any Via IDE, but I can't test that assertion)
which is run in PCI mode.

The basic bug is that in PCI native mode, the chip should use ONE PCI
interrupt and there is logic in the driver to select which channel fired
it. However, if the chip is configured to use two interrupts in the IRQ
steering register, it WILL use two interrupts.

I did write a patch at one time (September last year) but abandoned it as it
would only have had to be rewritten and I did not have the real resources
required to make sure it did not make any other platforms explode.

(Olaf, Peter Czanik may have forwarded you an old version of this patch already)

It basically did the following where the old Pegasos check was:

+	if (vdev->via_config->flags & VIA_NATIVE_TWO_IRQ) {
+		u8 cb;
+
+	    pci_read_config_byte(hwif->pci_dev, PCI_CLASS_PROG, &cb);
+
+		if (cb & 0x5) { /* if controller is configured for pci-native mode for both channels */
+		    	pci_read_config_byte(hwif->pci_dev, PCI_INTERRUPT_PIN, &cb);
+
+	   		if (cb & 0x1) { /* if controller is actually using an interrupt for native mode */
+
+				struct pci_dev *bridge = pci_find_device(PCI_VENDOR_ID_VIA, vdev->via_config->id);
+
+				if (bridge) {
+					u8 iir, irqlist[4] = { 14, 15, 10, 11 };
+
+					pci_read_config_byte(bridge, VIA_IDE_STEERING, &iir);
+
+					hwif->irq = irqlist[hwif->channel ? ((iir & 0xc) >> 2) : (iir & 0x3)];
+				}
+
+			}
+		}
  	}

This basically uses the IRQ that the Via chipset says to use, as it is always programmed into the
chipset, and that value is always correct. Only 14, 15, 10 and 11 are valid according to the
documentation, but in truth only interrupts 14 and 15 actually work. It is possible to set the
interrupts to the same IRQ but this is quite rare and the old via driver did not seem to handle
it correctly, so the firmware leaves the 14/15 combination in there to get a working system.

I tried to keep it as generic as possible. This patch does work on Pegasos.

Either way the steering bits will tell you which it is, rather than a switch between 14 and 15
hardcoded into the system. There is no need to use the device tree and in fact any modification
to the interrupt node would be rather spurious since the device tree can only include one interrupt
value for the PCI device according to the standard, and cannot define which interrupt goes with
which channel (it could be reversed!).

The only safe way is to use the values programmed into the chip. This will also fix any other
architecture where this chipset is used (x86) in this manner. This is 0% of x86 systems with an
Award/AMI BIOS but if the chip is reconfigured in early boot, or if LinuxBIOS or OpenBIOS are
used, this may well change on the author's whim.

Again some comments would be appreciated from anyone who has a better idea on how this controller
works. This simple code addition came out of 2 or 3 days of discussion with the Pegasos designer
based on his experiences with the chip and is so simple there cannot be much wrong with it
apart from coding style and a distinct lack of testing.

Thanks for any input you can give :)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Olaf Hering wrote:
> The pegaos board needs an irq quirk in pata_via.
> Where is the quirk list for libata? I dont see one in pata_via.c
> 
> drivers/ide/pci/via82cxxx.c:init_hwif_via82cxxx()
> 
>     440 #ifdef CONFIG_PPC_CHRP
>     441         if(machine_is(chrp) && _chrp_type == _CHRP_Pegasos) {
>     442                 hwif->irq = hwif->channel ? 15 : 14;
>     443         }
>     444 #endif
> 
> 
> This is in the firmware node. Will a fixup of the 'interrupts' property
> work or does everything poke directly at the PCI registers?
> Should fixup_device_tree_chrp() take care of the 'interrupts' property?
> 
> /proc/device-tree/pci@80000000/ide@C,1:
> name             "ide"
> linux,phandle    0fc5c3a0 (264618912)
> interrupt-parent 0fc5b948 (264616264)
> assigned-addresses 01006110 00000000 fe001000 00000000 00000008
>                  01006114 00000000 fe00100c 00000000 00000004
>                  01006118 00000000 fe001010 00000000 00000008
>                  0100611c 00000000 fe00101c 00000000 00000004
>                  01006120 00000000 fe001020 00000000 00000010
> device_type      "spi"
> reg              00006100 00000000 00000000 00000000 00000000 01006110
>                  00000000 00000000 00000000 00000008 01006114 00000000
>                  00000000 00000000 00000004 01006118 00000000 00000000
>                  00000000 00000008 0100611c 00000000 00000000 00000000
>                  00000004 01006120 00000000 00000000 00000000 00000010
> max-latency      00000000
> min-grant        00000000
> fast-back-to-back
> devsel-speed     00000001
> interrupts       00000014 00000000 00000015 00000000
> .description     "PCI IDE Controller"
> .part-number     "VT82C586/596/686"
> .vendor-name     "VIA"
> subsystem-vendor-id 00000000
> subsystem-id     00000000
> class-code       0001018f (65935)
> revision-id      00000006
> device-id        00000571 (1393)
> vendor-id        00001106 (4358)
> 
> 
> 0000:00:0c.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8f [Master SecP SecO PriP PriO])
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 0
>         Interrupt: pin A routed to IRQ 20
>         Region 0: I/O ports at 1000 [size=8]
>         Region 1: I/O ports at 100c [size=4]
>         Region 2: I/O ports at 1010 [size=8]
>         Region 3: I/O ports at 101c [size=4]
>         Region 4: I/O ports at 1020 [size=16]
>         Capabilities: [c0] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

  parent reply	other threads:[~2007-04-09 13:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-04 11:16 adding Pegasus IDE quirk for pata_via Olaf Hering
2007-04-04 16:20 ` [PATCH] add correct interrupt property for pegasos ide Olaf Hering
2007-04-04 18:10   ` Bartlomiej Zolnierkiewicz
2007-04-04 18:11     ` Olaf Hering
2007-04-04 18:42       ` Bartlomiej Zolnierkiewicz
2007-04-05  1:47         ` Benjamin Herrenschmidt
2007-04-05 10:32         ` Olaf Hering
2007-04-05  1:46       ` Benjamin Herrenschmidt
2007-04-05  0:55   ` Stephen Rothwell
2007-04-04 23:52 ` adding Pegasus IDE quirk for pata_via Benjamin Herrenschmidt
2007-04-09 13:13 ` Matt Sealey [this message]
2007-04-09 14:40   ` Alan Cox
2007-04-09 17:39     ` Matt Sealey
2007-04-10 16:22     ` Olaf Hering
2007-08-16 17:01       ` Olaf Hering
2007-08-16 17:00   ` Olaf Hering
2007-08-17 13:10 ` [PATCH] advertise correct IDE mode on Pegasos2 Olaf Hering
2007-08-17 14:33   ` Olaf Hering
2007-08-17 18:19     ` Matt Sealey
2007-08-17 18:30       ` Olaf Hering
2007-08-17 18:27   ` Olaf Hering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=461A3C10.3050104@genesi-usa.com \
    --to=matt@genesi-usa.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=olaf@aepfle.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).