public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: gboyce <gboyce@badbelly.com>, linux-kernel@vger.kernel.org
Subject: Re: IDE + CPU Scaling problem on Via EPIA systems
Date: Tue, 6 Dec 2005 12:05:33 -0500	[thread overview]
Message-ID: <20051206170533.GB440@redhat.com> (raw)
In-Reply-To: <1133713324.3168.3.camel@localhost>

On Sun, Dec 04, 2005 at 04:22:03PM +0000, Alan Cox wrote:
 > On Llu, 2005-11-28 at 01:32 -0500, Dave Jones wrote:
 > > On some variants of the VIA C3, we need to quiesce all DMA operations
 > > before we do a speed transition. We currently don't do that.
 > > I do have a patch from someone which adds support in the longhaul
 > > driver to wait for IDE transactions to stop, but to do it cleanly,
 > > we really need some callbacks into the IDE layer.
 > 
 > I was under the impression you could turn the IO/MEM enable on the root
 > bridge off momentarily to get the needed DMA pause safely ? Or does it
 > abort rather than retry at that point ?

I haven't tried that. Is that a safe thing to do ?
We do now disable mastering on all pci devices around the transition
as mandated in the spec, but that didn't really do much either.

Here's the patch I got from one user, which 'worked'...


Subject: [CPUFREQ] longhaul - avoid ide timeouts when bus mastering is off.

I really don't like this. Really.
Unfortunatly its necessary, otherwise after the transition, we live
for just a few minutes, and then just lockup.  In an ideal world,
the pm layer would allow some means of walking the device tree
quiescing DMA. Sadly, we don't live in an ideal world.

I'm open to suggestions on better ways to do this, as I'd rather
not push this to Linus' tree.

>From patch by: Ken Staton <ken_staton@agilent.com>
Signed-off-by: Dave Jones <davej@redhat.com>

--- linux-2.6.11/arch/i386/kernel/cpu/cpufreq/longhaul.c~	2005-05-24 01:51:51.000000000 -0400
+++ linux-2.6.11/arch/i386/kernel/cpu/cpufreq/longhaul.c	2005-05-24 01:52:07.000000000 -0400
@@ -30,6 +30,8 @@
 #include <linux/slab.h>
 #include <linux/string.h>
 #include <linux/pci.h>
+#include <linux/ide.h>
+#include <linux/delay.h>
 
 #include <asm/msr.h>
 #include <asm/timex.h>
@@ -91,6 +91,25 @@ static char *print_speed(int speed)
 }
 #endif
 
+static void ide_idle(void)
+ {
+	int i;
+	ide_hwif_t *hwif = ide_hwifs;
+	ide_drive_t *drive;
+
+	i = 0;
+	do {
+		drive = &hwif->drives[i];
+		i++;
+		if (strncmp(drive->name,"hd",2) == 0) {
+			while (drive->waiting_for_dma)
+			udelay(10);
+		} else {
+			i = 0;
+		}
+	} while (i != 0);
+}	
+
 
 static unsigned int calc_speed(int mult)
 {
@@ -146,6 +165,7 @@ static void do_powersaver(union msr_long
 	longhaul->bits.RevisionKey = 0;
 
 	preempt_disable();
+	ide_idle();	/* avoid ide timeouts when bus master off */
 	local_irq_save(flags);
 
 	/*

Whilst it may work fine, and 99.9% of VIA systems are likely IDE, it does
nothing about SCSI, so it's not quite perfect.

That said, even a 99% coverage is better than a 0% coverage we currently have.

It also seems quite racy, as it does nothing to prevent new transactions
from beginning after the drive has become idle.

		Dave


      reply	other threads:[~2005-12-06 17:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-28  5:02 IDE + CPU Scaling problem on Via EPIA systems gboyce
2005-11-28  6:32 ` Dave Jones
2005-12-04 16:22   ` Alan Cox
2005-12-06 17:05     ` Dave Jones [this message]

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=20051206170533.GB440@redhat.com \
    --to=davej@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gboyce@badbelly.com \
    --cc=linux-kernel@vger.kernel.org \
    /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