From: "Rafał Bilski" <rafalbilski@interia.pl>
To: Greg Kroah-Hartman <gregkh@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores
Date: Wed, 28 Jun 2006 20:25:43 +0200 [thread overview]
Message-ID: <44A2C9A7.6060703@interia.pl> (raw)
> You mean the longhaul driver can change the frequency of the PCI
> bus? Oh, that's a recipe for disaster...
No. Sorry. My English is bad. I mean changing CPU frequency.
> No, it's a hack :)
Again :-)
> No, this is not acceptable. What exactly do you want to do here? Make
> sure the PCI drivers are not doing DMA when the longhaul driver wants to
> change the pci bus speed?
I'm trying not to break DMA. Current version of longhaul (marked broken
in 2.6.16.2) simply clears bus master bit on every device.
> Does it really save battery?
Yes. And CPU temperature is lower.
> And what about PCI devices that always do DMA? (think USB controllers,
> they can easily saturate the PCI bus all the time).
This is worst for SATA. USB (this is strange) seems to work correcly.
I know that this is 10% coverage, but it is better then nothing.
It is always possible to add support for longhaul to driver.
> Why not just suspend all PCI devices make the bus change, and then
> resume them? That would require no PCI core, or driver changes.
This was my first idea. But trust me in current kernel this is simply
worst idea.
> greg k-h
> Though currently in the driver, voltage scaling is missing,
> so we never save any power, and just run at the maximum voltage
> the whole time.
I added this to longhaul, but it only works on non EBGA CPU's.
EBGA CPU's (at least Nehemiah) seem to have voltage scaling
disabled.
> It needs there to be no bus mastering occuring at the time
> of a CPU speed transition. Though I'm unable to find the part that mentions
> this in the specs I have right now.
> Dave
"Once this is set, the processor will switch to the
value in [26:23] on the next AUTOHALT transition. The duration of the AUTOHALT
should be >=1ms to ensure the CPU's internal PLL is resynchronized. For
AUTOHALT, this means interrupts must be disabled except for the time tick,
which should be reset to >=1ms. Care must be taken to avoid other system events
that could interfere with this operation. A few examples are snooping, NMI,
INIT, SMI and FLUSH."
For CPU's with Longhaul MSR this time is equal to 200us.
Rafał
----------------------------------------------------------------------
PS. Fajny portal... >>> http://link.interia.pl/f196a
next reply other threads:[~2006-06-28 18:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 18:25 Rafał Bilski [this message]
2006-06-29 11:37 ` [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores Alan Cox
2006-06-29 12:03 ` Bart Hartgers
2006-06-29 12:50 ` Rafał Bilski
2006-06-29 14:12 ` Rafał Bilski
2006-06-29 15:01 ` Bart Hartgers
2006-06-29 15:40 ` Rafał Bilski
2006-06-30 10:46 ` Bart Hartgers
2006-06-29 15:16 ` Bart Hartgers
2006-06-29 15:55 ` Alan Cox
2006-06-29 18:54 ` Rafał Bilski
2006-06-29 15:52 ` Alan Cox
[not found] <fa.lpmuYQxc6OV7Bh11JMM/FzqVWyY@ifi.uio.no>
2006-06-29 23:17 ` Robert Hancock
2006-07-01 18:02 ` Rafał Bilski
-- strict thread matches above, loose matches on Subject: below --
2006-06-28 13:56 Rafał Bilski
2006-06-28 17:34 ` Greg KH
2006-06-28 18:03 ` Alan Cox
2006-06-28 18:00 ` Jeremy Fitzhardinge
2006-06-28 18:10 ` 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=44A2C9A7.6060703@interia.pl \
--to=rafalbilski@interia.pl \
--cc=gregkh@suse.de \
--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 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.