* [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object
[not found] ` <20040910230200.73eb0374.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
@ 2004-09-16 10:47 ` Keiichiro Tokunaga
[not found] ` <20040916194725.562b50f0.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Keiichiro Tokunaga @ 2004-09-16 10:47 UTC (permalink / raw)
To: naveen.b.s-ral2JQCrhuEAvxtiuMwx3w, Dave Hansen
Cc: tokunaga.keiich-+CUm20s59erQFUHtdCDX3A,
matthew.e.tolentino-ral2JQCrhuEAvxtiuMwx3w,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
lhms-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Fri, 10 Sep 2004 23:02:00 +0900 Keiichiro Tokunaga wrote:
> On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> > Attached is an ACPI based hot plug driver patch to support physical
> > memory hotplug. This driver supports physical hotplug operation on
> > memory, fields notifications from firmware and notifies the VM of the
> > affected memory ranges. The following patch is against kernel
> > 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> > posted at: http://sprucegoose.sr71.net/patches. This patch has been
> > tested on real prototype hardware in the hot-add memory case. Hot
> > remove feature is tested in an emulated environment (by overriding
> > ACPI DSDT).
> >
> > Please review and consider for inclusion.
>
> I would like to add a feature into drivers/acpi/memory.c.
>
> Please see the patch below. This patch is for the kernel applying
> your patch.
I have changed the patch to create directories and files in
/sys/firmware/acpi/memory/ from Dave's comments. The files are
to export the following stuffs of each ACPI memory object for the
first version.
# ls /sys/firmware/acpi/memory/MEM1/
address_length
address_translation_offset
granularity
max_address_fixed
max_address_range
min_address_fixed
min_address_range
producer_consumer
resource_type
# cat /sys/firmware/acpi/memory/MEM1/min_address_range
0xc0000000
Naveen, if it looks okay, please include it to your patch. If you are
still working on 2.6.8.1-mm3, it applies. If you are not, please let
me know.
Thanks,
Keiichiro Tokunaga
Signed-off-by: Keiichiro Tokunaga <tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
---
drivers/acpi/memory.c | 363 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 358 insertions(+), 5 deletions(-)
diff -puN drivers/acpi/memory.c~sysfs_memory drivers/acpi/memory.c
--- linux-2.6.8.1-mm3/drivers/acpi/memory.c~sysfs_memory 2004-09-16 10:19:00.000000000 +0900
+++ linux-2.6.8.1-mm3-kei/drivers/acpi/memory.c 2004-09-16 19:06:38.000000000 +0900
@@ -69,6 +69,15 @@ static struct acpi_driver acpi_memory_de
},
};
+struct acpi_mem {
+ struct acpi_mem_device_ops *ops;
+ void (*release)(struct acpi_mem *mdev);
+ struct kobject kobj;
+};
+
+#define to_acpi_mem(n) container_of(n, struct acpi_mem, kobj)
+#define acpi_mem_to_dev(n) container_of(n, struct acpi_memory_device, amem)
+
struct acpi_memory_device {
acpi_handle handle;
unsigned int state; /* State of the memory device */
@@ -76,8 +85,335 @@ struct acpi_memory_device {
unsigned short read_write_attribute;/* memory read/write attribute */
u64 start_addr; /* Memory Range start physical addr */
u64 end_addr; /* Memory Range end physical addr */
+ struct acpi_resource resource;
+ struct acpi_mem amem;
+};
+
+/*
+ * /sys/firmware/acpi/memory/
+ */
+struct acpi_mem_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct acpi_mem *, char *);
+ ssize_t (*store)(struct acpi_mem *, const char *, size_t);
};
+#define to_acpi_mem_attr(n) container_of(n, struct acpi_mem_attribute, attr)
+
+static ssize_t acpi_mem_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct acpi_mem *amem = to_acpi_mem(kobj);
+ struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+ return attribute->show ? attribute->show(amem, buf) : 0;
+}
+
+static ssize_t acpi_mem_attr_store(struct kobject *kobj,
+ struct attribute *attr, const char *buf,
+ size_t len)
+{
+ struct acpi_mem *amem = to_acpi_mem(kobj);
+ struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+ return attribute->store ? attribute->store(amem, buf, len) : 0;
+}
+
+static struct sysfs_ops acpi_mem_sysfs_ops = {
+ .show = acpi_mem_attr_show,
+ .store = acpi_mem_attr_store,
+};
+
+static void acpi_mem_release(struct kobject *kobj)
+{
+ sysfs_remove_dir(kobj);
+ if (kobj->kset) {
+ down_write(&kobj->kset->subsys->rwsem);
+ list_del_init(&kobj->entry);
+ up_write(&kobj->kset->subsys->rwsem);
+ }
+}
+
+static struct kobj_type acpi_mem_ktype = {
+ .sysfs_ops = &acpi_mem_sysfs_ops,
+ .release = &acpi_mem_release,
+};
+
+static decl_subsys_name(acpi_mem, memory, &acpi_mem_ktype, NULL);
+
+static int acpi_mem_register(struct acpi_mem *amem)
+{
+ return kobject_register(&amem->kobj);
+}
+
+int create_acpi_mem(struct acpi_memory_device *mem_device,
+ struct acpi_device *device)
+{
+ int result;
+ struct acpi_mem *amem = &mem_device->amem;
+
+ ACPI_FUNCTION_TRACE("create_acpi_mem");
+
+ memset(amem, 0, sizeof(struct acpi_mem));
+ kobject_set_name(&amem->kobj, device->pnp.bus_id);
+ kobj_set_kset_s(amem, acpi_mem_subsys);
+ amem->kobj.parent = &acpi_mem_subsys.kset.kobj;
+
+ result = acpi_mem_register(amem);
+ if (result)
+ goto end;
+end:
+ return_VALUE(result);
+}
+
+int acpi_mem_fs_init(void)
+{
+ int result;
+ extern struct subsystem acpi_subsys;
+
+ ACPI_FUNCTION_TRACE("acpi_mem_fs_init");
+
+ acpi_mem_subsys.kset.kobj.parent = &acpi_subsys.kset.kobj;
+ result = subsystem_register(&acpi_mem_subsys);
+
+ return_VALUE(result);
+}
+
+void acpi_mem_fs_exit(void)
+{
+ ACPI_FUNCTION_TRACE("acpi_mem_fs_exit");
+
+ subsystem_unregister(&acpi_mem_subsys);
+
+ return_VOID;
+}
+
+static int get_address64(struct acpi_mem *amem,
+ struct acpi_resource_address64 *address64)
+{
+ struct acpi_memory_device *mem_device = acpi_mem_to_dev(amem);
+ struct acpi_resource *resource;
+
+ if (!mem_device)
+ return -ENODEV;
+
+ resource = &mem_device->resource;
+
+ acpi_resource_to_address64(resource, address64);
+
+ if (address64->resource_type != ACPI_MEMORY_RANGE)
+ return -EINVAL;
+
+ return 0;
+}
+
+static ssize_t resource_type_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%x\n", address64.resource_type);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_resource_type = {
+ .attr = {.name = "resource_type", .mode = S_IFREG | S_IRUGO},
+ .show = resource_type_read_file,
+};
+
+static ssize_t producer_consumer_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%x\n", address64.producer_consumer);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_producer_consumer = {
+ .attr = {.name = "producer_consumer", .mode = S_IFREG | S_IRUGO},
+ .show = producer_consumer_read_file,
+};
+
+static ssize_t decode_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%x\n", address64.decode);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_decode = {
+ .attr = {.name = "decode", .mode = S_IFREG | S_IRUGO},
+ .show = decode_read_file,
+};
+
+static ssize_t min_address_fixed_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%x\n", address64.min_address_fixed);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_min_address_fixed = {
+ .attr = {.name = "min_address_fixed", .mode = S_IFREG | S_IRUGO},
+ .show = min_address_fixed_read_file,
+};
+
+static ssize_t max_address_fixed_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%x\n", address64.max_address_fixed);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_max_address_fixed = {
+ .attr = {.name = "max_address_fixed", .mode = S_IFREG | S_IRUGO},
+ .show = max_address_fixed_read_file,
+};
+
+static ssize_t granularity_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%llx\n", address64.granularity);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_granularity = {
+ .attr = {.name = "granularity", .mode = S_IFREG | S_IRUGO},
+ .show = granularity_read_file,
+};
+
+static ssize_t min_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%llx\n", address64.min_address_range);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_min_address_range = {
+ .attr = {.name = "min_address_range", .mode = S_IFREG | S_IRUGO},
+ .show = min_address_range_read_file,
+};
+
+static ssize_t max_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%llx\n", address64.max_address_range);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_max_address_range = {
+ .attr = {.name = "max_address_range", .mode = S_IFREG | S_IRUGO},
+ .show = max_address_range_read_file,
+};
+
+static ssize_t address_translation_offset_read_file(struct acpi_mem *amem,
+ char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%llx\n",
+ address64.address_translation_offset);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_address_translation_offset = {
+ .attr = {.name = "address_translation_offset",
+ .mode = S_IFREG | S_IRUGO},
+ .show = address_translation_offset_read_file,
+};
+
+static ssize_t address_length_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%llx\n", address64.address_length);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_address_length = {
+ .attr = {.name = "address_length", .mode = S_IFREG | S_IRUGO},
+ .show = address_length_read_file,
+};
+
+static int fs_add_memory(struct acpi_mem *amem)
+{
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_resource_type.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_producer_consumer.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_decode.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_min_address_fixed.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_max_address_fixed.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_granularity.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_min_address_range.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_max_address_range.attr);
+ sysfs_create_file(&amem->kobj,
+ &acpi_mem_attr_address_translation_offset.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_address_length.attr);
+
+ return 0;
+}
static int
acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
@@ -97,6 +433,7 @@ acpi_memory_get_device_resources(struct
return_VALUE(-EINVAL);
resource = (struct acpi_resource *) buffer.pointer;
+ mem_device->resource = *resource;
switch (resource->id) {
case ACPI_RSTYPE_ADDRESS16:
@@ -413,17 +750,26 @@ acpi_memory_device_add(struct acpi_devic
/* Get the range from the _CRS */
result = acpi_memory_get_device_resources(mem_device);
- if (result) {
- kfree(mem_device);
- return_VALUE(result);
- }
-
+ if (result)
+ goto errout;
+
+ result = create_acpi_mem(mem_device, device);
+ if (result)
+ goto errout;
+
+ result = fs_add_memory(&mem_device->amem);
+ if (result)
+ goto errout;
+
/* Set the device state */
mem_device->state = MEMORY_POWER_ON_STATE;
printk(KERN_INFO "%s \n", acpi_device_name(device));
return_VALUE(result);
+errout:
+ kfree(mem_device);
+ return_VALUE(result);
}
static int
@@ -527,6 +873,10 @@ acpi_memory_device_init (void)
ACPI_FUNCTION_TRACE("acpi_memory_device_init");
+ result = acpi_mem_fs_init();
+ if (result)
+ return_VALUE(-ENODEV);
+
result = acpi_bus_register_driver(&acpi_memory_device_driver);
if (result < 0)
@@ -540,6 +890,7 @@ acpi_memory_device_init (void)
if (ACPI_FAILURE (status)) {
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "walk_namespace failed\n"));
acpi_bus_unregister_driver(&acpi_memory_device_driver);
+ acpi_mem_fs_exit();
return_VALUE(-ENODEV);
}
@@ -567,6 +918,8 @@ acpi_memory_device_exit (void)
acpi_bus_unregister_driver(&acpi_memory_device_driver);
+ acpi_mem_fs_exit();
+
return_VOID;
}
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object
@ 2004-09-16 14:07 Tolentino, Matthew E
[not found] ` <D36CE1FCEFD3524B81CA12C6FE5BCAB007B6FA60-oCDej+MBycNZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Tolentino, Matthew E @ 2004-09-16 14:07 UTC (permalink / raw)
To: Keiichiro Tokunaga, S, Naveen B, Dave Hansen
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
lhms-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
>I have changed the patch to create directories and files in
>/sys/firmware/acpi/memory/ from Dave's comments. The files are
>to export the following stuffs of each ACPI memory object for the
>first version.
Hmm. I thought Dave's suggestion was to create an arch-agnostic
viewpoint of physical memory and dump it into
/sys/devices/system/memory in order to gain consistency between
arches...
># ls /sys/firmware/acpi/memory/MEM1/
>address_length
>address_translation_offset
>granularity
>max_address_fixed
>max_address_range
>min_address_fixed
>min_address_range
>producer_consumer
>resource_type
For my understanding, what exactly are all of these attributes for?
matt
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object
[not found] ` <D36CE1FCEFD3524B81CA12C6FE5BCAB007B6FA60-oCDej+MBycNZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2004-09-16 16:00 ` Keiichiro Tokunaga
2004-09-16 16:46 ` Keiichiro Tokunaga
1 sibling, 0 replies; 7+ messages in thread
From: Keiichiro Tokunaga @ 2004-09-16 16:00 UTC (permalink / raw)
To: Tolentino, Matthew E
Cc: naveen.b.s-ral2JQCrhuEAvxtiuMwx3w,
haveblue-r/Jw6+rmf7HQT0dZR+AlfA,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
lhms-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
tokunaga.keiich-+CUm20s59erQFUHtdCDX3A
On Thu, 16 Sep 2004 07:07:07 -0700, Tolentino, Matthew E wrote:
> >I have changed the patch to create directories and files in
> >/sys/firmware/acpi/memory/ from Dave's comments. The files are
> >to export the following stuffs of each ACPI memory object for the
> >first version.
>
> Hmm. I thought Dave's suggestion was to create an arch-agnostic
> viewpoint of physical memory and dump it into
> /sys/devices/system/memory in order to gain consistency between
> arches...
Yes, that is also his suggestion. I understand that we have agreedthere are
arch-specific and agnostic
Actually, the patch is to create
just arch-specific directory, since he has agreed with it.
> ># ls /sys/firmware/acpi/memory/MEM1/
> >address_length
> >address_translation_offset
> >granularity
> >max_address_fixed
> >max_address_range
> >min_address_fixed
> >min_address_range
> >producer_consumer
> >resource_type
>
> For my understanding, what exactly are all of these attributes for?
>
> matt
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object
[not found] ` <D36CE1FCEFD3524B81CA12C6FE5BCAB007B6FA60-oCDej+MBycNZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-09-16 16:00 ` Keiichiro Tokunaga
@ 2004-09-16 16:46 ` Keiichiro Tokunaga
[not found] ` <20040917014611.000055db.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
1 sibling, 1 reply; 7+ messages in thread
From: Keiichiro Tokunaga @ 2004-09-16 16:46 UTC (permalink / raw)
To: Tolentino, Matthew E
Cc: naveen.b.s-ral2JQCrhuEAvxtiuMwx3w,
haveblue-r/Jw6+rmf7HQT0dZR+AlfA,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
lhms-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
tokunaga.keiich-+CUm20s59erQFUHtdCDX3A
Sorry, I sent the email in the middle of writing...
On Thu, 16 Sep 2004 07:07:07 -0700, Tolentino, Matthew E wrote:
> >I have changed the patch to create directories and files in
> >/sys/firmware/acpi/memory/ from Dave's comments. The files are
> >to export the following stuffs of each ACPI memory object for the
> >first version.
>
> Hmm. I thought Dave's suggestion was to create an arch-agnostic
> viewpoint of physical memory and dump it into
> /sys/devices/system/memory in order to gain consistency between
> arches...
Yes, that is also his suggestion. I think we have agreed that there
are arch-specific and agnostic directories. The agnostic one would
consist of some files that the specific one provides. Actually, the
patch is to create just the arch-specific directory. Then I would
turn into the agnostic stuffs.
> ># ls /sys/firmware/acpi/memory/MEM1/
> >address_length
> >address_translation_offset
> >granularity
> >max_address_fixed
> >max_address_range
> >min_address_fixed
> >min_address_range
> >producer_consumer
> >resource_type
>
> For my understanding, what exactly are all of these attributes for?
The directory name 'MEM1', min_address_range and max_address_range
are used to know the physical address range of the ACPI memory object.
Then, we can determine what memsection belongs to the ACPI memory
object by using the address range.
ACPI container hotplug is assuming to use the method to know
corresponding memsections (To be exact, a user mode script
'container.agent' uses it). When ACPI container hotplug is invoked,
it knows ACPI object names of devices contained in a container. So
when the container hotplug invokes the 'container.agent', it just can
tell ACPI object names. The 'container.agent' is responsible for
onlining/offlining, so it needs to translate the ACPI object names
to memsections. But, I am not sure about the other files...
Thanks,
Keiichiro Tokunaga
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object
[not found] ` <20040917014611.000055db.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
@ 2004-09-16 17:55 ` Dave Hansen
2004-09-17 1:43 ` Keiichiro Tokunaga
0 siblings, 1 reply; 7+ messages in thread
From: Dave Hansen @ 2004-09-16 17:55 UTC (permalink / raw)
To: Keiichiro Tokunaga
Cc: Matthew E Tolentino, naveen.b.s-ral2JQCrhuEAvxtiuMwx3w,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, lhms
On Thu, 2004-09-16 at 09:46, Keiichiro Tokunaga wrote:
> Sorry, I sent the email in the middle of writing...
>
> On Thu, 16 Sep 2004 07:07:07 -0700, Tolentino, Matthew E wrote:
> > >I have changed the patch to create directories and files in
> > >/sys/firmware/acpi/memory/ from Dave's comments. The files are
> > >to export the following stuffs of each ACPI memory object for the
> > >first version.
> >
> > Hmm. I thought Dave's suggestion was to create an arch-agnostic
> > viewpoint of physical memory and dump it into
> > /sys/devices/system/memory in order to gain consistency between
> > arches...
>
> Yes, that is also his suggestion. I think we have agreed that there
> are arch-specific and agnostic directories. The agnostic one would
> consist of some files that the specific one provides. Actually, the
> patch is to create just the arch-specific directory. Then I would
> turn into the agnostic stuffs.
Could you explain what each of those fields means?
-- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object
2004-09-16 17:55 ` Dave Hansen
@ 2004-09-17 1:43 ` Keiichiro Tokunaga
0 siblings, 0 replies; 7+ messages in thread
From: Keiichiro Tokunaga @ 2004-09-17 1:43 UTC (permalink / raw)
To: Dave Hansen
Cc: tokunaga.keiich-+CUm20s59erQFUHtdCDX3A,
matthew.e.tolentino-ral2JQCrhuEAvxtiuMwx3w,
naveen.b.s-ral2JQCrhuEAvxtiuMwx3w,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
lhms-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Thu, 16 Sep 2004 10:55:11 -0700 Dave Hansen wrote:
> On Thu, 2004-09-16 at 09:46, Keiichiro Tokunaga wrote:
> > Sorry, I sent the email in the middle of writing...
> >
> > On Thu, 16 Sep 2004 07:07:07 -0700, Tolentino, Matthew E wrote:
> > > >I have changed the patch to create directories and files in
> > > >/sys/firmware/acpi/memory/ from Dave's comments. The files are
> > > >to export the following stuffs of each ACPI memory object for the
> > > >first version.
> > >
> > > Hmm. I thought Dave's suggestion was to create an arch-agnostic
> > > viewpoint of physical memory and dump it into
> > > /sys/devices/system/memory in order to gain consistency between
> > > arches...
> >
> > Yes, that is also his suggestion. I think we have agreed that there
> > are arch-specific and agnostic directories. The agnostic one would
> > consist of some files that the specific one provides. Actually, the
> > patch is to create just the arch-specific directory. Then I would
> > turn into the agnostic stuffs.
>
> Could you explain what each of those fields means?
Those fields are all defined in ACPI spec 3.0. I steal the definitions
from the spec Table 6-39 below ;)
resource_type:
This indicates which type of resource this descriptor describes.
producer_consumer:
1 - This device consumes this resource
0 - This device produces and consumers this resource
decode: (This is for bridge devices)
min_address_fixed:
1 - The specified minimum address is fixed
0 - The specified minimum address is not fixed
max_address_fixed:
1 - The specified maximum address is fixed
0 - The specified maximum address is not fixed
granularity:
A set bit in this mask means that this bit is decoded. All bits less
significant than the most significant set bit must be set. That is,
the value of the full Address Space Granularity field (all 32 bits)
must be a number (2^n - 1)
min_address_range: (This definition is from the former page, Table 6-36)
A minimum base memory address of a device
max_address_range: (This definition is from the former page, Table 6-36)
A maximum base memory address of a device
address_translation_offset: (This is for bridge devices)
address_length: (This definition is from the former page, Table 6-36)
A length of the memory range
I just tried to export the fields for the first version. As I said to
Matt, at least min_address_range and max_address_range are
in real need so far. So, fields that should be exported might need
to be reconsidered.
Thanks,
Keiichiro Tokunaga
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object
[not found] ` <20040916194725.562b50f0.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
@ 2004-09-24 8:46 ` Keiichiro Tokunaga
0 siblings, 0 replies; 7+ messages in thread
From: Keiichiro Tokunaga @ 2004-09-24 8:46 UTC (permalink / raw)
To: naveen.b.s-ral2JQCrhuEAvxtiuMwx3w
Cc: tokunaga.keiich-+CUm20s59erQFUHtdCDX3A,
haveblue-r/Jw6+rmf7HQT0dZR+AlfA,
matthew.e.tolentino-ral2JQCrhuEAvxtiuMwx3w,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
lhms-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Thu, 16 Sep 2004 19:47:25 +0900 Keiichiro Tokunaga wrote:
> On Fri, 10 Sep 2004 23:02:00 +0900 Keiichiro Tokunaga wrote:
> > On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> > > Attached is an ACPI based hot plug driver patch to support physical
> > > memory hotplug. This driver supports physical hotplug operation on
> > > memory, fields notifications from firmware and notifies the VM of the
> > > affected memory ranges. The following patch is against kernel
> > > 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> > > posted at: http://sprucegoose.sr71.net/patches. This patch has been
> > > tested on real prototype hardware in the hot-add memory case. Hot
> > > remove feature is tested in an emulated environment (by overriding
> > > ACPI DSDT).
> > >
> > > Please review and consider for inclusion.
> >
> > I would like to add a feature into drivers/acpi/memory.c.
> >
> > Please see the patch below. This patch is for the kernel applying
> > your patch.
>
> I have changed the patch to create directories and files in
> /sys/firmware/acpi/memory/ from Dave's comments. The files are
> to export the following stuffs of each ACPI memory object for the
> first version.
I have updated the patch to show just information in real need.
o min_address_range
o max_address_range
This patch is still for 2.6.8.1-mm3.
Naveen, if I need to update the patch, please let me know.
Thanks,
Keiichiro Tokunaga
Name: sysfs_memory.patch
Status: Tested on 2.6.8.1-mm3
Signed-off-by: Keiichiro Tokunaga <tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Description:
This patch is to create directory '/sys/firmware/acpi/memory/',
directories for each ACPI memory object, and files under it. These
files are to export information of ACPI memory object. This version
just creates two files an ACPI memory object, min_address_range and
max_address_range. What it looks like is:
/sys/firmware/acpi/memory/MEM0/min_address_range, where MEM0 is an
ACPI memory object name.
---
drivers/acpi/memory.c | 199 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 194 insertions(+), 5 deletions(-)
diff -puN drivers/acpi/memory.c~sysfs_memory drivers/acpi/memory.c
--- linux-2.6.8.1-mm3/drivers/acpi/memory.c~sysfs_memory 2004-09-16 10:19:00.000000000 +0900
+++ linux-2.6.8.1-mm3-kei/drivers/acpi/memory.c 2004-09-24 17:31:13.000000000 +0900
@@ -69,6 +69,15 @@ static struct acpi_driver acpi_memory_de
},
};
+struct acpi_mem {
+ struct acpi_mem_device_ops *ops;
+ void (*release)(struct acpi_mem *mdev);
+ struct kobject kobj;
+};
+
+#define to_acpi_mem(n) container_of(n, struct acpi_mem, kobj)
+#define acpi_mem_to_dev(n) container_of(n, struct acpi_memory_device, amem)
+
struct acpi_memory_device {
acpi_handle handle;
unsigned int state; /* State of the memory device */
@@ -76,8 +85,171 @@ struct acpi_memory_device {
unsigned short read_write_attribute;/* memory read/write attribute */
u64 start_addr; /* Memory Range start physical addr */
u64 end_addr; /* Memory Range end physical addr */
+ struct acpi_resource resource;
+ struct acpi_mem amem;
+};
+
+/*
+ * /sys/firmware/acpi/memory/
+ */
+struct acpi_mem_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct acpi_mem *, char *);
+ ssize_t (*store)(struct acpi_mem *, const char *, size_t);
+};
+
+#define to_acpi_mem_attr(n) container_of(n, struct acpi_mem_attribute, attr)
+
+static ssize_t acpi_mem_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct acpi_mem *amem = to_acpi_mem(kobj);
+ struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+ return attribute->show ? attribute->show(amem, buf) : 0;
+}
+
+static ssize_t acpi_mem_attr_store(struct kobject *kobj,
+ struct attribute *attr, const char *buf,
+ size_t len)
+{
+ struct acpi_mem *amem = to_acpi_mem(kobj);
+ struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+ return attribute->store ? attribute->store(amem, buf, len) : 0;
+}
+
+static struct sysfs_ops acpi_mem_sysfs_ops = {
+ .show = acpi_mem_attr_show,
+ .store = acpi_mem_attr_store,
+};
+
+static void acpi_mem_release(struct kobject *kobj)
+{
+ sysfs_remove_dir(kobj);
+ if (kobj->kset) {
+ down_write(&kobj->kset->subsys->rwsem);
+ list_del_init(&kobj->entry);
+ up_write(&kobj->kset->subsys->rwsem);
+ }
+}
+
+static struct kobj_type acpi_mem_ktype = {
+ .sysfs_ops = &acpi_mem_sysfs_ops,
+ .release = &acpi_mem_release,
};
+static decl_subsys_name(acpi_mem, memory, &acpi_mem_ktype, NULL);
+
+static int acpi_mem_register(struct acpi_mem *amem)
+{
+ return kobject_register(&amem->kobj);
+}
+
+int create_acpi_mem(struct acpi_memory_device *mem_device,
+ struct acpi_device *device)
+{
+ int result;
+ struct acpi_mem *amem = &mem_device->amem;
+
+ ACPI_FUNCTION_TRACE("create_acpi_mem");
+
+ memset(amem, 0, sizeof(struct acpi_mem));
+ kobject_set_name(&amem->kobj, device->pnp.bus_id);
+ kobj_set_kset_s(amem, acpi_mem_subsys);
+ amem->kobj.parent = &acpi_mem_subsys.kset.kobj;
+
+ result = acpi_mem_register(amem);
+ if (result)
+ goto end;
+end:
+ return_VALUE(result);
+}
+
+int acpi_mem_fs_init(void)
+{
+ int result;
+ extern struct subsystem acpi_subsys;
+
+ ACPI_FUNCTION_TRACE("acpi_mem_fs_init");
+
+ acpi_mem_subsys.kset.kobj.parent = &acpi_subsys.kset.kobj;
+ result = subsystem_register(&acpi_mem_subsys);
+
+ return_VALUE(result);
+}
+
+void acpi_mem_fs_exit(void)
+{
+ ACPI_FUNCTION_TRACE("acpi_mem_fs_exit");
+
+ subsystem_unregister(&acpi_mem_subsys);
+
+ return_VOID;
+}
+
+static int get_address64(struct acpi_mem *amem,
+ struct acpi_resource_address64 *address64)
+{
+ struct acpi_memory_device *mem_device = acpi_mem_to_dev(amem);
+ struct acpi_resource *resource;
+
+ if (!mem_device)
+ return -ENODEV;
+
+ resource = &mem_device->resource;
+
+ acpi_resource_to_address64(resource, address64);
+
+ if (address64->resource_type != ACPI_MEMORY_RANGE)
+ return -EINVAL;
+
+ return 0;
+}
+
+static ssize_t min_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%llx\n", address64.min_address_range);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_min_address_range = {
+ .attr = {.name = "min_address_range", .mode = S_IFREG | S_IRUGO},
+ .show = min_address_range_read_file,
+};
+
+static ssize_t max_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+ int result;
+ struct acpi_resource_address64 address64;
+
+ result = get_address64(amem, &address64);
+ if (result)
+ return result;
+
+ result = sprintf(buf, "0x%llx\n", address64.max_address_range);
+
+ return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_max_address_range = {
+ .attr = {.name = "max_address_range", .mode = S_IFREG | S_IRUGO},
+ .show = max_address_range_read_file,
+};
+
+static int fs_add_memory(struct acpi_mem *amem)
+{
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_min_address_range.attr);
+ sysfs_create_file(&amem->kobj, &acpi_mem_attr_max_address_range.attr);
+
+ return 0;
+}
static int
acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
@@ -97,6 +269,7 @@ acpi_memory_get_device_resources(struct
return_VALUE(-EINVAL);
resource = (struct acpi_resource *) buffer.pointer;
+ mem_device->resource = *resource;
switch (resource->id) {
case ACPI_RSTYPE_ADDRESS16:
@@ -413,17 +586,26 @@ acpi_memory_device_add(struct acpi_devic
/* Get the range from the _CRS */
result = acpi_memory_get_device_resources(mem_device);
- if (result) {
- kfree(mem_device);
- return_VALUE(result);
- }
-
+ if (result)
+ goto errout;
+
+ result = create_acpi_mem(mem_device, device);
+ if (result)
+ goto errout;
+
+ result = fs_add_memory(&mem_device->amem);
+ if (result)
+ goto errout;
+
/* Set the device state */
mem_device->state = MEMORY_POWER_ON_STATE;
printk(KERN_INFO "%s \n", acpi_device_name(device));
return_VALUE(result);
+errout:
+ kfree(mem_device);
+ return_VALUE(result);
}
static int
@@ -527,6 +709,10 @@ acpi_memory_device_init (void)
ACPI_FUNCTION_TRACE("acpi_memory_device_init");
+ result = acpi_mem_fs_init();
+ if (result)
+ return_VALUE(-ENODEV);
+
result = acpi_bus_register_driver(&acpi_memory_device_driver);
if (result < 0)
@@ -540,6 +726,7 @@ acpi_memory_device_init (void)
if (ACPI_FAILURE (status)) {
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "walk_namespace failed\n"));
acpi_bus_unregister_driver(&acpi_memory_device_driver);
+ acpi_mem_fs_exit();
return_VALUE(-ENODEV);
}
@@ -567,6 +754,8 @@ acpi_memory_device_exit (void)
acpi_bus_unregister_driver(&acpi_memory_device_driver);
+ acpi_mem_fs_exit();
+
return_VOID;
}
_
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-09-24 8:46 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-16 14:07 [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object Tolentino, Matthew E
[not found] ` <D36CE1FCEFD3524B81CA12C6FE5BCAB007B6FA60-oCDej+MBycNZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-09-16 16:00 ` Keiichiro Tokunaga
2004-09-16 16:46 ` Keiichiro Tokunaga
[not found] ` <20040917014611.000055db.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2004-09-16 17:55 ` Dave Hansen
2004-09-17 1:43 ` Keiichiro Tokunaga
-- strict thread matches above, loose matches on Subject: below --
2004-09-09 10:54 [PATCH] ACPI based Memory Hotplug Driver Patch S, Naveen B
2004-09-10 14:02 ` Keiichiro Tokunaga
[not found] ` <20040910230200.73eb0374.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2004-09-16 10:47 ` [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object Keiichiro Tokunaga
[not found] ` <20040916194725.562b50f0.tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2004-09-24 8:46 ` Keiichiro Tokunaga
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox