mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
To: Athol Mullen <me@privacy.net>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()
Date: Tue, 10 Feb 2004 01:24:13 +0100	[thread overview]
Message-ID: <200402100124.13627.bzolnier@elka.pw.edu.pl> (raw)
In-Reply-To: <c06jlm$13ju4j$1@ID-215292.news.uni-berlin.de>

On Monday 09 of February 2004 03:50, Athol Mullen wrote:
> Willy Tarreau <willy@w.ods.org> wrote:
> > On Sun, Feb 08, 2004 at 11:45:18AM +1100, Athol Mullen wrote:
> >
> > I captured dmesg and /proc/ide/piix, but forgot to post them. They're at
> > work now. But I did the change, by commenting out the call to
> > eighty_ninety_three() in piix.c, and my disks came back to 54 MB/s each,
> > and 64 MB/s cumulated.  dmesg showed UDMA33 before and now displays
> > UDMA100 again. But I obviously cannot let it like that because if I
> > install this kernel in a 40-pin machine, I will get some surprizes !
>
> That's what worries me...
>
> > I understand. But could you please post your ICH5 detection code so that
> > I can try it on this machine. I still can play with it for a few days
> > before it gets racked. And I can try with both 40 and 80-pin cables.
>
> This patch inserts the piix code into eighty_ninty_three() - obviously
> this is for testing purposes only.  The patch was diff'd against 2.4.22,
> but patches okay to 2.6.1 with:
>     Hunk #1 succeeded at 719 (offset -10 lines).
>
> --- ide-iops.c.orig	2004-01-18 15:04:24.000000000 +1100
> +++ ide-iops.c	2004-01-18 16:41:16.000000000 +1100
> @@ -729,6 +729,34 @@
>
>  #else
>
> +#ifdef CONFIG_BLK_DEV_PIIX
> +	/* ICH BIOSes are supposed to set a bit flags for us */
> +
> +	ide_hwif_t *hwif	= HWIF(drive);
> +	struct pci_dev *dev	= hwif->pci_dev;
> +	u16 cr_flag		= 0x10 << drive->dn;
> +	u16			reg54;
> +
> +	if (hwif->pci_dev->vendor == PCI_VENDOR_ID_INTEL) {
> +		switch(hwif->pci_dev->device) {
> +			case PCI_DEVICE_ID_INTEL_82801BA_8:
> +	    		case PCI_DEVICE_ID_INTEL_82801BA_9:
> +	    		case PCI_DEVICE_ID_INTEL_82801CA_10:
> +	    		case PCI_DEVICE_ID_INTEL_82801CA_11:
> +	    		case PCI_DEVICE_ID_INTEL_82801E_11:
> +	    		case PCI_DEVICE_ID_INTEL_82801DB_10:
> +			case PCI_DEVICE_ID_INTEL_82801DB_11:
> +			case PCI_DEVICE_ID_INTEL_82801EB_11:
> +			case PCI_DEVICE_ID_INTEL_82801AA_1:
> +			case PCI_DEVICE_ID_INTEL_82372FB_1:
> +			    {
> +			    pci_read_config_word(dev, 0x54, &reg54);
> +			    return ((reg54 & cr_flag) ? 1 : 0);
> +			    }
> +		}
> +	}
> +#endif /* CONFIG_BLK_DEV_PIIX */
> +

This is plain wrong, piix.c already does it for you.
piix.c:init_hwif_piix():

(...)
	u8 mask = hwif->channel ? 0xc0 : 0x30;
(...)
			pci_read_config_byte(hwif->pci_dev, 0x54, &reg54h);
			pci_read_config_byte(hwif->pci_dev, 0x55, &reg55h);
			ata66 = (reg54h & mask) ? 1 : 0;
(...)
	if (!(hwif->udma_four))
		hwif->udma_four = ata66;

So you could just add:
	return hwif->udma_four;
for testing purposes.

>  	return ((u8) ((HWIF(drive)->udma_four) &&

Therefore this will be true.

>  #ifndef CONFIG_IDEDMA_IVB
>  			(drive->id->hw_config & 0x4000) &&

Here is your problem.

Please make sure you have CONFIG_IDEDMA_IVB=n in your config.
If it is okay, please send me a copy of /proc/ide/hdX/identify.

--bart


  parent reply	other threads:[~2004-02-10  0:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1mLsS-6Oq-7@gated-at.bofh.it>
     [not found] ` <1mLsS-6Oq-9@gated-at.bofh.it>
     [not found]   ` <1mLsS-6Oq-5@gated-at.bofh.it>
     [not found]     ` <1mRHV-4Xn-7@gated-at.bofh.it>
2004-02-09  2:50       ` Athol Mullen
2004-02-09 20:04         ` Willy Tarreau
2004-02-10  0:24         ` Bartlomiej Zolnierkiewicz [this message]
     [not found] <1n9OA-6lu-17@gated-at.bofh.it>
     [not found] ` <1n9OA-6lu-23@gated-at.bofh.it>
     [not found]   ` <1n9OA-6lu-15@gated-at.bofh.it>
     [not found]     ` <1nu6y-XO-3@gated-at.bofh.it>
2004-02-10  7:16       ` Athol Mullen
2004-02-10 14:41         ` Bartlomiej Zolnierkiewicz
     [not found] <1mtPj-7oQ-3@gated-at.bofh.it>
     [not found] ` <1mwNn-1xb-27@gated-at.bofh.it>
2004-02-08  0:45   ` Athol Mullen
2004-02-08  7:31     ` Willy Tarreau
2004-02-10  0:10       ` Bartlomiej Zolnierkiewicz
2004-02-10  0:37         ` Bartlomiej Zolnierkiewicz
2004-02-07  6:00 Athol Mullen
2004-02-07  9:15 ` Willy Tarreau

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=200402100124.13627.bzolnier@elka.pw.edu.pl \
    --to=b.zolnierkiewicz@elka.pw.edu.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@privacy.net \
    /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

all inboxes | Powered by JetHome®