public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Rafa? Bilski <rafalbilski@interia.pl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores
Date: Wed, 28 Jun 2006 10:34:48 -0700	[thread overview]
Message-ID: <20060628173448.GA2371@suse.de> (raw)
In-Reply-To: <44A28AA2.6060306@interia.pl>

On Wed, Jun 28, 2006 at 03:56:50PM +0200, Rafa? Bilski wrote:
> 	This patch will allow Longhaul cpufreq driver to change frequency
> without breaking BMDMA. In order to work properly it needs:
> - adding rw_semaphore to pci_device and bus structures - this is
> patch below,
> - Longhaul should find host bridge and lock write on bus before
> frequency change,

Eeek!  You mean the longhaul driver can change the frequency of the PCI
bus?  Oh, that's a recipe for disaster...

> - device driver support - device should lock read its bus before
> starting DMA transfer. I have curently implemented this for ide
> layer (tested with via82cxxx), libata (not tested, but this is similar
> code to ide) and VIA Rhine network card driver.
> 	I don't know if this is acceptable infrastructure, but I hope it is
> less horrible then last. Is this infrastructure at all?

No, it's a hack :)

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?

How often will this bus change happen?

Does it really save battery?

Will all PCI devices work properly at different speeds from what they
originally thought they were running at?

And what about PCI devices that always do DMA?  (think USB controllers,
they can easily saturate the PCI bus all the time).

Why not just suspend all PCI devices make the bus change, and then
resume them?  That would require no PCI core, or driver changes.

thanks,

greg k-h

  reply	other threads:[~2006-06-28 17:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-28 13:56 [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores Rafał Bilski
2006-06-28 17:34 ` Greg KH [this message]
2006-06-28 18:03   ` Alan Cox
2006-06-28 18:00     ` Jeremy Fitzhardinge
2006-06-28 18:10   ` Dave Jones
  -- strict thread matches above, loose matches on Subject: below --
2006-06-28 18:25 Rafał Bilski
2006-06-29 11:37 ` 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

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=20060628173448.GA2371@suse.de \
    --to=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafalbilski@interia.pl \
    /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