Re: [PATCH] PCI: Add pci shutdown ability

From: Adam Belay (ambx1_at_neo.rr.com)
Date: 04/26/05

  • Next message: Andrew Morton: "Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation"
    Date:	Mon, 25 Apr 2005 19:23:31 -0400
    To: Dave Jones <davej@redhat.com>, Andrew Morton <akpm@osdl.org>, Alan Stern <stern@rowland.harvard.edu>, alexn@dsv.su.se, greg@kroah.com, gud@eth.net, linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz, jgarzik@pobox.com, cramerj@intel.com, linux-usb-devel@lists.sourceforge.net
    
    

    On Mon, Apr 25, 2005 at 06:13:27PM -0400, Dave Jones wrote:
    > On Mon, Apr 25, 2005 at 02:58:31PM -0700, Andrew Morton wrote:
    > > Alan Stern <stern@rowland.harvard.edu> wrote:
    > > >
    > > > On Mon, 25 Apr 2005, Alexander Nyberg wrote:
    > > >
    > > > > Not sure what you mean by "make kexec work nicer" but if it is because
    > > > > some devices don't work after a kexec I have some objections.
    > > >
    > > > That was indeed the reason, at least in my case. The newly-rebooted
    > > > kernel doesn't work too well when there are active devices, with no driver
    > > > loaded, doing DMA and issuing IRQs because they were never shut down.
    > >
    > > I have vague memories of this being discussed at some length last year.
    > > Nothing comprehensive came of it, except that perhaps the kdump code should
    > > spin with irqs off for a couple of seconds so the DMA and IRQs stop.
    > >
    > > (Ongoing DMA is not a problem actually, because the kdump kernel won't be
    > > using that memory anyway)
    >
    > Actually, some cpufreq drivers *should* do their speed transitions with
    > all PCI mastering disabled. The lack of any infrastructure to quiesce drivers
    > and prevent new DMA transactions from occuring whilst the transition occurs
    > means that currently.. we don't. So +1 for any driver model work that
    > may lead to something we can use here.
    >
    > This is the main reason the longhaul cpufreq driver is currently busted.
    > That it ever worked at all is a miracle.
    >
    > Dave

    I've been considering for a while that, in addition to ->probe and ->remove, we
    have the following:

    "struct device" -->
    ->attach - binds to the device and allocates data structures
    ->probe - detects and sets up the hardware
    ->start - begins transactions (like DMA)
    ->stop - stops transactions
    ->remove - prepares the hardware for no driver control
    ->detach - frees stuff and unbinds the device

    ->start and ->stop would be optional, and only used where they apply.

    ->probe and ->remove would be useful for resource rebalancing

    Power management functions could (and usually should) manually call some of
    these. Also this would be useful for error recovery and restarting devices.

    Still, cpufreq seems like a difficult problem. What's to prevent,
    hypothetically, an SMP system from stoping a device while the upper class
    layer tries to use it. If the class level locks control of the device, then
    DMA can't be stopped. Also, attempting to stop device activity may fail
    if the driver decides it's not possible.

    Thanks,
    Adam
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Andrew Morton: "Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation"

    Relevant Pages

    • Re: What are the general causes of frozen system?
      ... > system has frozen whenever I load the driver. ... TX DMA was OK. ... Another common cause is a stale interrupt, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH/Example] using dma_get_required_mask() in sym2
      ... having to have it compiled in to the driver). ... * We may want to use segment registers for 64 bit DMA. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [Panic] ieee1394 HD when moving files
      ... > port), The kernel sytematically panic and crashed with the same error. ... > The problem seems to come from the DMA part of the OHCI1394 driver and affect ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • What are the general causes of frozen system?
      ... I am trying to help the bcm43xx project develop a driver for the ... TX DMA was OK. ... What should I consider as a cause of the freeze? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] disable PCIE Enable No Snoop bit by default
      ... assumes PCI DMA is snooped, which is legacy PCI device does. ... driver can work with no snoop, we can provide a helper to enable it. ... Set the No Snoop bit in the Requester Attributes of transactions it ...
      (Linux-Kernel)