All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: ken_staton@agilent.com
Cc: cpufreq@lists.linux.org.uk
Subject: Re: [PATCH] longhaul
Date: Wed, 20 Apr 2005 14:47:21 -0400	[thread overview]
Message-ID: <20050420184721.GL2476@redhat.com> (raw)
In-Reply-To: <3EFE14A8A1A82D4BB867A48A01A88ED708A096@waglmb01.labs.agilent.com>

On Wed, Apr 20, 2005 at 11:18:20AM -0700, ken_staton@agilent.com wrote:

 > > I wonder if the ide layer should have a way to quiesce dma that
 > > we can use instead of doing this here.
 > > Maybe it already does, I'm not too familiar with its internals.
 > i'll look again. i didn't find a more direct way. 

If it doesn't exist, it's worth bringing this up with the IDE folks
at linux-ide@vger.kernel.org to be sure theres no other evil
ide gotchas we need to know about.  This still doesn't solve the
problem of DMA from SATA / SCSI though.  Any ideas ?

 > > This bit bothers me a little, as we're not saving any state
 > > to record whether the devices had mastering enabled.
 > 
 > state is saved here:
 > >  > +			cmd_state[i++] = pci_cmd;

Doh, somehow I completely misread that. looks fine.
 
 > > Also, from my reading of the PCI spec, if we disable mastering
 > > in the root bridge, every device downstream of that should
 > > also be transparently disabled. Can you try that ?
 > the root bridge command register is read only.
 > use setpci -s 0:0.0 4.w to confirm

Hmm, I was sure I read otherwise in the spec/mindshare book.
I'll have another read of that when I get home.

 > >  >  	longhaul->bits.EnableSoftBusRatio = 0;
 > >  >  	longhaul->bits.RevisionKey = version;
 > >  > -	local_irq_disable();
 > >  > +
 > >  >  	wrmsrl(MSR_VIA_LONGHAUL, longhaul->val);
 > >  > -	local_irq_enable();
 > >  > +
 > > 
 > > Doesn't the spec say we need ints off around transitions ?
 > i didn't read it that way.
 > in fact an interrupt is one way to bring the PLL back up after hlt;
 > the timer int is the only one we can conveniently control.
 > 
 > the second write to the MSR doesn't do a PLL transition.

Ok, I'm convinced.


		Dave

  reply	other threads:[~2005-04-20 18:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-20 18:18 [PATCH] longhaul ken_staton
2005-04-20 18:47 ` Dave Jones [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-05-29 13:25 [PATCH] Longhaul Rafał Bilski
2005-04-20 16:49 [PATCH] longhaul ken_staton
2005-04-20 18:03 ` Dave Jones

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=20050420184721.GL2476@redhat.com \
    --to=davej@redhat.com \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=ken_staton@agilent.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.