LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 04/11] PCI/hotplug: Needn't remove EEH cache again
From: Benjamin Herrenschmidt @ 2013-07-24 21:47 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, linuxppc-dev, Gavin Shan
In-Reply-To: <CAErSpo7rXF9vf=BMT1LoLeHPRiyJxT2XWbroRjdt+DH8+4QOnA@mail.gmail.com>

On Wed, 2013-07-24 at 12:02 -0600, Bjorn Helgaas wrote:
> [+cc linux-pci]
> 
> On Tue, Jul 23, 2013 at 8:24 PM, Gavin Shan <shangw@linux.vnet.ibm.com> wrote:
> > Since pcibios_release_device() called by pci_stop_and_remove_bus_device()
> > has removed the EEH cache, we needn't do that again.
> >
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> 
> I'll be happy to merge this if you want, or since you have my Ack
> already, you can merge it with the rest of the series.  I didn't get
> the rest of the series, so I don't know if it depends on this.
> 
> Just let me know what you want me to do.

Already merged :-)

Thanks !

Cheers,
Ben.

> > ---
> >  drivers/pci/hotplug/rpadlpar_core.c |    1 -
> >  1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
> > index b29e20b..bb7af78 100644
> > --- a/drivers/pci/hotplug/rpadlpar_core.c
> > +++ b/drivers/pci/hotplug/rpadlpar_core.c
> > @@ -388,7 +388,6 @@ int dlpar_remove_pci_slot(char *drc_name, struct device_node *dn)
> >         /* Remove the EADS bridge device itself */
> >         BUG_ON(!bus->self);
> >         pr_debug("PCI: Now removing bridge device %s\n", pci_name(bus->self));
> > -       eeh_remove_bus_device(bus->self, true);
> >         pci_stop_and_remove_bus_device(bus->self);
> >
> >         return 0;
> > --
> > 1.7.5.4
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages
From: Scott Wood @ 2013-07-24 20:32 UTC (permalink / raw)
  To: Alexander Graf
  Cc: Wood Scott-B07421, Gleb Natapov, kvm@vger.kernel.org list,
	kvm-ppc@vger.kernel.org, “tiejun.chen”,
	Bhushan Bharat-R65777, Paolo Bonzini, linuxppc-dev
In-Reply-To: <03EEFDFE-4603-44FC-8449-2450607F2864@suse.de>

On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
>=20
> On 24.07.2013, at 11:35, Gleb Natapov wrote:
>=20
> > On Wed, Jul 24, 2013 at 11:21:11AM +0200, Alexander Graf wrote:
> >>> Are not we going to use page_is_ram() from  =20
> e500_shadow_mas2_attrib() as Scott commented?
> >>
> >> rWhy aren't we using page_is_ram() in kvm_is_mmio_pfn()?
> >>
> >>
> > Because it is much slower and, IIRC, actually used to build pfn map =20
> that allow
> > us to check quickly for valid pfn.
>=20
> Then why should we use page_is_ram()? :)
>=20
> I really don't want the e500 code to diverge too much from what the =20
> rest of the kvm code is doing.

I don't understand "actually used to build pfn map...".  What code is =20
this?  I don't see any calls to page_is_ram() in the KVM code, or in =20
generic mm code.  Is this a statement about what x86 does?

On PPC page_is_ram() is only called (AFAICT) for determining what =20
attributes to set on mmaps.  We want to be sure that KVM always makes =20
the same decision.  While pfn_valid() seems like it should be =20
equivalent, it's not obvious from the PPC code that it is.

If pfn_valid() is better, why is that not used for mmap?  Why are there =20
two different names for the same thing?

-Scott=

^ permalink raw reply

* Re: [PATCH v5 4/4] DMA: Freescale: eliminate a compiling warning
From: Scott Wood @ 2013-07-24 19:33 UTC (permalink / raw)
  To: hongbo.zhang
  Cc: devicetree, vinod.koul, linux-kernel, Hongbo Zhang, djbw,
	linuxppc-dev
In-Reply-To: <1374646870-5162-5-git-send-email-hongbo.zhang@freescale.com>

On 07/24/2013 01:21:09 AM, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>=20
> The variable cookie is initialized in a list_for_each_entry loop, =20
> if(unlikely)
> the list is empty, this variable will be used uninitialized, so we =20
> get a gcc
> compiling warning about this. This patch fixes this defect by setting =20
> an
> initial value to the varialble cookie.
>=20
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> ---
>  drivers/dma/fsldma.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 16a9a48..14d68a4 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct =20
> dma_async_tx_descriptor *tx)
>  	struct fsl_desc_sw *desc =3D tx_to_fsl_desc(tx);
>  	struct fsl_desc_sw *child;
>  	unsigned long flags;
> -	dma_cookie_t cookie;
> +	dma_cookie_t cookie =3D 0;
>=20
>  	spin_lock_irqsave(&chan->desc_lock, flags);

This patch is unrelated to the rest of the patch series...

What are the semantics of this function if there are multiple entries =20
in the list?  Returning the last cookie seems a bit odd.

Is zero the proper error value?  include/linux/dmaengine.h suggests =20
that cookies should be < 0 to indicate error.

-Scott=

^ permalink raw reply

* Re: [PATCH v5 3/4] DMA: Freescale: update driver to support 8-channel DMA engine
From: Scott Wood @ 2013-07-24 19:30 UTC (permalink / raw)
  To: hongbo.zhang
  Cc: devicetree, vinod.koul, linux-kernel, Hongbo Zhang, djbw,
	linuxppc-dev
In-Reply-To: <1374646870-5162-4-git-send-email-hongbo.zhang@freescale.com>

On 07/24/2013 01:21:08 AM, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>=20
> This patch adds support to 8-channel DMA engine, thus the driver =20
> works for both
> the new 8-channel and the legacy 4-channel DMA engines.
>=20
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> ---
>  drivers/dma/Kconfig  |    9 +++++----
>  drivers/dma/fsldma.c |    9 ++++++---
>  drivers/dma/fsldma.h |    2 +-
>  3 files changed, 12 insertions(+), 8 deletions(-)
>=20
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 6825957..1b78272 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -89,14 +89,15 @@ config AT_HDMAC
>  	  Support the Atmel AHB DMA controller.
>=20
>  config FSL_DMA
> -	tristate "Freescale Elo and Elo Plus DMA support"
> +	tristate "Freescale Elo series DMA support"
>  	depends on FSL_SOC
>  	select DMA_ENGINE
>  	select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>  	---help---
> -	  Enable support for the Freescale Elo and Elo Plus DMA =20
> controllers.
> -	  The Elo is the DMA controller on some 82xx and 83xx parts, =20
> and the
> -	  Elo Plus is the DMA controller on 85xx and 86xx parts.
> +	  Enable support for the Freescale Elo series DMA controllers.
> +	  The Elo is the DMA controller on some mpc82xx and mpc83xx =20
> parts, the
> +	  EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the =20
> Elo3 is on
> +	  some Txxx and Bxxx parts. Look up user manuals for details =20
> anyway.

The user manuals do not use the "elo" terminology.  I also don't =20
understand the tone you're trying to convey with "anyway".

-Scott=

^ permalink raw reply

* Re: [PATCH v5 2/4] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Scott Wood @ 2013-07-24 19:29 UTC (permalink / raw)
  To: hongbo.zhang
  Cc: devicetree, vinod.koul, linux-kernel, Hongbo Zhang, djbw,
	linuxppc-dev
In-Reply-To: <1374646870-5162-3-git-send-email-hongbo.zhang@freescale.com>

On 07/24/2013 01:21:07 AM, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>=20
> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this =20
> patch add
> the device tree nodes for them.
>=20
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> ---
>  .../devicetree/bindings/powerpc/fsl/dma.txt        |   66 =20
> ++++++++++++++++
>  arch/powerpc/boot/dts/fsl/b4si-post.dtsi           |    4 +-
>  arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi          |   81 =20
> ++++++++++++++++++++
>  arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi          |   81 =20
> ++++++++++++++++++++
>  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi        |    4 +-
>  5 files changed, 232 insertions(+), 4 deletions(-)
>  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
>  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
>=20
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt =20
> b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> index ed703d9..54a023b2 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> @@ -130,6 +130,72 @@ Example:
>  		};
>  	};
>=20
> +** Freescale Elo3 DMA Controller
> +   This is EloPlus controller with 8 channels, used in Freescale =20
> Txxx and Bxxx
> +   series chips, such as t1040, t4240, b4860.
> +
> +Required properties:
> +
> +- compatible        : should be "fsl,elo3-dma"

Should include "fsl,elo3-dma".  There's nothing different about elo3 =20
versus elo/eloplus regarding whether fsl,CHIP-dma is allowed.  I'd just =20
drop the references to fsl,CHIP-dma throughout the binding, and phrase =20
the compatible description as "must include" rather than "must be" so =20
that additional strings are allowed.

