lkml.org 
[lkml]   [2003]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject82371FB PIIX IDE problem with multi-function mode
    I'm having problems accessing the IDE controller on my Thinkpad (760ED)'s
    82371FB bridge. This has the effect that I get an error (HDIO_SET_DMA) when
    trying to enable DMA modes on it.

    The boot messages are

    PCI: PCI BIOS revision 2.10 entry at 0xfd930, last bus=6
    PCI: Using configuration type 1
    PCI: Probing PCI hardware
    ...
    Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
    ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
    PIIXa: IDE controller at PCI slot 00:01.0
    PIIXa: chipset revision 2
    PIIXa: not 100% native mode: will probe irqs later
    PIIXa: neither IDE port enabled (BIOS)
    hda: TOSHIBA MK4006MAV, ATA DISK drive
    hdb: SANYO CRD-S58P, ATAPI CD/DVD-ROM drive
    ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

    which suggests that there is no busmaster support.

    After searching for some help on this, I found
    http://www001.upp.so-net.ne.jp/kterada/pc_memo.html
    which, although in Japanese, contained some snippets of code and dmesg
    output that I was able to understand. It is for a slightly different model
    of Thinkpad that still contains the 82731FB. I tried the given setpci
    command (setpci -s 0:1.0 6a.w=04) with the result that lspci could then find
    the IDE interface:

    00:00.0 Host bridge: Intel Corp. 430MX - 82437MX Mob. System Ctrlr (MTSC) &
    82438MX Data Path (MTDP) (rev 02)
    00:01.0 ISA bridge: Intel Corp. 82371FB PIIX ISA [Triton I] (rev 02)
    00:01.1 IDE interface: Intel Corp. 82371FB PIIX IDE [Triton I] (rev 02)
    00:02.0 CardBus bridge: Texas Instruments PCI1130 (rev 04)
    ...

    The page also includes a trivial patch against 2.2.20 to perform this
    operation before the IDE devices are registered. I adapted this patch to
    2.4.21 as follows:

    --- linux-2.4.21/drivers/pci/pci.c.orig Fri Jun 20 16:06:17 2003
    +++ linux-2.4.21/drivers/pci/pci.c Sat Jun 21 11:03:27 2003
    @@ -1470,10 +1470,16 @@
    int func = 0;
    int is_multi = 0;
    u8 hdr_type;
    + unsigned int l;

    for (func = 0; func < 8; func++, temp->devfn++) {
    if (func && !is_multi) /* not a multi-function device */
    continue;
    + pci_read_config_dword(temp, PCI_VENDOR_ID, &l);
    + if (l == 0x122e8086) {
    + pci_write_config_word(temp,0x6a,0x0004);
    + printk("PCI: PIIXa set to multi-function mode\n");
    + }
    if (pci_read_config_byte(temp, PCI_HEADER_TYPE, &hdr_type))
    continue;
    temp->hdr_type = hdr_type & 0x7f;

    On booting, the output is now

    PCI: PCI BIOS revision 2.10 entry at 0xfd930, last bus=6
    PCI: Using configuration type 1
    PCI: Probing PCI hardware
    PCI: PIIXa set to multi-function mode
    ...
    Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
    ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
    PIIXa: IDE controller at PCI slot 00:01.0
    PIIXa: chipset revision 2
    PIIXa: not 100% native mode: will probe irqs later
    PIIXa: neither IDE port enabled (BIOS)
    PIIXb: IDE controller at PCI slot 00:01.1
    PIIXb: chipset revision 2
    PIIXb: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xfcf0-0xfcf7, BIOS settings: hda:DMA, hdb:pio
    hda: TOSHIBA MK4006MAV, ATA DISK drive
    hdb: SANYO CRD-S58P, ATAPI CD/DVD-ROM drive
    blk: queue c02763e0, I/O limit 4095Mb (mask 0xffffffff)
    ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
    hda: attached ide-disk driver.
    I can now set the drive to use DMA, although hdparm -tT shows that it's
    faster without, and the UDMA modes cause lots of `irq timeout' errors.

    I checked the documentation for the 82371FB, which says that the register
    being written is the MSTAT register, and writing a value of 4 to it does
    indeed put the device into multi-function mode. However, it also states
    that this bit defaults to 1 anyway.

    From this, I reason that somehow this bit is being set to 0 earlier in
    bootup. This might be happening either in the Thinkpad BIOS (in which case
    the above patch is necessary) or earlier in the kernel's boot routine (which
    means that the problem lies elsewhere).

    Any suggestions?

    Glyn
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:36    [W:0.022 / U:0.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site