Hi.
These 2 patches are to catch notification of new node's hot-add event via ACPI.
They were members of v4 of new node hot-add patches.
However, I would like to merge them at first before other patch.
Because, if these 2 patches are merged into mainline, all new node's memory
can be added to node 0. If not, no memory is added even if other patches are
merged. In addition, there is no opposition to these patches.
To tell the truth, I've posted similer patches a few times to ACPI-ML.
But, unfortunately, there was no response.
So, could you apply these patches to -mm tree?
This patch is for 2.6.16-mm1.
I tested on my ia64 Tiger4 box with my node emulation.
In addition, our firmware team provided us new firmware which can allow hot-add.
These patches worked well on it. :-)
Bye.
------------------------------------------
These 2 patches are to catch notification of new node's hot-add event
via ACPI.
If a new node is added, notification of ACPI reaches container device
which means node, and container driver scans belonging devices.
To call memory device's driver, start function of acpi memory device is
necessary. First patch is to register its function.
In addition, the scanning of memory devices and call add_memory() works
even if memory is registered at boottime.
Second patch is to avoid redundant call of add_memory().
--
Yasunori Goto
This is a patch to call add_memroy() when notify reaches for
new node's add event.
When new node is added, notify of ACPI reaches container device
which means the node.
Container device driver calls acpi_bus_scan() to find and add
belonging devices (which means cpu, memory and so on).
Its function calls add and start function of belonging
devices's driver.
Howevever, current memory hotplug driver just register add function to
create sysfs file for its memory. But, acpi_memory_enable_device()
is not called because it is considered just the case that notify reaches
memory device directly. So, if notify reaches container device
nothing can call add_memory().
This is a patch to create start function which calls add_memory().
add_memory() can be called by this when notify reaches container device.
Signed-off-by: Yasunori Goto <[email protected]>
drivers/acpi/acpi_memhotplug.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+)
Index: pgdat9/drivers/acpi/acpi_memhotplug.c
===================================================================
--- pgdat9.orig/drivers/acpi/acpi_memhotplug.c 2006-03-23 19:58:48.000000000 +0900
+++ pgdat9/drivers/acpi/acpi_memhotplug.c 2006-03-23 20:20:17.000000000 +0900
@@ -57,6 +57,7 @@ MODULE_LICENSE("GPL");
static int acpi_memory_device_add(struct acpi_device *device);
static int acpi_memory_device_remove(struct acpi_device *device, int type);
+static int acpi_memory_device_start (struct acpi_device *device);
static struct acpi_driver acpi_memory_device_driver = {
.name = ACPI_MEMORY_DEVICE_DRIVER_NAME,
@@ -65,6 +66,7 @@ static struct acpi_driver acpi_memory_de
.ops = {
.add = acpi_memory_device_add,
.remove = acpi_memory_device_remove,
+ .start = acpi_memory_device_start,
},
};
@@ -429,6 +431,26 @@ static int acpi_memory_device_remove(str
return_VALUE(0);
}
+static int
+acpi_memory_device_start (struct acpi_device *device)
+{
+ struct acpi_memory_device *mem_device;
+ int result = 0;
+
+ ACPI_FUNCTION_TRACE("acpi_memory_device_start");
+
+ mem_device = (struct acpi_memory_device *) acpi_driver_data(device);
+
+ if (!acpi_memory_check_device(mem_device)){
+ /* call add_memory func */
+ result = acpi_memory_enable_device(mem_device);
+ if (result)
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+ "Error in acpi_memory_enable_device\n"));
+ }
+ return_VALUE(result);
+}
+
/*
* Helper function to check for memory device
*/
--
Yasunori Goto
When acpi_memory_device_init() is called at boottime to
register struct memory acpi_memory_device,
acpi_bus_add() are called via acpi_driver_attach().
But it also calls ops->start() function.
It is called even if the memory blocks are initialized at
early boottime. In this case add_memory() return -EEXIST, and
the memory blocks becomes INVALID state even if it is normal.
This is patch to avoid calling add_memory() for already available memory.
Signed-off-by: Yasunori Goto <[email protected]>
drivers/acpi/acpi_memhotplug.c | 11 +++++++++++
1 files changed, 11 insertions(+)
Index: pgdat9/drivers/acpi/acpi_memhotplug.c
===================================================================
--- pgdat9.orig/drivers/acpi/acpi_memhotplug.c 2006-03-23 19:59:01.000000000 +0900
+++ pgdat9/drivers/acpi/acpi_memhotplug.c 2006-03-23 20:20:04.000000000 +0900
@@ -234,6 +234,17 @@ static int acpi_memory_enable_device(str
* (i.e. memory-hot-remove function)
*/
list_for_each_entry(info, &mem_device->res_list, list) {
+ u64 start_pfn, end_pfn;
+
+ start_pfn= info->start_addr >> PAGE_SHIFT;
+ end_pfn = (info->start_addr + info->length - 1) >> PAGE_SHIFT;
+
+ if (pfn_valid(start_pfn) || pfn_valid(end_pfn)){
+ /* already enabled. try next area */
+ num_enabled++;
+ continue;
+ }
+
result = add_memory(info->start_addr, info->length);
if (result)
continue;
--
Yasunori Goto
On Thu, 23 Mar 2006 22:41:05 +0900
Yasunori Goto <[email protected]> wrote:
>These 2 patches are to catch notification of new node's hot-add event via ACPI.
One more thing, this patch works for the case that memory device "PNP0C80" appears
in container device"ACPI0004,PNP0A05,PNP0A06". In this case, ACPI's notify just comes
to container device (not to memory device in it). This patch is necessary to deal with it.
I heared that some of firmwares (will?) use this kind of design, memory in a container,
even if it's not NUMA.
-- Kame.