-Scott=

^ permalink raw reply

* Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
From: Scott Wood @ 2013-07-24 19:22 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Neil Horman, Rusty Russell, linux-kernel, Paul Mackerras,
	Anton Blanchard, linuxppc-dev
In-Reply-To: <20130723133032.GB31944@concordia>

On 07/23/2013 08:30:32 AM, Michael Ellerman wrote:
> On Fri, Jul 19, 2013 at 05:59:30PM -0500, Scott Wood wrote:
> > On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
> > >
> > >Hi Scott,
> > >
> > >> What specifically should I do to test it?
> > >
> > >Could you double check perf annotate works? I'm 99% sure it will =20
> but
> > >that is what was failing on ppc64.
> >
> > I'm not really sure what it's supposed to look like when "perf
> > annotate" works.  It spits a bunch of unreadable[1]
> > dark-blue-on-black assembly code at me, all with "0.00 :" in the
> > left column.
> >
> > Oh, wait -- some lines have "100.00 : " on the left, in
> > even-more-unreadable dark-red-on-black.
> >
> > Apart from the annoying colors, is there anything specific I should
> > be looking for?  Some sort of error message, or output that actually
> > makes sense?
>=20
> The colours look fine on my terminal, so I don't know what you've done
> there.

It probably looks better if the terminal is configured to have a light =20
background (which of course makes some other programs look worse), or =20
(as I noted) if you've got your monitor set to be very bright.  I now =20
see that xfce4-terminal lets me redefine the standard colors, though, =20
so that should help.

> If you care you can use "--stdio" to use the plainer interface,
> though it still uses colours.
>=20
> That output looks fine in terms of the bug Anton was chasing. As far =20
> as
> only ever hitting one instruction that does look weird.

OK.  I'll add "investigate weird e500 perf annotate results" to the =20
TODO list...

-Scott=

^ permalink raw reply

* [PATCH 8/8] Remove no longer needed powerpc memory node update handler
From: Nathan Fontenot @ 2013-07-24 18:47 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

Remove the update_node handler for powerpc/pseries.

Now that we can do memory dlpar in the kernel we no longer need the of
update node notifier to update the ibm,dynamic-memory property of the
ibm,dynamic-reconfiguration-memory node. This work is now handled by
the memory notification handlers for powerpc/pseries.

This patch also conditionally registers the handler for of node remove
if we are not using the ibm,dynamic-reconfiguration-memory device tree
layout. That handler is only needed for handling memory@XXX nodes
in the device tree.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
 arch/powerpc/platforms/pseries/hotplug-memory.c |   60 +++---------------------
 1 file changed, 8 insertions(+), 52 deletions(-)

Index: linux/arch/powerpc/platforms/pseries/hotplug-memory.c
===================================================================
--- linux.orig/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ linux/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -166,67 +166,15 @@ static inline int pseries_remove_memory(
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
 
-static int pseries_update_drconf_memory(struct of_prop_reconfig *pr)
-{
-	struct of_drconf_cell *new_drmem, *old_drmem;
-	unsigned long memblock_size;
-	u32 entries;
-	u32 *p;
-	int i, rc = -EINVAL;
-
-	memblock_size = get_memblock_size();
-	if (!memblock_size)
-		return -EINVAL;
-
-	p = (u32 *)of_get_property(pr->dn, "ibm,dynamic-memory", NULL);
-	if (!p)
-		return -EINVAL;
-
-	/* The first int of the property is the number of lmb's described
-	 * by the property. This is followed by an array of of_drconf_cell
-	 * entries. Get the niumber of entries and skip to the array of
-	 * of_drconf_cell's.
-	 */
-	entries = *p++;
-	old_drmem = (struct of_drconf_cell *)p;
-
-	p = (u32 *)pr->prop->value;
-	p++;
-	new_drmem = (struct of_drconf_cell *)p;
-
-	for (i = 0; i < entries; i++) {
-		if ((old_drmem[i].flags & DRCONF_MEM_ASSIGNED) &&
-		    (!(new_drmem[i].flags & DRCONF_MEM_ASSIGNED))) {
-			rc = pseries_remove_memblock(old_drmem[i].base_addr,
-						     memblock_size);
-			break;
-		} else if ((!(old_drmem[i].flags & DRCONF_MEM_ASSIGNED)) &&
-			   (new_drmem[i].flags & DRCONF_MEM_ASSIGNED)) {
-			rc = memblock_add(old_drmem[i].base_addr,
-					  memblock_size);
-			rc = (rc < 0) ? -EINVAL : 0;
-			break;
-		}
-	}
-
-	return rc;
-}
-
 static int pseries_memory_notifier(struct notifier_block *nb,
 				   unsigned long action, void *node)
 {
-	struct of_prop_reconfig *pr;
 	int err = 0;
 
 	switch (action) {
 	case OF_RECONFIG_DETACH_NODE:
 		err = pseries_remove_memory(node);
 		break;
-	case OF_RECONFIG_UPDATE_PROPERTY:
-		pr = (struct of_prop_reconfig *)node;
-		if (!strcmp(pr->prop->name, "ibm,dynamic-memory"))
-			err = pseries_update_drconf_memory(pr);
-		break;
 	}
 	return notifier_from_errno(err);
 }
@@ -237,6 +185,14 @@ static struct notifier_block pseries_mem
 
 static int __init pseries_memory_hotplug_init(void)
 {
+	struct device_node *dn;
+
+	dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
+	if (dn) {
+		of_node_put(dn);
+		return 0;
+	}
+
 	if (firmware_has_feature(FW_FEATURE_LPAR))
 		of_reconfig_notifier_register(&pseries_mem_nb);
 

^ permalink raw reply

* [PATCH 7/8]  Add memory hot add/remove notifier handlers for pwoerpc
From: Nathan Fontenot @ 2013-07-24 18:45 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

Add memory hot add/remove notifier handlers for powerpc/pseries.

This patch allows the powerpc/pseries platforms to perform memory DLPAR
int the kernel. The handlers for add and remove do the work of
acquiring/releasing the memory to firmware and updating the device tree.

This is only used when memory is specified in the
ibm,dynamic-reconfiguration-memory device tree node so the memory notifiers
are registered contingent on its existence.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
 arch/powerpc/platforms/pseries/dlpar.c |  103 +++++++++++++++++++++++++++++++++
 1 file changed, 103 insertions(+)

Index: linux/arch/powerpc/platforms/pseries/dlpar.c
===================================================================
--- linux.orig/arch/powerpc/platforms/pseries/dlpar.c
+++ linux/arch/powerpc/platforms/pseries/dlpar.c
@@ -15,6 +15,7 @@
 #include <linux/notifier.h>
 #include <linux/spinlock.h>
 #include <linux/cpu.h>
+#include <linux/memory.h>
 #include <linux/slab.h>
 #include <linux/of.h>
 #include "offline_states.h"
@@ -531,11 +532,113 @@ out:
 	return rc ? rc : count;
 }
 
+static struct of_drconf_cell *dlpar_get_drconf_cell(struct device_node *dn,
+						    unsigned long phys_addr)
+{
+	struct of_drconf_cell *drmem;
+	u32 entries;
+	u32 *prop;
+	int i;
+
+	prop = (u32 *)of_get_property(dn, "ibm,dynamic-memory", NULL);
+	of_node_put(dn);
+	if (!prop)
+		return NULL;
+
+	entries = *prop++;
+	drmem = (struct of_drconf_cell *)prop;
+
+	for (i = 0; i < entries; i++) {
+		if (drmem[i].base_addr == phys_addr)
+			return &drmem[i];
+	}
+
+	return NULL;
+}
+
+static int dlpar_mem_probe(unsigned long phys_addr)
+{
+	struct device_node *dn;
+	struct of_drconf_cell *drmem;
+	int rc;
+
+	dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
+	if (!dn)
+		return -EINVAL;
+
+	drmem = dlpar_get_drconf_cell(dn, phys_addr);
+	of_node_put(dn);
+
+	if (!drmem)
+		return -EINVAL;
+
+	if (drmem->flags & DRCONF_MEM_ASSIGNED)
+		return 0;
+
+	drmem->flags |= DRCONF_MEM_ASSIGNED;
+
+	rc = dlpar_acquire_drc(drmem->drc_index);
+	return rc;
+}
+
+static int dlpar_mem_release(unsigned long phys_addr)
+{
+	struct device_node *dn;
+	struct of_drconf_cell *drmem;
+	int rc;
+
+	dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
+	if (!dn)
+		return -EINVAL;
+
+	drmem = dlpar_get_drconf_cell(dn, phys_addr);
+	of_node_put(dn);
+
+	if (!drmem)
+		return -EINVAL;
+
+	if (!drmem->flags & DRCONF_MEM_ASSIGNED)
+		return 0;
+
+	drmem->flags &= ~DRCONF_MEM_ASSIGNED;
+
+	rc = dlpar_release_drc(drmem->drc_index);
+	return rc;
+}
+
+static int pseries_dlpar_mem_callback(struct notifier_block *nb,
+				      unsigned long action, void *hp_arg)
+{
+	struct memory_notify *arg = hp_arg;
+	unsigned long phys_addr = arg->start_pfn << PAGE_SHIFT;
+	int rc = 0;
+
+
+	switch (action) {
+	case MEM_BEING_HOT_ADDED:
+		rc = dlpar_mem_probe(phys_addr);
+		break;
+	case MEM_HOT_REMOVED:
+		rc = dlpar_mem_release(phys_addr);
+		break;
+	}
+
+	return notifier_from_errno(rc);
+}
+
 static int __init pseries_dlpar_init(void)
 {
+	struct device_node *dn;
+
 	ppc_md.cpu_probe = dlpar_cpu_probe;
 	ppc_md.cpu_release = dlpar_cpu_release;
 
+	dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
+	if (dn) {
+		hotplug_memory_notifier(pseries_dlpar_mem_callback, 0);
+		of_node_put(dn);
+	}
+
 	return 0;
 }
 machine_device_initcall(pseries, pseries_dlpar_init);

^ permalink raw reply

* [PATCH 6/8] Update the powerpc arch specific memory add/remove handlers
From: Nathan Fontenot @ 2013-07-24 18:44 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

In order to properly hot add and remove memory for powerpc the arch
specific callouts need to now complete all of the required work to
fully add or remove the memory.

With this update we can also remove the handler for memory node add
because the powerpc arch specific memory add handler will do all the
work needed. We do still need the memory node remove handler because
systems with memory specified in the memory@XXX nodes in the device tree
we have to use the removal of the node to trigger memory hot remove.

For systems on newer firmware with memory specified in the
ibm,dynamic-reconfiguration-memory node of the device tree this is not an
issue.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
 arch/powerpc/mm/mem.c                           |   33 +++++++++++++++++++---
 arch/powerpc/platforms/pseries/hotplug-memory.c |   35 ------------------------
 2 files changed, 29 insertions(+), 39 deletions(-)

Index: linux/arch/powerpc/mm/mem.c
===================================================================
--- linux.orig/arch/powerpc/mm/mem.c
+++ linux/arch/powerpc/mm/mem.c
@@ -35,6 +35,7 @@
 #include <linux/memblock.h>
 #include <linux/hugetlb.h>
 #include <linux/slab.h>
+#include <linux/vmalloc.h>
 
 #include <asm/pgalloc.h>
 #include <asm/prom.h>
@@ -120,17 +121,24 @@ int arch_add_memory(int nid, u64 start,
 	struct zone *zone;
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
+	u64 va_start;
+	int ret;
 
 	pgdata = NODE_DATA(nid);
 
-	start = (unsigned long)__va(start);
-	if (create_section_mapping(start, start + size))
+	va_start = (unsigned long)__va(start);
+	if (create_section_mapping(va_start, va_start + size))
 		return -EINVAL;
 
 	/* this should work for most non-highmem platforms */
 	zone = pgdata->node_zones;
 
-	return __add_pages(nid, zone, start_pfn, nr_pages);
+	ret = __add_pages(nid, zone, start_pfn, nr_pages);
+	if (ret)
+		return ret;
+
+	ret = memblock_add(start, size);
+	return ret;
 }
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
@@ -138,10 +146,27 @@ int arch_remove_memory(u64 start, u64 si
 {
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
+	unsigned long va_addr;
 	struct zone *zone;
+	int ret;
 
 	zone = page_zone(pfn_to_page(start_pfn));
-	return __remove_pages(zone, start_pfn, nr_pages);
+	ret = __remove_pages(zone, start_pfn, nr_pages);
+	if (ret)
+		return ret;
+
+	memblock_remove(start, size);
+
+	/* remove htab bolted mappings */
+	va_addr = (unsigned long)__va(start);
+	ret = remove_section_mapping(va_addr, va_addr + size);
+
+	/* Ensure all vmalloc mappings are flushed in case they also
+	 * hit that section of memory.
+	 */
+	vm_unmap_aliases();
+
+	return ret;
 }
 #endif
 #endif /* CONFIG_MEMORY_HOTPLUG */
Index: linux/arch/powerpc/platforms/pseries/hotplug-memory.c
===================================================================
--- linux.orig/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ linux/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -166,38 +166,6 @@ static inline int pseries_remove_memory(
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
 
-static int pseries_add_memory(struct device_node *np)
-{
-	const char *type;
-	const unsigned int *regs;
-	unsigned long base;
-	unsigned int lmb_size;
-	int ret = -EINVAL;
-
-	/*
-	 * Check to see if we are actually adding memory
-	 */
-	type = of_get_property(np, "device_type", NULL);
-	if (type == NULL || strcmp(type, "memory") != 0)
-		return 0;
-
-	/*
-	 * Find the base and size of the memblock
-	 */
-	regs = of_get_property(np, "reg", NULL);
-	if (!regs)
-		return ret;
-
-	base = *(unsigned long *)regs;
-	lmb_size = regs[3];
-
-	/*
-	 * Update memory region to represent the memory add
-	 */
-	ret = memblock_add(base, lmb_size);
-	return (ret < 0) ? -EINVAL : 0;
-}
-
 static int pseries_update_drconf_memory(struct of_prop_reconfig *pr)
 {
 	struct of_drconf_cell *new_drmem, *old_drmem;
@@ -251,9 +219,6 @@ static int pseries_memory_notifier(struc
 	int err = 0;
 
 	switch (action) {
-	case OF_RECONFIG_ATTACH_NODE:
-		err = pseries_add_memory(node);
-		break;
 	case OF_RECONFIG_DETACH_NODE:
 		err = pseries_remove_memory(node);
 		break;

^ permalink raw reply

* [PATCH 5/8] Add notifiers for memory hot add/remove
From: Nathan Fontenot @ 2013-07-24 18:41 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman, isimatu.yasuaki
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

In order to allow architectures or other subsystems to do any needed
work prior to hot adding or hot removing memory the memory notifier
chain should be updated to provide notifications of these events.

This patch adds the notifications for memory hot add and hot remove.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
--
 Documentation/memory-hotplug.txt |   26 +++++++++++++++++++++++---
 include/linux/memory.h           |    6 ++++++
 mm/memory_hotplug.c              |   25 ++++++++++++++++++++++---
 3 files changed, 51 insertions(+), 6 deletions(-)

Index: linux/include/linux/memory.h
===================================================================
--- linux.orig/include/linux/memory.h
+++ linux/include/linux/memory.h
@@ -50,6 +50,12 @@ int arch_get_memory_phys_device(unsigned
 #define	MEM_GOING_ONLINE	(1<<3)
 #define	MEM_CANCEL_ONLINE	(1<<4)
 #define	MEM_CANCEL_OFFLINE	(1<<5)
+#define MEM_BEING_HOT_REMOVED	(1<<6)
+#define MEM_HOT_REMOVED		(1<<7)
+#define MEM_CANCEL_HOT_REMOVE	(1<<8)
+#define MEM_BEING_HOT_ADDED	(1<<9)
+#define MEM_HOT_ADDED		(1<<10)
+#define MEM_CANCEL_HOT_ADD	(1<<11)

 struct memory_notify {
 	unsigned long start_pfn;
Index: linux/mm/memory_hotplug.c
===================================================================
--- linux.orig/mm/memory_hotplug.c
+++ linux/mm/memory_hotplug.c
@@ -1073,17 +1073,25 @@ out:
 int __ref add_memory(int nid, u64 start, u64 size)
 {
 	pg_data_t *pgdat = NULL;
-	bool new_pgdat;
+	bool new_pgdat = false;
 	bool new_node;
-	struct resource *res;
+	struct resource *res = NULL;
+	struct memory_notify arg;
 	int ret;

 	lock_memory_hotplug();

+	arg.start_pfn = start >> PAGE_SHIFT;
+	arg.nr_pages = size / PAGE_SIZE;
+	ret = memory_notify(MEM_BEING_HOT_ADDED, &arg);
+	ret = notifier_to_errno(ret);
+	if (ret)
+		goto error;
+
 	res = register_memory_resource(start, size);
 	ret = -EEXIST;
 	if (!res)
-		goto out;
+		goto error;

 	{	/* Stupid hack to suppress address-never-null warning */
 		void *p = NODE_DATA(nid);
@@ -1119,9 +1127,12 @@ int __ref add_memory(int nid, u64 start,
 	/* create new memmap entry */
 	firmware_map_add_hotplug(start, start + size, "System RAM");

+	memory_notify(MEM_HOT_ADDED, &arg);
 	goto out;

 error:
+	memory_notify(MEM_CANCEL_HOT_ADD, &arg);
+
 	/* rollback pgdat allocation and others */
 	if (new_pgdat)
 		rollback_node_hotadd(nid, pgdat);
@@ -1784,10 +1795,15 @@ EXPORT_SYMBOL(try_offline_node);

 void __ref remove_memory(int nid, u64 start, u64 size)
 {
+	struct memory_notify arg;
 	int ret;

 	lock_memory_hotplug();

+	arg.start_pfn = start >> PAGE_SHIFT;
+	arg.nr_pages = size / PAGE_SIZE;
+	memory_notify(MEM_BEING_HOT_REMOVED, &arg);
+
 	/*
 	 * All memory blocks must be offlined before removing memory.  Check
 	 * whether all memory blocks in question are offline and trigger a BUG()
@@ -1796,6 +1812,7 @@ void __ref remove_memory(int nid, u64 st
 	ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
 				is_memblock_offlined_cb);
 	if (ret) {
+		memory_notify(MEM_CANCEL_HOT_REMOVE, &arg);
 		unlock_memory_hotplug();
 		BUG();
 	}
@@ -1807,6 +1824,8 @@ void __ref remove_memory(int nid, u64 st

 	try_offline_node(nid);

+	memory_notify(MEM_HOT_REMOVED, &arg);
+
 	unlock_memory_hotplug();
 }
 EXPORT_SYMBOL_GPL(remove_memory);
Index: linux/Documentation/memory-hotplug.txt
===================================================================
--- linux.orig/Documentation/memory-hotplug.txt
+++ linux/Documentation/memory-hotplug.txt
@@ -371,7 +371,9 @@ Need more implementation yet....
 --------------------------------
 8. Memory hotplug event notifier
 --------------------------------
-Memory hotplug has event notifier. There are 6 types of notification.
+Memory hotplug has event notifier. There are 12 types of notification, the
+first six relate to memory hotplug and the second six relate to memory hot
+add/remove.

 MEMORY_GOING_ONLINE
   Generated before new memory becomes available in order to be able to
@@ -398,6 +400,24 @@ MEMORY_CANCEL_OFFLINE
 MEMORY_OFFLINE
   Generated after offlining memory is complete.

+MEMORY_BEING_HOT_REMOVED
+  Generated prior to the process of hot removing memory.
+
+MEMORY_CANCEL_HOT_REMOVE
+  Generated if MEMORY_BEING_HOT_REMOVED fails.
+
+MEMORY_HOT_REMOVED
+  Generated when memory has been successfully hot removed.
+
+MEMORY_BEING_HOT_ADDED
+  Generated prior to the process of hot adding memory.
+
+MEMORY_HOT_ADD_CANCEL
+  Generated if MEMORY_BEING_HOT_ADDED fails.
+
+MEMORY_HOT_ADDED
+  Generated when memory has successfully been hot added.
+
 A callback routine can be registered by
   hotplug_memory_notifier(callback_func, priority)

@@ -412,8 +432,8 @@ struct memory_notify {
        int status_change_nid;
 }

-start_pfn is start_pfn of online/offline memory.
-nr_pages is # of pages of online/offline memory.
+start_pfn is start_pfn of online/offline/add/remove memory.
+nr_pages is # of pages of online/offline/add/remove memory.
 status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask
 is (will be) set/clear, if this is -1, then nodemask status is not changed.
 status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask

^ permalink raw reply

* [PATCH 4/8] Create a sysfs release file for hot removing memory
From: Nathan Fontenot @ 2013-07-24 18:39 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman, isimatu.yasuaki
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

Provide a sysfs interface to hot remove memory.

This patch updates the sysfs interface for hot add of memory to also
provide a sysfs interface to hot remove memory. The use of this interface
is controlled with the ARCH_MEMORY_PROBE config option, currently used
by x86 and powerpc. This patch also updates the name of this option to
CONFIG_ARCH_MEMORY_PROBE_RELEASE to indicate that it controls the probe
and release sysfs interfaces.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
 Documentation/memory-hotplug.txt |   34 ++++++++++++----
 arch/powerpc/Kconfig             |    2 
 arch/x86/Kconfig                 |    2 
 drivers/base/memory.c            |   81 ++++++++++++++++++++++++++++++++++-----
 4 files changed, 100 insertions(+), 19 deletions(-)

Index: linux/drivers/base/memory.c
===================================================================
--- linux.orig/drivers/base/memory.c
+++ linux/drivers/base/memory.c
@@ -129,22 +129,30 @@ static ssize_t show_mem_end_phys_index(s
 	return sprintf(buf, "%08lx\n", phys_index);
 }
 
+static int is_memblock_removable(unsigned long start_section_nr)
+{
+	unsigned long pfn;
+	int i, ret = 1;
+
+	for (i = 0; i < sections_per_block; i++) {
+		pfn = section_nr_to_pfn(start_section_nr + i);
+		ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
+	}
+
+	return ret;
+}
+
 /*
  * Show whether the section of memory is likely to be hot-removable
  */
 static ssize_t show_mem_removable(struct device *dev,
 			struct device_attribute *attr, char *buf)
 {
-	unsigned long i, pfn;
-	int ret = 1;
+	int ret;
 	struct memory_block *mem =
 		container_of(dev, struct memory_block, dev);
 
-	for (i = 0; i < sections_per_block; i++) {
-		pfn = section_nr_to_pfn(mem->start_section_nr + i);
-		ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
-	}
-
+	ret = is_memblock_removable(mem->start_section_nr);
 	return sprintf(buf, "%d\n", ret);
 }
 
@@ -421,7 +429,7 @@ static DEVICE_ATTR(block_size_bytes, 044
  * as well as ppc64 will do all of their discovery in userspace
  * and will require this interface.
  */
-#ifdef CONFIG_ARCH_MEMORY_PROBE
+#ifdef CONFIG_ARCH_MEMORY_PROBE_RELEASE
 static ssize_t
 memory_probe_store(struct device *dev, struct device_attribute *attr,
 		   const char *buf, size_t count)
@@ -444,6 +452,60 @@ memory_probe_store(struct device *dev, s
 }
 
 static DEVICE_ATTR(probe, S_IWUSR, NULL, memory_probe_store);
+
+static int is_memblock_offline(struct memory_block *mem, void *arg)
+{
+	if (mem->state == MEM_ONLINE)
+		return 1;
+
+	return 0;
+}
+
+static ssize_t
+memory_release_store(struct device *dev, struct device_attribute *attr,
+		     const char *buf, size_t count)
+{
+	u64 phys_addr;
+	int nid, ret = 0;
+	unsigned long block_size, pfn;
+	unsigned long pages_per_block = PAGES_PER_SECTION * sections_per_block;
+
+	lock_device_hotplug();
+
+	ret = kstrtoull(buf, 0, &phys_addr);
+	if (ret)
+		goto out;
+
+	if (phys_addr & ((pages_per_block << PAGE_SHIFT) - 1)) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	block_size = get_memory_block_size();
+	nid = memory_add_physaddr_to_nid(phys_addr);
+
+	/* Ensure memory is offline and removable before removing it. */
+	ret = walk_memory_range(PFN_DOWN(phys_addr),
+				PFN_UP(phys_addr + block_size - 1), NULL,
+				is_memblock_offline);
+	if (!ret) {
+		pfn = phys_addr >> PAGE_SHIFT;
+		ret = !is_memblock_removable(pfn_to_section_nr(pfn));
+	}
+
+	if (ret) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	remove_memory(nid, phys_addr, block_size);
+
+out:
+	unlock_device_hotplug();
+	return ret ? ret : count;
+}
+
+static DEVICE_ATTR(release, S_IWUSR, NULL, memory_release_store);
 #endif
 
 #ifdef CONFIG_MEMORY_FAILURE
@@ -694,8 +756,9 @@ bool is_memblock_offlined(struct memory_
 }
 
 static struct attribute *memory_root_attrs[] = {
-#ifdef CONFIG_ARCH_MEMORY_PROBE
+#ifdef CONFIG_ARCH_MEMORY_PROBE_RELEASE
 	&dev_attr_probe.attr,
+	&dev_attr_release.attr,
 #endif
 
 #ifdef CONFIG_MEMORY_FAILURE
Index: linux/arch/powerpc/Kconfig
===================================================================
--- linux.orig/arch/powerpc/Kconfig
+++ linux/arch/powerpc/Kconfig
@@ -438,7 +438,7 @@ config SYS_SUPPORTS_HUGETLBFS
 
 source "mm/Kconfig"
 
-config ARCH_MEMORY_PROBE
+config ARCH_MEMORY_PROBE_RELEASE
 	def_bool y
 	depends on MEMORY_HOTPLUG
 
Index: linux/arch/x86/Kconfig
===================================================================
--- linux.orig/arch/x86/Kconfig
+++ linux/arch/x86/Kconfig
@@ -1343,7 +1343,7 @@ config ARCH_SELECT_MEMORY_MODEL
 	def_bool y
 	depends on ARCH_SPARSEMEM_ENABLE
 
-config ARCH_MEMORY_PROBE
+config ARCH_MEMORY_PROBE_RELEASE
 	def_bool y
 	depends on X86_64 && MEMORY_HOTPLUG
 
Index: linux/Documentation/memory-hotplug.txt
===================================================================
--- linux.orig/Documentation/memory-hotplug.txt
+++ linux/Documentation/memory-hotplug.txt
@@ -17,7 +17,9 @@ be changed often.
 3. sysfs files for memory hotplug
 4. Physical memory hot-add phase
   4.1 Hardware(Firmware) Support
-  4.2 Notify memory hot-add event by hand
+  4.2 Notify memory hot-addand hot-remove event by hand
+     4.2.1 Probe interface
+     4.2.2 Release interface
 5. Logical Memory hot-add phase
   5.1. State of memory
   5.2. How to online memory
@@ -69,7 +71,7 @@ management tables, and makes sysfs files
 
 If firmware supports notification of connection of new memory to OS,
 this phase is triggered automatically. ACPI can notify this event. If not,
-"probe" operation by system administration is used instead.
+"probe" and "release" operations by system administration is used instead.
 (see Section 4.).
 
 Logical Memory Hotplug phase is to change memory state into
@@ -208,20 +210,23 @@ calls hotplug code for all of objects wh
 If memory device is found, memory hotplug code will be called.
 
 
-4.2 Notify memory hot-add event by hand
+4.2 Notify memory hot-add and hot-remove event by hand
 ------------
 In some environments, especially virtualized environment, firmware will not
 notify memory hotplug event to the kernel. For such environment, "probe"
-interface is supported. This interface depends on CONFIG_ARCH_MEMORY_PROBE.
+and "release" interfaces are supported. This interface depends on
+CONFIG_ARCH_MEMORY_PROBE_RELEASE.
 
-Now, CONFIG_ARCH_MEMORY_PROBE is supported only by powerpc but it does not
-contain highly architecture codes. Please add config if you need "probe"
-interface.
+Now, CONFIG_ARCH_MEMORY_PROBE_RELEASE is supported only by powerpc but it does
+not contain highly architecture codes. Please add config if you need "probe"
+and "release" interfaces.
 
+4.2.1 "probe" interface
+------------
 Probe interface is located at
 /sys/devices/system/memory/probe
 
-You can tell the physical address of new memory to the kernel by
+You can tell the physical address of new memory to hot-add to the kernel by
 
 % echo start_address_of_new_memory > /sys/devices/system/memory/probe
 
@@ -230,6 +235,19 @@ memory range is hot-added. In this case,
 current implementation). You'll have to online memory by yourself.
 Please see "How to online memory" in this text.
 
+4.2.2 "release" interface
+------------
+Release interface is located at
+/sys/devices/system/memory/release
+
+You can tell the physical address of memory to hot-remove from the kernel by
+
+% echo start_address_of_memory > /sys/devices/system/memory/release
+
+Then, [start_address_of_memory, start_address_of_memory + section_size)
+memory range is hot-removed. You will need to ensure all of the memory in
+this range has been offlined prior to using this interface, please see
+"How to offline memory" in this text.
 
 
 ------------------------------

^ permalink raw reply

* [PATCH 3/8] Add all memory via sysfs probe interface at once
From: Nathan Fontenot @ 2013-07-24 18:37 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman, isimatu.yasuaki
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

When doing memory hot add via the 'probe' interface in sysfs we do not
need to loop through and add memory one section at a time. I think this
was originally done for powerpc, but is not needed. This patch removes
the loop and just calls add_memory for all of the memory to be added.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
 drivers/base/memory.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

Index: linux/drivers/base/memory.c
===================================================================
--- linux.orig/drivers/base/memory.c
+++ linux/drivers/base/memory.c
@@ -427,8 +427,8 @@ memory_probe_store(struct device *dev, s
 		   const char *buf, size_t count)
 {
 	u64 phys_addr;
-	int nid;
-	int i, ret;
+	int nid, ret;
+	unsigned long block_size;
 	unsigned long pages_per_block = PAGES_PER_SECTION * sections_per_block;
 
 	phys_addr = simple_strtoull(buf, NULL, 0);
@@ -436,19 +436,11 @@ memory_probe_store(struct device *dev, s
 	if (phys_addr & ((pages_per_block << PAGE_SHIFT) - 1))
 		return -EINVAL;
 
-	for (i = 0; i < sections_per_block; i++) {
-		nid = memory_add_physaddr_to_nid(phys_addr);
-		ret = add_memory(nid, phys_addr,
-				 PAGES_PER_SECTION << PAGE_SHIFT);
-		if (ret)
-			goto out;
+	block_size = get_memory_block_size();
+	nid = memory_add_physaddr_to_nid(phys_addr);
+	ret = add_memory(nid, phys_addr, block_size);
 
-		phys_addr += MIN_MEMORY_BLOCK_SIZE;
-	}
-
-	ret = count;
-out:
-	return ret;
+	return ret ? ret : count;
 }
 
 static DEVICE_ATTR(probe, S_IWUSR, NULL, memory_probe_store);

^ permalink raw reply

* [PATCH 2/8] Mark powerpc memory resources as busy
From: Nathan Fontenot @ 2013-07-24 18:36 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman, isimatu.yasuaki
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

Memory I/O resources need to be marked as busy or else we cannot remove
them when doing memory hot remove.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
 arch/powerpc/mm/mem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/arch/powerpc/mm/mem.c
===================================================================
--- linux.orig/arch/powerpc/mm/mem.c
+++ linux/arch/powerpc/mm/mem.c
@@ -523,7 +523,7 @@ static int add_system_ram_resources(void
 			res->name = "System RAM";
 			res->start = base;
 			res->end = base + size - 1;
-			res->flags = IORESOURCE_MEM;
+			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 			WARN_ON(request_resource(&iomem_resource, res) < 0);
 		}
 	}

^ permalink raw reply

* [PATCH 1/8] register bootmem pages for powerpc when sparse vmemmap is not defined
From: Nathan Fontenot @ 2013-07-24 18:35 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman, isimatu.yasuaki
In-Reply-To: <51F01E06.6090800@linux.vnet.ibm.com>

Previous commit 46723bfa540... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for powerpc
when sparse vmemmap is not defined.

This patch defines HAVE_BOOTMEM_INFO_NODE for powerpc and adds the call to
register_page_bootmem_info_node. Without this patch we get a BUG_ON for memory
hot remove in put_page_bootmem().

This also adds a stub for register_page_bootmem_memmap to allow powerpc to
build with sparse vmemmap defined.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---

---
 arch/powerpc/mm/init_64.c |    6 ++++++
 arch/powerpc/mm/mem.c     |    9 +++++++++
 mm/Kconfig                |    2 +-
 3 files changed, 16 insertions(+), 1 deletion(-)

Index: linux/arch/powerpc/mm/init_64.c
===================================================================
--- linux.orig/arch/powerpc/mm/init_64.c
+++ linux/arch/powerpc/mm/init_64.c
@@ -300,5 +300,11 @@ void vmemmap_free(unsigned long start, u
 {
 }
 
+void register_page_bootmem_memmap(unsigned long section_nr,
+				  struct page *start_page, unsigned long size)
+{
+	WARN_ONCE(1, KERN_INFO
+		  "Sparse Vmemmap not fully supported for bootmem info nodes\n");
+}
 #endif /* CONFIG_SPARSEMEM_VMEMMAP */
 
Index: linux/arch/powerpc/mm/mem.c
===================================================================
--- linux.orig/arch/powerpc/mm/mem.c
+++ linux/arch/powerpc/mm/mem.c
@@ -297,12 +297,21 @@ void __init paging_init(void)
 }
 #endif /* ! CONFIG_NEED_MULTIPLE_NODES */
 
+static void __init register_page_bootmem_info(void)
+{
+	int i;
+
+	for_each_online_node(i)
+		register_page_bootmem_info_node(NODE_DATA(i));
+}
+
 void __init mem_init(void)
 {
 #ifdef CONFIG_SWIOTLB
 	swiotlb_init(0);
 #endif
 
+	register_page_bootmem_info();
 	high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
 	set_max_mapnr(max_pfn);
 	free_all_bootmem();
Index: linux/mm/Kconfig
===================================================================
--- linux.orig/mm/Kconfig
+++ linux/mm/Kconfig
@@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
 config MEMORY_HOTREMOVE
 	bool "Allow for memory hot remove"
 	select MEMORY_ISOLATION
-	select HAVE_BOOTMEM_INFO_NODE if X86_64
+	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
 	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
 	depends on MIGRATION
 

^ permalink raw reply

* [PATCH 0/8] Correct memory hot add/remove for powerpc
From: Nathan Fontenot @ 2013-07-24 18:33 UTC (permalink / raw)
  To: LKML, linux-mm, linuxppc-dev; +Cc: Greg Kroah-Hartman, isimatu.yasuaki

The current implementation of memory hot add and remove for powerpc is broken.
This patch set both corrects this issue and updates the memory hot add and
remove code for powerpc so that it can be done properly in the kernel.

The first two patches update the powerpc hot add and remove code to work with
all of the updates that have gone in to enable memory remove with sparse
vmemmap enabled. With these two patches applied the powerpc code is back to
working, but not working properly.

The remaining patches update the powerpc memory add and remove code so the
work can be done in the kernel and all while holding the memory hotplug lock.
The current powerpc implementation does some of the work in the kernel and
some of the work in userspace. While this code did work at one time, it has
a problem in that it does part of the work to add and remove memory without
holding the memory hotplug lock. In this scheme memory could be added and
removed fast enough to cause the system to crash. This was a result of
doing part of the add or remove without holding the lock.

In order to do memory hot remove in the kernel, this patch set introduces
a sysfs release file (/sys/device/system/memory/release) which one
can write the physical address of the memory to be removed to. Additionally
there is a new set of flags defined for the memory notification chain to
indicate that memory is being hot added or hot removed. This allows any work
that may need to be done prior to or after memory is hot added or removed
to be performed.

The remaining patches in the patch set update the powerpc to properly do
memory hot add and remove in the kernel.

Nathan Fontenot
---
 Documentation/memory-hotplug.txt                      |   26 ++++
 arch/powerpc/mm/mem.c                                 |   35 +++++-
 arch/powerpc/platforms/pseries/hotplug-memory.c       |   95 +---------------
 drivers/base/memory.c                                 |   81 ++++++++++++--
 linux/Documentation/memory-hotplug.txt                |   34 ++++-
 linux/arch/powerpc/Kconfig                            |    2 
 linux/arch/powerpc/mm/init_64.c                       |    6 +
 linux/arch/powerpc/mm/mem.c                           |    9 +
 linux/arch/powerpc/platforms/pseries/dlpar.c          |  103 ++++++++++++++++++
 linux/arch/powerpc/platforms/pseries/hotplug-memory.c |   60 +---------
 linux/arch/x86/Kconfig                                |    2 
 linux/drivers/base/memory.c                           |   20 +--
 linux/include/linux/memory.h                          |    6 +
 linux/mm/Kconfig                                      |    2 
 linux/mm/memory_hotplug.c                             |   25 +++-
 15 files changed, 322 insertions(+), 184 deletions(-)

^ permalink raw reply

* Re: [PATCH 04/11] PCI/hotplug: Needn't remove EEH cache again
From: Bjorn Helgaas @ 2013-07-24 18:02 UTC (permalink / raw)
  To: Gavin Shan, linux-pci@vger.kernel.org; +Cc: linuxppc-dev
In-Reply-To: <1374632701-20972-5-git-send-email-shangw@linux.vnet.ibm.com>

[+cc linux-pci]

On Tue, Jul 23, 2013 at 8:24 PM, Gavin Shan <shangw@linux.vnet.ibm.com> wrote:
> Since pcibios_release_device() called by pci_stop_and_remove_bus_device()
> has removed the EEH cache, we needn't do that again.
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>

I'll be happy to merge this if you want, or since you have my Ack
already, you can merge it with the rest of the series.  I didn't get
the rest of the series, so I don't know if it depends on this.

Just let me know what you want me to do.

> ---
>  drivers/pci/hotplug/rpadlpar_core.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
> index b29e20b..bb7af78 100644
> --- a/drivers/pci/hotplug/rpadlpar_core.c
> +++ b/drivers/pci/hotplug/rpadlpar_core.c
> @@ -388,7 +388,6 @@ int dlpar_remove_pci_slot(char *drc_name, struct device_node *dn)
>         /* Remove the EADS bridge device itself */
>         BUG_ON(!bus->self);
>         pr_debug("PCI: Now removing bridge device %s\n", pci_name(bus->self));
> -       eeh_remove_bus_device(bus->self, true);
>         pci_stop_and_remove_bus_device(bus->self);
>
>         return 0;
> --
> 1.7.5.4
>

^ permalink raw reply

* Re: [PATCH] Update compilation flags with core specific options
From: Scott Wood @ 2013-07-24 17:45 UTC (permalink / raw)
  To: Udma Catalin-Dan-B32721; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <FE751157F0442848A159F3AB4CB1F55B3F83F1@039-SN1MPN1-001.039d.mgd.msft.net>

On 07/24/2013 11:25:52 AM, Udma Catalin-Dan-B32721 wrote:
> > This breaks the vdso for e500v1/v2 (userspace dies with SIGILL), =20
> since
> > KBUILD_CFLAGS doesn't get used when building asm files, and the vdso
> > uses mftbu/mftbl which are not being assembled to the form that
> > e500v1/v2 support.
> >
> > We should be setting -mcpu=3Dwhatever and -msoft-float in both CFLAGS =20
> and
> > AFLAGS, since we don't call "as" directly, and target selection =20
> should
> > not differ based on whether we're building a C file or an asm file.
> >
> > -Scott
> [CU] Thank you, Scott. I'll update also AFLAGS.
>=20
> I have some questions about how you reproduce the SIGILL issue.
> I tried to reproduce the issue looking to gettimeofday.S, that uses
> mftbu/mftbl. In my tests, I obtained the same output when compiling =20
> this file
> for p1021rdb before and after this patch, and also after adding -mcpu =20
> to
> AFLAGS: "objdump -d arch/powerpc/kernel/vdso32/gettimeofday.o" looks =20
> the same
> for the cases mentioned above:
>    "mftbu r3" from .S file is decoded to "mfspr   r3,269" in "objdump =20
> -d" output
>=20
> Indeed, for -mcpu=3D601/power3, the "objdump -d" output is "mftbu r3" =20
> and according to
> powerISA this instruction would cause Illegal Instruction error =20
> handler to be invoked
> and permits the sw to emulate the instruction.

It probably depends on what the default is for your toolchain.

-Scott=

^ permalink raw reply

* RE: [PATCH] Update compilation flags with core specific options
From: Udma Catalin-Dan-B32721 @ 2013-07-24 16:25 UTC (permalink / raw)
  To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374624677.15592.48@snotra>

> This breaks the vdso for e500v1/v2 (userspace dies with SIGILL), since
> KBUILD_CFLAGS doesn't get used when building asm files, and the vdso
> uses mftbu/mftbl which are not being assembled to the form that
> e500v1/v2 support.
>=20
> We should be setting -mcpu=3Dwhatever and -msoft-float in both CFLAGS and
> AFLAGS, since we don't call "as" directly, and target selection should
> not differ based on whether we're building a C file or an asm file.
>=20
> -Scott
[CU] Thank you, Scott. I'll update also AFLAGS.

I have some questions about how you reproduce the SIGILL issue.
I tried to reproduce the issue looking to gettimeofday.S, that uses
mftbu/mftbl. In my tests, I obtained the same output when compiling this fi=
le
for p1021rdb before and after this patch, and also after adding -mcpu to
AFLAGS: "objdump -d arch/powerpc/kernel/vdso32/gettimeofday.o" looks the sa=
me
for the cases mentioned above:
   "mftbu r3" from .S file is decoded to "mfspr   r3,269" in "objdump -d" o=
utput

Indeed, for -mcpu=3D601/power3, the "objdump -d" output is "mftbu r3" and a=
ccording to
powerISA this instruction would cause Illegal Instruction error handler to =
be invoked
and permits the sw to emulate the instruction.

Regards,
Catalin

^ permalink raw reply

* Re: Inbound PCI and Memory Corruption
From: Peter LaDow @ 2013-07-24 15:39 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1374640044.3916.109.camel@pasglop>

On Tue, Jul 23, 2013 at 9:27 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> CONFIG_NOT_COHERENT_CACHE will do it for you (in
> arch/powerpc/kernel/dma.c) provided the driver does the right things vs.
> the DMA accessors but afaik e1000 does.

Well, when I went to make the changes I noted a few things.  First,
the e1000 driver does a dma_unmap_single() prior to processing the
descriptor.  So it would seem that the dma_sync_single_for_cpu() isn't
necessary in that case.  And when allocating descriptors, it does
dma_map_single() after setting up the descriptor, so
dma_sync_single_for_device() probably isn't necessary either.

But regardless, I put in the dma_sync_single_* calls and we still get
the same behavior.  So, even with CONFIG_NOT_COHERENT_CACHE we are
getting this error.

> If that helps, that might hint at either a missing barrier or some kind
> of HW (or HW configuration) bug with cache coherency.

And unfortunately it didn't help.  We have a few other things we are
trying, but I'm not hopeful that any will change the behavior.

A bit of history that may help.  We were using an e100 (an 82559)
part, but Intel EOL'd that part so we picked up the 82540EP (which
they have also recently EOL'd).  The e100 driver uses a different DMA
model.  It uses pci_map_single/pci_unmap_single along with
pci_dma_sync_single_for* calls (as well as other PCI calls).  The
e1000 driver, however, does not use the pci_* calls.  We have never
had a problem with the e100 parts.  I don't suppose the use of
pci_map_* vs dma_map_* makes a difference does it?

Thanks,
Pete

^ permalink raw reply

* Re: [PATCH v2] powerpc: VPHN topology change updates all siblings
From: Greg KH @ 2013-07-24 15:28 UTC (permalink / raw)
  To: Robert Jennings, linuxppc-dev, Benjamin Herrenschmidt,
	Paul Mackerras, Nathan Fontenot, Michael Ellerman, Jan Stancek,
	stable
In-Reply-To: <20130724150005.GB13737@linux.vnet.ibm.com>

On Wed, Jul 24, 2013 at 10:00:05AM -0500, Robert Jennings wrote:
> When an associativity level change is found for one thread, the
> siblings threads need to be updated as well.  This is done today
> for PRRN in stage_topology_update() but is missing for VPHN in
> update_cpu_associativity_changes_mask().
> 
> All threads should be updated to move to the new node.  Without this
> patch, a single thread may be flagged for a topology change, leaving it
> in a different node from its siblings, which is incorrect.  This causes
> problems for the scheduler where overlapping scheduler groups are created
> and a loop is formed in those groups.
> 
> Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
> ---
> cpu_sibling_mask is now defined for UP which fixes that build break.
> ---
>  arch/powerpc/include/asm/smp.h |  4 +++
>  arch/powerpc/mm/numa.c         | 59 +++++++++++++++++++++++++++++++-----------
>  2 files changed, 48 insertions(+), 15 deletions(-)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>

^ permalink raw reply

* [PATCH v2] powerpc: VPHN topology change updates all siblings
From: Robert Jennings @ 2013-07-24 15:00 UTC (permalink / raw)
  To: linuxppc-dev, Benjamin Herrenschmidt, Paul Mackerras,
	Nathan Fontenot, Robert Jennings, Michael Ellerman, Jan Stancek,
	stable

When an associativity level change is found for one thread, the
siblings threads need to be updated as well.  This is done today
for PRRN in stage_topology_update() but is missing for VPHN in
update_cpu_associativity_changes_mask().

All threads should be updated to move to the new node.  Without this
patch, a single thread may be flagged for a topology change, leaving it
in a different node from its siblings, which is incorrect.  This causes
problems for the scheduler where overlapping scheduler groups are created
and a loop is formed in those groups.

Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
cpu_sibling_mask is now defined for UP which fixes that build break.
---
 arch/powerpc/include/asm/smp.h |  4 +++
 arch/powerpc/mm/numa.c         | 59 +++++++++++++++++++++++++++++++-----------
 2 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index ffbaabe..48cfc85 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -145,6 +145,10 @@ extern void __cpu_die(unsigned int cpu);
 #define smp_setup_cpu_maps()
 static inline void inhibit_secondary_onlining(void) {}
 static inline void uninhibit_secondary_onlining(void) {}
+static inline const struct cpumask *cpu_sibling_mask(int cpu)
+{
+	return cpumask_of(cpu);
+}
 
 #endif /* CONFIG_SMP */
 
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 0839721..5850798 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -27,6 +27,7 @@
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
 #include <linux/slab.h>
+#include <asm/cputhreads.h>
 #include <asm/sparsemem.h>
 #include <asm/prom.h>
 #include <asm/smp.h>
@@ -1318,7 +1319,8 @@ static int update_cpu_associativity_changes_mask(void)
 			}
 		}
 		if (changed) {
-			cpumask_set_cpu(cpu, changes);
+			cpumask_or(changes, changes, cpu_sibling_mask(cpu));
+			cpu = cpu_last_thread_sibling(cpu);
 		}
 	}
 
@@ -1426,7 +1428,7 @@ static int update_cpu_topology(void *data)
 	if (!data)
 		return -EINVAL;
 
-	cpu = get_cpu();
+	cpu = smp_processor_id();
 
 	for (update = data; update; update = update->next) {
 		if (cpu != update->cpu)
@@ -1446,12 +1448,12 @@ static int update_cpu_topology(void *data)
  */
 int arch_update_cpu_topology(void)
 {
-	unsigned int cpu, changed = 0;
+	unsigned int cpu, sibling, changed = 0;
 	struct topology_update_data *updates, *ud;
 	unsigned int associativity[VPHN_ASSOC_BUFSIZE] = {0};
 	cpumask_t updated_cpus;
 	struct device *dev;
-	int weight, i = 0;
+	int weight, new_nid, i = 0;
 
 	weight = cpumask_weight(&cpu_associativity_changes_mask);
 	if (!weight)
@@ -1464,19 +1466,46 @@ int arch_update_cpu_topology(void)
 	cpumask_clear(&updated_cpus);
 
 	for_each_cpu(cpu, &cpu_associativity_changes_mask) {
-		ud = &updates[i++];
-		ud->cpu = cpu;
-		vphn_get_associativity(cpu, associativity);
-		ud->new_nid = associativity_to_nid(associativity);
-
-		if (ud->new_nid < 0 || !node_online(ud->new_nid))
-			ud->new_nid = first_online_node;
+		/*
+		 * If siblings aren't flagged for changes, updates list
+		 * will be too short. Skip on this update and set for next
+		 * update.
+		 */
+		if (!cpumask_subset(cpu_sibling_mask(cpu),
+					&cpu_associativity_changes_mask)) {
+			pr_info("Sibling bits not set for associativity "
+					"change, cpu%d\n", cpu);
+			cpumask_or(&cpu_associativity_changes_mask,
+					&cpu_associativity_changes_mask,
+					cpu_sibling_mask(cpu));
+			cpu = cpu_last_thread_sibling(cpu);
+			continue;
+		}
 
-		ud->old_nid = numa_cpu_lookup_table[cpu];
-		cpumask_set_cpu(cpu, &updated_cpus);
+		/* Use associativity from first thread for all siblings */
+		vphn_get_associativity(cpu, associativity);
+		new_nid = associativity_to_nid(associativity);
+		if (new_nid < 0 || !node_online(new_nid))
+			new_nid = first_online_node;
+
+		if (new_nid == numa_cpu_lookup_table[cpu]) {
+			cpumask_andnot(&cpu_associativity_changes_mask,
+					&cpu_associativity_changes_mask,
+					cpu_sibling_mask(cpu));
+			cpu = cpu_last_thread_sibling(cpu);
+			continue;
+		}
 
-		if (i < weight)
-			ud->next = &updates[i];
+		for_each_cpu(sibling, cpu_sibling_mask(cpu)) {
+			ud = &updates[i++];
+			ud->cpu = sibling;
+			ud->new_nid = new_nid;
+			ud->old_nid = numa_cpu_lookup_table[sibling];
+			cpumask_set_cpu(sibling, &updated_cpus);
+			if (i < weight)
+				ud->next = &updates[i];
+		}
+		cpu = cpu_last_thread_sibling(cpu);
 	}
 
 	stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
-- 
1.8.1.2

^ permalink raw reply related

* Re: [PATCH] powerpc: VPHN topology change updates all siblings
From: Robert Jennings @ 2013-07-24 14:59 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: stable, Paul Mackerras, Nathan Fontenot, linuxppc-dev,
	Jan Stancek
In-Reply-To: <1374641175.3916.111.camel@pasglop>

* Benjamin Herrenschmidt (benh@kernel.crashing.org) wrote:
> On Tue, 2013-07-23 at 07:33 -0500, Robert Jennings wrote:
> > When an associativity level change is found for one thread, the
> > siblings threads need to be updated as well.  This is done today
> > for PRRN in stage_topology_update() but is missing for VPHN in
> > update_cpu_associativity_changes_mask().
> > 
> > All threads should be updated to move to the new node.  Without this
> > patch, a single thread may be flagged for a topology change, leaving it
> > in a different node from its siblings, which is incorrect.  This causes
> > problems for the scheduler where overlapping scheduler groups are created
> > and a loop is formed in those groups.
> > 
> > Reported-by: Jan Stancek <jstancek@redhat.com>
> > Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
> > Cc: <stable@vger.kernel.org>
> 
> Patch breaks the UP build ...
> 
> Cheers,
> Ben.

Very sorry about that, a fix is on the way.

^ permalink raw reply

* Re: [PATCH 2/3] cpufreq: pmac64: re-estimate G5 cpufreq transition latency
From: Viresh Kumar @ 2013-07-24 10:45 UTC (permalink / raw)
  To: Aaro Koskinen; +Cc: Rafael J. Wysocki, linux-pm, linuxppc-dev, Nick Piggin
In-Reply-To: <20130724101832.GA26943@blackmetal.musicnaut.iki.fi>

On 24 July 2013 15:48, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> Hi,
>
> On Wed, Jul 24, 2013 at 11:04:50AM +0530, Viresh Kumar wrote:
>> On 24 July 2013 01:54, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>> > The patch also enables to use ondemand governor on the latter.
>>
>> How? I can't see anything obvious here. :(
>
> It replaces CPUFREQ_ETERNAL with a proper value on older PowerMacs.
> ondemand does not accept CPUFREQ_ETERNAL transition latency.

Ahh.. In case you are sending it again, just add this info in log as people
might miss it.

^ permalink raw reply

* RE: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not remove
From: Li Yang-R58472 @ 2013-07-24 10:33 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: daniel.lezcano@linaro.org, linuxppc-dev@lists.ozlabs.org,
	Wang Dongsheng-B40534, linux-pm@vger.kernel.org
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259FDCB28@039-SN2MPN1-023.039d.mgd.msft.net>

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgtcG0tb3duZXJA
dmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtcG0tDQo+IG93bmVyQHZnZXIua2VybmVsLm9y
Z10gT24gQmVoYWxmIE9mIFdhbmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiBTZW50OiBXZWRuZXNkYXks
IEp1bHkgMjQsIDIwMTMgMTA6MjYgQU0NCj4gVG86IFJhZmFlbCBKLiBXeXNvY2tpDQo+IENjOiBk
YW5pZWwubGV6Y2Fub0BsaW5hcm8ub3JnOyBsaW51eC1wbUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSRTogW1BBVENIIDEvMl0g
Y3B1aWRsZTogZml4IGNwdSBpZGxlIGRyaXZlciBhcyBhIG1vZHVsZSBjYW4gbm90DQo+IHJlbW92
ZQ0KPiANCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog
UmFmYWVsIEouIFd5c29ja2kgW21haWx0bzpyandAc2lzay5wbF0NCj4gPiBTZW50OiBXZWRuZXNk
YXksIEp1bHkgMjQsIDIwMTMgNTozMyBBTQ0KPiA+IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQN
Cj4gPiBDYzogZGFuaWVsLmxlemNhbm9AbGluYXJvLm9yZzsgbGludXgtcG1Admdlci5rZXJuZWwu
b3JnOyBsaW51eHBwYy0NCj4gPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+IFN1YmplY3Q6IFJl
OiBbUEFUQ0ggMS8yXSBjcHVpZGxlOiBmaXggY3B1IGlkbGUgZHJpdmVyIGFzIGEgbW9kdWxlIGNh
bg0KPiA+IG5vdCByZW1vdmUNCj4gPg0KPiA+IE9uIFR1ZXNkYXksIEp1bHkgMjMsIDIwMTMgMDU6
Mjg6MDAgUE0gRG9uZ3NoZW5nIFdhbmcgd3JvdGU6DQo+ID4gPiBGcm9tOiBXYW5nIERvbmdzaGVu
ZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiA+DQo+ID4gPiBUaGUgbW9kdWxl
IGNhbiBub3QgYmUgcmVtb3ZlZCB3aGVuIGV4ZWN1dGUgInJtbW9kIi4gcm1tb2Qgbm90IHVzZQ0K
PiA+ID4gIi0tZm9yY2UiLg0KPiA+ID4NCj4gPiA+IExvZzoNCj4gPiA+IHJvb3Q6fiMgcm1tb2Qg
Y3B1aWRsZS1lNTAwDQo+ID4gPiBpbmNzWzldLCBkZWNzWzFdDQo+ID4gPiBybW1vZDogY2FuJ3Qg
dW5sb2FkICdjcHVpZGxlX2U1MDAnOiBSZXNvdXJjZSB0ZW1wb3JhcmlseSB1bmF2YWlsYWJsZQ0K
PiA+ID4NCj4gPiA+IFNpZ25lZC1vZmYtYnk6IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2Fu
Z0BmcmVlc2NhbGUuY29tPg0KPiA+DQo+ID4gQ2FuIHlvdSBwbGVhc2UgY2hlY2sgdGhlIGN1cnJl
bnQgbGludXgtbmV4dCBicmFuY2ggb2YgdGhlIGxpbnV4LXBtLmdpdA0KPiA+IHRyZWUgYW5kIHNl
ZSBpZiB0aGF0IGRvZXNuJ3QgY29uZmxpY3Qgd2l0aCB0aGUgbWF0ZXJpYWwgaW4gdGhlcmU/DQo+
ID4NCj4gPiBBbHNvIHBsZWFzZSBleHBsYWluIGluIHRoZSBjaGFuZ2Vsb2cgaG93IHlvdXIgY2hh
bmdlcyBoZWxwIHRvIGZpeCB0aGUNCj4gPiBwcm9ibGVtLg0KPiA+DQo+IFllcywgTGludXgtbmV4
dCBicmFuY2ggYWxzbyBoYXZlIHRoaXMgcHJvYmxlbS4NCj4gDQo+IFNob3VsZCBJIGJhc2Ugb24g
TGludXgtbmV4dCB0byBmaXggdGhpcyBwcm9ibGVtPw0KDQpJIHRoaW5rIERvbmdzaGVuZyBpcyB0
cnlpbmcgdG8gbWFrZSB0aGUgcGxhdGZvcm0gY3B1aWRsZSBkcml2ZXIgYXMgYSBrZXJuZWwgbW9k
dWxlLg0KDQpNeSBxdWVzdGlvbnMgYXJlOg0KSXMgdGhlIGNwdWlkbGUgZHJpdmVyIHN1cHBvc2Vk
IHRvIHdvcmsgYXMgYSBtb2R1bGU/DQpPciBpdCBjYW4gb25seSBiZSBidWlsdC1pbiBsaWtlIG1h
bnkgY3VycmVudCBkcml2ZXJzIGRvPw0KDQpSZWdhcmRzLA0KTGVvDQo=

^ permalink raw reply

* Re: [PATCH 2/3] cpufreq: pmac64: re-estimate G5 cpufreq transition latency
From: Aaro Koskinen @ 2013-07-24 10:18 UTC (permalink / raw)
  To: Viresh Kumar; +Cc: Rafael J. Wysocki, linux-pm, linuxppc-dev, Nick Piggin
In-Reply-To: <CAKohpo=t0C63m_WuZA-dGiLDtBu8FbdM8tgJLNh_NSAALnf+fw@mail.gmail.com>

Hi,

On Wed, Jul 24, 2013 at 11:04:50AM +0530, Viresh Kumar wrote:
> On 24 July 2013 01:54, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > The patch also enables to use ondemand governor on the latter.
> 
> How? I can't see anything obvious here. :(

It replaces CPUFREQ_ETERNAL with a proper value on older PowerMacs.
ondemand does not accept CPUFREQ_ETERNAL transition latency.

A.

> 
> >
> > Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> > ---
> >  drivers/cpufreq/pmac64-cpufreq.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/cpufreq/pmac64-cpufreq.c b/drivers/cpufreq/pmac64-cpufreq.c
> > index 674807d..f9e399b 100644
> > --- a/drivers/cpufreq/pmac64-cpufreq.c
> > +++ b/drivers/cpufreq/pmac64-cpufreq.c
> > @@ -85,7 +85,8 @@ static int (*g5_query_freq)(void);
> >
> >  static DEFINE_MUTEX(g5_switch_mutex);
> >
> > -static unsigned long transition_latency;
> > +/* A conservative estimate, based on Xserve G5 and iMac G5 (iSight). */
> > +static const unsigned long transition_latency = 10 * NSEC_PER_MSEC;
> >
> >  #ifdef CONFIG_PMAC_SMU
> >
> > @@ -499,7 +500,6 @@ static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
> >         g5_cpu_freqs[1].frequency = max_freq/2;
> >
> >         /* Set callbacks */
> > -       transition_latency = 12000;
> >         g5_switch_freq = g5_scom_switch_freq;
> >         g5_query_freq = g5_scom_query_freq;
> >         freq_method = "SCOM";
> > @@ -675,7 +675,6 @@ static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
> >         g5_cpu_freqs[1].frequency = min_freq;
> >
> >         /* Set callbacks */
> > -       transition_latency = CPUFREQ_ETERNAL;
> >         g5_switch_volt = g5_pfunc_switch_volt;
> >         g5_switch_freq = g5_pfunc_switch_freq;
> >         g5_query_freq = g5_pfunc_query_freq;
> > --
> > 1.8.3.2
> >

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox