* [PATCH 8/9] v3 Define memory_block_size_bytes for x86_64 with CONFIG_X86_UV set
From: Nathan Fontenot @ 2010-10-01 18:37 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev
Cc: Greg KH, steiner, Robin Holt, KAMEZAWA Hiroyuki, Dave Hansen
In-Reply-To: <4CA62700.7010809@austin.ibm.com>
Define a version of memory_block_size_bytes for x86_64 when CONFIG_X86_UV is
set.
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Jack Steiner <steiner@sgi.com>
---
arch/x86/mm/init_64.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Index: linux-next/arch/x86/mm/init_64.c
===================================================================
--- linux-next.orig/arch/x86/mm/init_64.c 2010-09-29 14:56:25.000000000 -0500
+++ linux-next/arch/x86/mm/init_64.c 2010-10-01 13:00:50.000000000 -0500
@@ -51,6 +51,7 @@
#include <asm/numa.h>
#include <asm/cacheflush.h>
#include <asm/init.h>
+#include <asm/uv/uv.h>
#include <linux/bootmem.h>
static int __init parse_direct_gbpages_off(char *arg)
@@ -902,6 +903,19 @@
return NULL;
}
+#ifdef CONFIG_X86_UV
+#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
+
+unsigned long memory_block_size_bytes(void)
+{
+ if (is_uv_system()) {
+ printk(KERN_INFO "UV: memory block size 2GB\n");
+ return 2UL * 1024 * 1024 * 1024;
+ }
+ return MIN_MEMORY_BLOCK_SIZE;
+}
+#endif
+
#ifdef CONFIG_SPARSEMEM_VMEMMAP
/*
* Initialise the sparsemem vmemmap using huge-pages at the PMD level.
^ permalink raw reply
* [PATCH 9/9] v3 Update memory hotplug documentation
From: Nathan Fontenot @ 2010-10-01 18:37 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev
Cc: Greg KH, steiner, Robin Holt, KAMEZAWA Hiroyuki, Dave Hansen
In-Reply-To: <4CA62700.7010809@austin.ibm.com>
Update the memory hotplug documentation to reflect the new behaviors of
memory blocks reflected in sysfs.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
Documentation/memory-hotplug.txt | 47 +++++++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 16 deletions(-)
Index: linux-next/Documentation/memory-hotplug.txt
===================================================================
--- linux-next.orig/Documentation/memory-hotplug.txt 2010-09-29 14:56:24.000000000 -0500
+++ linux-next/Documentation/memory-hotplug.txt 2010-09-30 14:59:47.000000000 -0500
@@ -126,36 +126,51 @@
--------------------------------
4 sysfs files for memory hotplug
--------------------------------
-All sections have their device information under /sys/devices/system/memory as
+All sections have their device information in sysfs. Each section is part of
+a memory block under /sys/devices/system/memory as
/sys/devices/system/memory/memoryXXX
-(XXX is section id.)
+(XXX is the section id.)
-Now, XXX is defined as start_address_of_section / section_size.
+Now, XXX is defined as (start_address_of_section / section_size) of the first
+section contained in the memory block. The files 'phys_index' and
+'end_phys_index' under each directory report the beginning and end section id's
+for the memory block covered by the sysfs directory. It is expected that all
+memory sections in this range are present and no memory holes exist in the
+range. Currently there is no way to determine if there is a memory hole, but
+the existence of one should not affect the hotplug capabilities of the memory
+block.
For example, assume 1GiB section size. A device for a memory starting at
0x100000000 is /sys/device/system/memory/memory4
(0x100000000 / 1Gib = 4)
This device covers address range [0x100000000 ... 0x140000000)
-Under each section, you can see 4 files.
+Under each section, you can see 4 or 5 files, the end_phys_index file being
+a recent addition and not present on older kernels.
-/sys/devices/system/memory/memoryXXX/phys_index
+/sys/devices/system/memory/memoryXXX/start_phys_index
+/sys/devices/system/memory/memoryXXX/end_phys_index
/sys/devices/system/memory/memoryXXX/phys_device
/sys/devices/system/memory/memoryXXX/state
/sys/devices/system/memory/memoryXXX/removable
-'phys_index' : read-only and contains section id, same as XXX.
-'state' : read-write
- at read: contains online/offline state of memory.
- at write: user can specify "online", "offline" command
-'phys_device': read-only: designed to show the name of physical memory device.
- This is not well implemented now.
-'removable' : read-only: contains an integer value indicating
- whether the memory section is removable or not
- removable. A value of 1 indicates that the memory
- section is removable and a value of 0 indicates that
- it is not removable.
+'phys_index' : read-only and contains section id of the first section
+ in the memory block, same as XXX.
+'end_phys_index' : read-only and contains section id of the last section
+ in the memory block.
+'state' : read-write
+ at read: contains online/offline state of memory.
+ at write: user can specify "online", "offline" command
+ which will be performed on al sections in the block.
+'phys_device' : read-only: designed to show the name of physical memory
+ device. This is not well implemented now.
+'removable' : read-only: contains an integer value indicating
+ whether the memory block is removable or not
+ removable. A value of 1 indicates that the memory
+ block is removable and a value of 0 indicates that
+ it is not removable. A memory block is removable only if
+ every section in the block is removable.
NOTE:
These directories/files appear after physical memory hotplug phase.
^ permalink raw reply
* Re: [PATCH 2/9] v3 Add mutex for adding/removing memory blocks
From: Robin Holt @ 2010-10-01 18:45 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62896.2060307@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:29:42PM -0500, Nathan Fontenot wrote:
> Add a new mutex for use in adding and removing of memory blocks. This
> is needed to avoid any race conditions in which the same memory block could
> be added and removed at the same time.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
I am fine with this patch by itself, but its only real function is
to protect the count introduced by the next patch. You might want to
combine the patches, but if not, that is fine as well.
Robin
^ permalink raw reply
* Re: [PATCH 1/9] v3 Move find_memory_block routine
From: Robin Holt @ 2010-10-01 18:40 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62857.4030803@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:28:39PM -0500, Nathan Fontenot wrote:
> Move the find_memory_block() routine up to avoid needing a forward
> declaration in subsequent patches.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
^ permalink raw reply
* Re: [PATCH 3/9] v3 Add section count to memory_block struct
From: Robin Holt @ 2010-10-01 18:46 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA628D0.6030508@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:30:40PM -0500, Nathan Fontenot wrote:
> Add a section count property to the memory_block struct to track the number
> of memory sections that have been added/removed from a memory block. This
> allows us to know when the last memory section of a memory block has been
> removed so we can remove the memory block.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
^ permalink raw reply
* Re: [PATCH 5/9] v3 rename phys_index properties of memory block struct
From: Robin Holt @ 2010-10-01 18:54 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62982.5080900@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:33:38PM -0500, Nathan Fontenot wrote:
> Update the 'phys_index' property of a the memory_block struct to be
> called start_section_nr, and add a end_section_nr property. The
> data tracked here is the same but the updated naming is more in line
> with what is stored here, namely the first and last section number
> that the memory block spans.
>
> The names presented to userspace remain the same, phys_index for
> start_section_nr and end_phys_index for end_section_nr, to avoid breaking
> anything in userspace.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
^ permalink raw reply
* Re: [PATCH 4/9] v3 Allow memory blocks to span multiple memory sections
From: Nathan Fontenot @ 2010-10-01 18:56 UTC (permalink / raw)
To: Robin Holt
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <20101001185250.GK14064@sgi.com>
On 10/01/2010 01:52 PM, Robin Holt wrote:
> On Fri, Oct 01, 2010 at 01:31:51PM -0500, Nathan Fontenot wrote:
>> Update the memory sysfs code such that each sysfs memory directory is now
>> considered a memory block that can span multiple memory sections per
>> memory block. The default size of each memory block is SECTION_SIZE_BITS
>> to maintain the current behavior of having a single memory section per
>> memory block (i.e. one sysfs directory per memory section).
>>
>> For architectures that want to have memory blocks span multiple
>> memory sections they need only define their own memory_block_size_bytes()
>> routine.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>>
>> ---
>> drivers/base/memory.c | 155 ++++++++++++++++++++++++++++++++++----------------
>> 1 file changed, 108 insertions(+), 47 deletions(-)
>>
>> Index: linux-next/drivers/base/memory.c
>> ===================================================================
>> --- linux-next.orig/drivers/base/memory.c 2010-09-30 14:13:50.000000000 -0500
>> +++ linux-next/drivers/base/memory.c 2010-09-30 14:46:00.000000000 -0500
> ...
>> +static unsigned long get_memory_block_size(void)
>> +{
>> + u32 block_sz;
> ^^^
>
> I think this should be unsigned long. u32 will work, but everything
> else has been changed to use unsigned long. If you disagree, I will
> happily acquiesce as nothing is currently broken. If SGI decides to make
> memory_block_size_bytes more dynamic, we will fix this up at that time.
You're right, that should have been made an unsigned long also. I'll attach a new
patch with that corrected.
-Nathan
^ permalink raw reply
* Re: [PATCH 8/9] v3 Define memory_block_size_bytes for x86_64 with CONFIG_X86_UV set
From: Robin Holt @ 2010-10-01 18:57 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62A51.70807@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:37:05PM -0500, Nathan Fontenot wrote:
> Define a version of memory_block_size_bytes for x86_64 when CONFIG_X86_UV is
> set.
>
> Signed-off-by: Robin Holt <holt@sgi.com>
> Signed-off-by: Jack Steiner <steiner@sgi.com>
I think this technically needs a Signed-off-by: <you> since you
are passing it upstream.
>
> ---
> arch/x86/mm/init_64.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> Index: linux-next/arch/x86/mm/init_64.c
> ===================================================================
> --- linux-next.orig/arch/x86/mm/init_64.c 2010-09-29 14:56:25.000000000 -0500
> +++ linux-next/arch/x86/mm/init_64.c 2010-10-01 13:00:50.000000000 -0500
> @@ -51,6 +51,7 @@
> #include <asm/numa.h>
> #include <asm/cacheflush.h>
> #include <asm/init.h>
> +#include <asm/uv/uv.h>
> #include <linux/bootmem.h>
>
> static int __init parse_direct_gbpages_off(char *arg)
> @@ -902,6 +903,19 @@
> return NULL;
> }
>
> +#ifdef CONFIG_X86_UV
> +#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
> +
> +unsigned long memory_block_size_bytes(void)
> +{
> + if (is_uv_system()) {
> + printk(KERN_INFO "UV: memory block size 2GB\n");
> + return 2UL * 1024 * 1024 * 1024;
> + }
> + return MIN_MEMORY_BLOCK_SIZE;
> +}
> +#endif
> +
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
> /*
> * Initialise the sparsemem vmemmap using huge-pages at the PMD level.
>
^ permalink raw reply
* Re: [PATCH 9/9] v3 Update memory hotplug documentation
From: Robin Holt @ 2010-10-01 18:58 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62A7D.8030905@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:37:49PM -0500, Nathan Fontenot wrote:
> Update the memory hotplug documentation to reflect the new behaviors of
> memory blocks reflected in sysfs.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
^ permalink raw reply
* Re: [PATCH 4/9] v3 Allow memory blocks to span multiple memory sections
From: Nathan Fontenot @ 2010-10-01 19:00 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev
Cc: Greg KH, steiner, Robin Holt, KAMEZAWA Hiroyuki, Dave Hansen
In-Reply-To: <4CA62917.80008@austin.ibm.com>
Update the memory sysfs code such that each sysfs memory directory is now
considered a memory block that can span multiple memory sections per
memory block. The default size of each memory block is SECTION_SIZE_BITS
to maintain the current behavior of having a single memory section per
memory block (i.e. one sysfs directory per memory section).
For architectures that want to have memory blocks span multiple
memory sections they need only define their own memory_block_size_bytes()
routine.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Updated patch to correct get_memory_block_size() variable block_sz to be
an unsigned long.
---
drivers/base/memory.c | 155 ++++++++++++++++++++++++++++++++++----------------
1 file changed, 108 insertions(+), 47 deletions(-)
Index: linux-next/drivers/base/memory.c
===================================================================
--- linux-next.orig/drivers/base/memory.c 2010-09-30 14:13:50.000000000 -0500
+++ linux-next/drivers/base/memory.c 2010-10-01 13:50:19.000000000 -0500
@@ -30,6 +30,14 @@
static DEFINE_MUTEX(mem_sysfs_mutex);
#define MEMORY_CLASS_NAME "memory"
+#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
+
+static int sections_per_block;
+
+static inline int base_memory_block_id(int section_nr)
+{
+ return section_nr / sections_per_block;
+}
static struct sysdev_class memory_sysdev_class = {
.name = MEMORY_CLASS_NAME,
@@ -84,28 +92,47 @@
* register_memory - Setup a sysfs device for a memory block
*/
static
-int register_memory(struct memory_block *memory, struct mem_section *section)
+int register_memory(struct memory_block *memory)
{
int error;
memory->sysdev.cls = &memory_sysdev_class;
- memory->sysdev.id = __section_nr(section);
+ memory->sysdev.id = memory->phys_index / sections_per_block;
error = sysdev_register(&memory->sysdev);
return error;
}
static void
-unregister_memory(struct memory_block *memory, struct mem_section *section)
+unregister_memory(struct memory_block *memory)
{
BUG_ON(memory->sysdev.cls != &memory_sysdev_class);
- BUG_ON(memory->sysdev.id != __section_nr(section));
/* drop the ref. we got in remove_memory_block() */
kobject_put(&memory->sysdev.kobj);
sysdev_unregister(&memory->sysdev);
}
+unsigned long __weak memory_block_size_bytes(void)
+{
+ return MIN_MEMORY_BLOCK_SIZE;
+}
+
+static unsigned long get_memory_block_size(void)
+{
+ unsigned long block_sz;
+
+ block_sz = memory_block_size_bytes();
+
+ /* Validate blk_sz is a power of 2 and not less than section size */
+ if ((block_sz & (block_sz - 1)) || (block_sz < MIN_MEMORY_BLOCK_SIZE)) {
+ WARN_ON(1);
+ block_sz = MIN_MEMORY_BLOCK_SIZE;
+ }
+
+ return block_sz;
+}
+
/*
* use this as the physical section index that this memsection
* uses.
@@ -116,7 +143,7 @@
{
struct memory_block *mem =
container_of(dev, struct memory_block, sysdev);
- return sprintf(buf, "%08lx\n", mem->phys_index);
+ return sprintf(buf, "%08lx\n", mem->phys_index / sections_per_block);
}
/*
@@ -125,13 +152,16 @@
static ssize_t show_mem_removable(struct sys_device *dev,
struct sysdev_attribute *attr, char *buf)
{
- unsigned long start_pfn;
- int ret;
+ unsigned long i, pfn;
+ int ret = 1;
struct memory_block *mem =
container_of(dev, struct memory_block, sysdev);
- start_pfn = section_nr_to_pfn(mem->phys_index);
- ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
+ for (i = 0; i < sections_per_block; i++) {
+ pfn = section_nr_to_pfn(mem->phys_index + i);
+ ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
+ }
+
return sprintf(buf, "%d\n", ret);
}
@@ -184,17 +214,14 @@
* OK to have direct references to sparsemem variables in here.
*/
static int
-memory_block_action(struct memory_block *mem, unsigned long action)
+memory_section_action(unsigned long phys_index, unsigned long action)
{
int i;
- unsigned long psection;
unsigned long start_pfn, start_paddr;
struct page *first_page;
int ret;
- int old_state = mem->state;
- psection = mem->phys_index;
- first_page = pfn_to_page(psection << PFN_SECTION_SHIFT);
+ first_page = pfn_to_page(phys_index << PFN_SECTION_SHIFT);
/*
* The probe routines leave the pages reserved, just
@@ -207,8 +234,8 @@
continue;
printk(KERN_WARNING "section number %ld page number %d "
- "not reserved, was it already online? \n",
- psection, i);
+ "not reserved, was it already online?\n",
+ phys_index, i);
return -EBUSY;
}
}
@@ -219,18 +246,13 @@
ret = online_pages(start_pfn, PAGES_PER_SECTION);
break;
case MEM_OFFLINE:
- mem->state = MEM_GOING_OFFLINE;
start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
ret = remove_memory(start_paddr,
PAGES_PER_SECTION << PAGE_SHIFT);
- if (ret) {
- mem->state = old_state;
- break;
- }
break;
default:
- WARN(1, KERN_WARNING "%s(%p, %ld) unknown action: %ld\n",
- __func__, mem, action, action);
+ WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
+ "%ld\n", __func__, phys_index, action, action);
ret = -EINVAL;
}
@@ -240,7 +262,8 @@
static int memory_block_change_state(struct memory_block *mem,
unsigned long to_state, unsigned long from_state_req)
{
- int ret = 0;
+ int i, ret = 0;
+
mutex_lock(&mem->state_mutex);
if (mem->state != from_state_req) {
@@ -248,8 +271,22 @@
goto out;
}
- ret = memory_block_action(mem, to_state);
- if (!ret)
+ if (to_state == MEM_OFFLINE)
+ mem->state = MEM_GOING_OFFLINE;
+
+ for (i = 0; i < sections_per_block; i++) {
+ ret = memory_section_action(mem->phys_index + i, to_state);
+ if (ret)
+ break;
+ }
+
+ if (ret) {
+ for (i = 0; i < sections_per_block; i++)
+ memory_section_action(mem->phys_index + i,
+ from_state_req);
+
+ mem->state = from_state_req;
+ } else
mem->state = to_state;
out:
@@ -262,20 +299,15 @@
struct sysdev_attribute *attr, const char *buf, size_t count)
{
struct memory_block *mem;
- unsigned int phys_section_nr;
int ret = -EINVAL;
mem = container_of(dev, struct memory_block, sysdev);
- phys_section_nr = mem->phys_index;
-
- if (!present_section_nr(phys_section_nr))
- goto out;
if (!strncmp(buf, "online", min((int)count, 6)))
ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
else if(!strncmp(buf, "offline", min((int)count, 7)))
ret = memory_block_change_state(mem, MEM_OFFLINE, MEM_ONLINE);
-out:
+
if (ret)
return ret;
return count;
@@ -315,7 +347,7 @@
print_block_size(struct sysdev_class *class, struct sysdev_class_attribute *attr,
char *buf)
{
- return sprintf(buf, "%lx\n", (unsigned long)PAGES_PER_SECTION * PAGE_SIZE);
+ return sprintf(buf, "%lx\n", get_memory_block_size());
}
static SYSDEV_CLASS_ATTR(block_size_bytes, 0444, print_block_size, NULL);
@@ -451,12 +483,13 @@
struct sys_device *sysdev;
struct memory_block *mem;
char name[sizeof(MEMORY_CLASS_NAME) + 9 + 1];
+ int block_id = base_memory_block_id(__section_nr(section));
/*
* This only works because we know that section == sysdev->id
* slightly redundant with sysdev_register()
*/
- sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, __section_nr(section));
+ sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, block_id);
kobj = kset_find_obj(&memory_sysdev_class.kset, name);
if (!kobj)
@@ -468,26 +501,27 @@
return mem;
}
-static int add_memory_block(int nid, struct mem_section *section,
- unsigned long state, enum mem_add_context context)
+static int init_memory_block(struct memory_block **memory,
+ struct mem_section *section, unsigned long state)
{
- struct memory_block *mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+ struct memory_block *mem;
unsigned long start_pfn;
+ int scn_nr;
int ret = 0;
+ mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return -ENOMEM;
- mutex_lock(&mem_sysfs_mutex);
-
- mem->phys_index = __section_nr(section);
+ scn_nr = __section_nr(section);
+ mem->phys_index = base_memory_block_id(scn_nr) * sections_per_block;
mem->state = state;
mem->section_count++;
mutex_init(&mem->state_mutex);
start_pfn = section_nr_to_pfn(mem->phys_index);
mem->phys_device = arch_get_memory_phys_device(start_pfn);
- ret = register_memory(mem, section);
+ ret = register_memory(mem);
if (!ret)
ret = mem_create_simple_file(mem, phys_index);
if (!ret)
@@ -496,8 +530,29 @@
ret = mem_create_simple_file(mem, phys_device);
if (!ret)
ret = mem_create_simple_file(mem, removable);
+
+ *memory = mem;
+ return ret;
+}
+
+static int add_memory_section(int nid, struct mem_section *section,
+ unsigned long state, enum mem_add_context context)
+{
+ struct memory_block *mem;
+ int ret = 0;
+
+ mutex_lock(&mem_sysfs_mutex);
+
+ mem = find_memory_block(section);
+ if (mem) {
+ mem->section_count++;
+ kobject_put(&mem->sysdev.kobj);
+ } else
+ ret = init_memory_block(&mem, section, state);
+
if (!ret) {
- if (context == HOTPLUG)
+ if (context == HOTPLUG &&
+ mem->section_count == sections_per_block)
ret = register_mem_sect_under_node(mem, nid);
}
@@ -520,8 +575,10 @@
mem_remove_simple_file(mem, state);
mem_remove_simple_file(mem, phys_device);
mem_remove_simple_file(mem, removable);
- unregister_memory(mem, section);
- }
+ unregister_memory(mem);
+ kfree(mem);
+ } else
+ kobject_put(&mem->sysdev.kobj);
mutex_unlock(&mem_sysfs_mutex);
return 0;
@@ -533,7 +590,7 @@
*/
int register_new_memory(int nid, struct mem_section *section)
{
- return add_memory_block(nid, section, MEM_OFFLINE, HOTPLUG);
+ return add_memory_section(nid, section, MEM_OFFLINE, HOTPLUG);
}
int unregister_memory_section(struct mem_section *section)
@@ -552,12 +609,16 @@
unsigned int i;
int ret;
int err;
+ unsigned long block_sz;
memory_sysdev_class.kset.uevent_ops = &memory_uevent_ops;
ret = sysdev_class_register(&memory_sysdev_class);
if (ret)
goto out;
+ block_sz = get_memory_block_size();
+ sections_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
+
/*
* Create entries for memory sections that were found
* during boot and have been initialized
@@ -565,8 +626,8 @@
for (i = 0; i < NR_MEM_SECTIONS; i++) {
if (!present_section_nr(i))
continue;
- err = add_memory_block(0, __nr_to_section(i), MEM_ONLINE,
- BOOT);
+ err = add_memory_section(0, __nr_to_section(i), MEM_ONLINE,
+ BOOT);
if (!ret)
ret = err;
}
^ permalink raw reply
* Re: [PATCH 4/9] v3 Allow memory blocks to span multiple memory sections
From: Robin Holt @ 2010-10-01 18:52 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62917.80008@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:31:51PM -0500, Nathan Fontenot wrote:
> Update the memory sysfs code such that each sysfs memory directory is now
> considered a memory block that can span multiple memory sections per
> memory block. The default size of each memory block is SECTION_SIZE_BITS
> to maintain the current behavior of having a single memory section per
> memory block (i.e. one sysfs directory per memory section).
>
> For architectures that want to have memory blocks span multiple
> memory sections they need only define their own memory_block_size_bytes()
> routine.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
> ---
> drivers/base/memory.c | 155 ++++++++++++++++++++++++++++++++++----------------
> 1 file changed, 108 insertions(+), 47 deletions(-)
>
> Index: linux-next/drivers/base/memory.c
> ===================================================================
> --- linux-next.orig/drivers/base/memory.c 2010-09-30 14:13:50.000000000 -0500
> +++ linux-next/drivers/base/memory.c 2010-09-30 14:46:00.000000000 -0500
...
> +static unsigned long get_memory_block_size(void)
> +{
> + u32 block_sz;
^^^
I think this should be unsigned long. u32 will work, but everything
else has been changed to use unsigned long. If you disagree, I will
happily acquiesce as nothing is currently broken. If SGI decides to make
memory_block_size_bytes more dynamic, we will fix this up at that time.
Robin
^ permalink raw reply
* Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
From: Robin Holt @ 2010-10-01 18:56 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62A0A.4050406@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:35:54PM -0500, Nathan Fontenot wrote:
> Define a version of memory_block_size_bytes() for powerpc/pseries such that
> a memory block spans an entire lmb.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
^ permalink raw reply
* Re: [PATCH 6/9] v3 Update node sysfs code
From: Robin Holt @ 2010-10-01 18:55 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA629BA.60100@austin.ibm.com>
On Fri, Oct 01, 2010 at 01:34:34PM -0500, Nathan Fontenot wrote:
> Update the node sysfs code to be aware of the new capability for a memory
> block to contain multiple memory sections and be aware of the memory block
> structure name changes (start_section_nr). This requires an additional
> parameter to unregister_mem_sect_under_nodes so that we know which memory
> section of the memory block to unregister.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
^ permalink raw reply
* Re: [PATCH 4/9] v3 Allow memory blocks to span multiple memory sections
From: Robin Holt @ 2010-10-01 19:20 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <4CA62FE2.2000003@austin.ibm.com>
On Fri, Oct 01, 2010 at 02:00:50PM -0500, Nathan Fontenot wrote:
> Update the memory sysfs code such that each sysfs memory directory is now
> considered a memory block that can span multiple memory sections per
> memory block. The default size of each memory block is SECTION_SIZE_BITS
> to maintain the current behavior of having a single memory section per
> memory block (i.e. one sysfs directory per memory section).
>
> For architectures that want to have memory blocks span multiple
> memory sections they need only define their own memory_block_size_bytes()
> routine.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
^ permalink raw reply
* Re: [PATCH 15/18] mtd: Fix endianness issues from device tree
From: Artem Bityutskiy @ 2010-10-01 19:29 UTC (permalink / raw)
To: Ian Munsie
Cc: Jason Gunthorpe, Artem Bityutskiy, linuxppc-dev, linux-kernel,
H Hartley Sweeten, paulus, linux-mtd, Sean MacLennan, Tejun Heo,
Julia Lawall, Steve Deiters, Anatolij Gustschin, David Woodhouse,
David S. Miller
In-Reply-To: <1285916771-18033-16-git-send-email-imunsie@au1.ibm.com>
On Fri, 2010-10-01 at 17:06 +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> This patch adds the appropriate conversions to correct the endianness
> issues in the MTD driver whenever it accesses the device tree (which is
> always big endian).
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Pushed to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* [PATCH -mm] RapidIO: fix IDLE2 bits corruption
From: Alexandre Bounine @ 2010-10-01 19:55 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
RapidIO spec v.2.1 adds Idle Sequence 2 into LP-Serial Physical
Layer. The fix ensures that corresponding bits are not corrupted during
error handling.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Micha Nelissen <micha@neli.hopto.org>
---
drivers/rapidio/rio.c | 9 ++-------
include/linux/rio_regs.h | 3 +--
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index 7f18a65..68cf0c9 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -871,15 +871,10 @@ int rio_inb_pwrite_handler(union rio_pw_msg *pw_msg)
rdev->em_efptr + RIO_EM_LTL_ERR_DETECT, 0);
}
- /* Clear remaining error bits */
+ /* Clear remaining error bits and Port-Write Pending bit */
rio_mport_write_config_32(mport, destid, hopcount,
rdev->phys_efptr + RIO_PORT_N_ERR_STS_CSR(portnum),
- err_status & RIO_PORT_N_ERR_STS_CLR_MASK);
-
- /* Clear Port-Write Pending bit */
- rio_mport_write_config_32(mport, destid, hopcount,
- rdev->phys_efptr + RIO_PORT_N_ERR_STS_CSR(portnum),
- RIO_PORT_N_ERR_STS_PW_PEND);
+ err_status);
return 0;
}
diff --git a/include/linux/rio_regs.h b/include/linux/rio_regs.h
index a18b2e2..d63dcba 100644
--- a/include/linux/rio_regs.h
+++ b/include/linux/rio_regs.h
@@ -229,7 +229,7 @@
#define RIO_MNT_REQ_CMD_IS 0x04 /* Input-status command */
#define RIO_PORT_N_MNT_RSP_CSR(x) (0x0044 + x*0x20) /* 0x0002 */
#define RIO_PORT_N_MNT_RSP_RVAL 0x80000000 /* Response Valid */
-#define RIO_PORT_N_MNT_RSP_ASTAT 0x000003e0 /* ackID Status */
+#define RIO_PORT_N_MNT_RSP_ASTAT 0x000007e0 /* ackID Status */
#define RIO_PORT_N_MNT_RSP_LSTAT 0x0000001f /* Link Status */
#define RIO_PORT_N_ACK_STS_CSR(x) (0x0048 + x*0x20) /* 0x0002 */
#define RIO_PORT_N_ACK_CLEAR 0x80000000
@@ -243,7 +243,6 @@
#define RIO_PORT_N_ERR_STS_PORT_ERR 0x00000004
#define RIO_PORT_N_ERR_STS_PORT_OK 0x00000002
#define RIO_PORT_N_ERR_STS_PORT_UNINIT 0x00000001
-#define RIO_PORT_N_ERR_STS_CLR_MASK 0x07120204
#define RIO_PORT_N_CTL_CSR(x) (0x005c + x*0x20)
#define RIO_PORT_N_CTL_PWIDTH 0xc0000000
#define RIO_PORT_N_CTL_PWIDTH_1 0x00000000
--
1.7.3.1
^ permalink raw reply related
* RE: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Bounine, Alexandre @ 2010-10-01 20:46 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linux-kernel, Thomas Moll, Andrew Morton, linuxppc-dev
In-Reply-To: <4C97C6D8.4010407@neli.hopto.org>
Hi Micha,
Sorry for delayed reply.
Micha Nelissen <micha@neli.hopto.org> wrote:
>=20
> Bounine, Alexandre wrote:
> > struct rio_dev {
> > struct list_head global_list;
> > struct list_head net_list;
> > .....
> > ..... rest of rio_dev
> > .....
> > struct rio_switch switch[0];
> > }
>=20
> It makes sense to let rio_dev structures point to the switch they are
> attached to. That can be useful in various situations, but is not
> possible with this setup.
>=20
> If a rio_dev is a switch then rdev->rswitch->rdev =3D=3D rdev holds.
>
But the switch is a RIO device itself and all other parts of rio_dev
structure
are applicable to it as well. If there is situation when a device=20
needs to hold a pointer to the attached switch that should be a pointer
to the switch rio_dev and not to its switch-specific extension.=20
=20
> > This will remove extra memory allocation, remove overlapping
structure
> > members and clean code sections like one shown below:
> >
> > u8 hopcount =3D 0xff;
> > u16 destid =3D rdev->destid;
> >
> > if (rdev->rswitch) {
> > destid =3D rdev->rswitch->destid;
> > hopcount =3D rdev->rswitch->hopcount;
> > }
>=20
> Note that it is possible for rdev->destid to differ from
> rdev->rswitch->destid even if rswitch->rdev =3D=3D rdev (for non-hosts
i.e.
> agents). rswitch->destid is the destid by which we discovered the
switch
> (and can reach it) but rdev->destid is the actual id given to the
switch.
>=20
My goal is to have one destid storage for device - endpoint or switch.
And destid should be used only for one purpose: to reach corresponding
device.
In your statement above you suggest using rdev->destid instead of
rswitch->switchid.
RIO switches do not have any specific RIO ID that can be assigned to the
switch.
In this case the rswitch->switchid should work well for logical
identification
of the switch.
I think if (for switch) we load rdev->destid with some function
different
from its routing role this may bring unnecessary confusion.
I also will move rswitch->hopcount to rdev->hopcount. For endpoint it
will be set
to 0xff during rio_dev initialization.
Alex.
=20
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Benjamin Herrenschmidt @ 2010-10-01 20:50 UTC (permalink / raw)
To: Michel Dänzer; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie
In-Reply-To: <1285950041.15020.272.camel@thor.local>
On Fri, 2010-10-01 at 18:20 +0200, Michel Dänzer wrote:
> On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote:
> >
> > Now, the main reasons in practice are anything touching graphics.
> >
> > There's quite a few IP cores out there for SoCs that don't have HW
> > swappers, and -tons- of more or less ugly code that can't deal with non
> > native pixel ordering (hell, even Xorg isn't good at it, we really only
> > support cards that have HW swappers today).
>
> That's not true. Even the radeon driver doesn't really need the HW
> swappers anymore with KMS.
And last I looked X still pukes if you give it a pixmap in non native
byte order but that might have been fixed. In any case, X is far from
the target here. More like existing stacks for embedded SoCs, including
codecs etc... all written for LE.
> > There's an even bigger pile of application code that deals with graphics
> > without any regard for endianness and is essentially unfixable.
>
> Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL
> have well-defined semantics wrt endianness, allowing the drivers to
> handle any necessary byte swapping internally, and IME the vast majority
> of apps handle this correctly.
So why is it so hard to get any video card working on ppc ? :-) I
haven't even started to look at r6xx which -does- have HW swapping
capabilities...
In this case tho, see above. I don't even need to care much about the
details, customers are making the point over and over again. It might be
fixable, but either they don't have the resources to fix it or don't
want to fix it, or their -own- customers won't chose their product if
it's BE for "perceived" difficulty of porting reason, whether they are
valid or not.
So it boils down to do we want to be another Amiga sinking into oblivion
but keeping our purity intact, or do we make that "reasonably easy"
thing to support LE at least at the kernel level for now, and -possibly-
give powerpc a bit more juice on the market for a while longer ?
Cheers,
Ben.
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Benjamin Herrenschmidt @ 2010-10-01 20:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, Ian Munsie, linux-kernel
In-Reply-To: <BBD78246-343E-4A96-9E55-3E40AD628C0B@kernel.crashing.org>
On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
> I'm not against it, and I agree some of the patches seem like good
> clean up. I'm concerned about this bit rotting pretty quickly.
Maybe. Most of it doesn't seem to be that bit-rottable.
The changes to the asm stuff in misc_32.S for example are functions we
never ever touch once written (libgcc replacements) so I don't see them
rotting more with LE support than they did with BE :-)
What might rot is that we might introduce new LE breakage, true, and I
suppose it's going to be to some extent my job to at least every now and
then shoot that thing on a 44x to see if it still flies.
Cheers,
Ben.
^ permalink raw reply
* [patch 1/1] powerpc: enable ARCH_DMA_ADDR_T_64BIT with ARCH_PHYS_ADDR_T_64BIT
From: akpm @ 2010-10-01 21:12 UTC (permalink / raw)
To: benh; +Cc: fujita.tomonori, linuxppc-dev, akpm
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff -puN arch/powerpc/Kconfig~powerpc-enable-arch_dma_addr_t_64bit-with-arch_phys_addr_t_64bit arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig~powerpc-enable-arch_dma_addr_t_64bit-with-arch_phys_addr_t_64bit
+++ a/arch/powerpc/Kconfig
@@ -16,6 +16,9 @@ config WORD_SIZE
config ARCH_PHYS_ADDR_T_64BIT
def_bool PPC64 || PHYS_64BIT
+config ARCH_DMA_ADDR_T_64BIT
+ def_bool ARCH_PHYS_ADDR_T_64BIT
+
config MMU
bool
default y
_
^ permalink raw reply
* [RESEND PATCH 0/2] Fix IRQ round-robing w/o irqbalance on pseries
From: Nishanth Aravamudan @ 2010-10-01 21:26 UTC (permalink / raw)
To: nacc; +Cc: linuxppc-dev, linux-kernel, miltonm
We have received reports on power systems not running irqbalance where
all interrupts are being routed to CPU0 rather than being interleaved by
default across the system. Current firmware only allows either sending
interrupts to all CPUs or sending them to one CPU. The following two
patches address this issue by fixing the mask used in generic code and
by fixing the check for the "all" setting in the pseries code.
Nishanth Aravamudan (2):
IRQ: use cpu_possible_mask rather than online_mask in setup_affinity
pseries/xics: use cpu_possible_mask rather than cpu_all_mask
arch/powerpc/platforms/pseries/xics.c | 2 +-
kernel/irq/manage.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [RESEND PATCH 2/2] pseries/xics: use cpu_possible_mask rather than cpu_all_mask
From: Nishanth Aravamudan @ 2010-10-01 21:26 UTC (permalink / raw)
To: nacc
Cc: Mark Nelson, linux-kernel, miltonm, Paul Mackerras,
Anton Blanchard, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1285968378-12805-1-git-send-email-nacc@us.ibm.com>
Current firmware only allows us to send IRQs to the first processor or
all processors. We currently check to see if the passed in mask is equal
to the all_mask, but the firmware is only considering whether the
request is for the equivalent of the possible_mask. Thus, we think the
request is for some subset of CPUs and only assign IRQs to the first CPU
(on systems without irqbalance running) as evidenced by
/proc/interrupts. By using possible_mask instead, we account for this
and proper interleaving of interrupts occurs.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/pseries/xics.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 93834b0..7c1e342 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -178,7 +178,7 @@ static int get_irq_server(unsigned int virq, const struct cpumask *cpumask,
if (!distribute_irqs)
return default_server;
- if (!cpumask_equal(cpumask, cpu_all_mask)) {
+ if (!cpumask_subset(cpu_possible_mask, cpumask)) {
int server = cpumask_first_and(cpu_online_mask, cpumask);
if (server < nr_cpu_ids)
--
1.7.0.4
^ permalink raw reply related
* Re: Introduce support for little endian PowerPC
From: Olof Johansson @ 2010-10-01 22:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie
In-Reply-To: <1285966315.2463.141.camel@pasglop>
On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
> > I'm not against it, and I agree some of the patches seem like good
> > clean up. I'm concerned about this bit rotting pretty quickly.
>
> Maybe. Most of it doesn't seem to be that bit-rottable.
>
> The changes to the asm stuff in misc_32.S for example are functions we
> never ever touch once written (libgcc replacements) so I don't see them
> rotting more with LE support than they did with BE :-)
Does KVM/qemu support running LE guest on BE host? That'd help keeping
the bitrot lower. :)
-Olof
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Benjamin Herrenschmidt @ 2010-10-01 22:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie
In-Reply-To: <20101001220343.GA10494@lixom.net>
On Fri, 2010-10-01 at 17:03 -0500, Olof Johansson wrote:
> > Maybe. Most of it doesn't seem to be that bit-rottable.
> >
> > The changes to the asm stuff in misc_32.S for example are functions we
> > never ever touch once written (libgcc replacements) so I don't see them
> > rotting more with LE support than they did with BE :-)
>
> Does KVM/qemu support running LE guest on BE host? That'd help keeping
> the bitrot lower. :)
Not yet I suppose :-) But then, I'm not sure it would make a big
difference, if you have a 440 board in the first place, you can boot
either LE or BE, no need for a special FW or anything.
What we've done is basically keep the zImage wrapper BE (for now at
least), and have it trampoline to LE when executing the actual kernel
(using a cuImage, of course a device-tree enabled u-Boot would probably
need something akin to a proper ePAPR zImage to do that but that's
reasonably easy to do nowadays).
Cheers,
Ben.
^ permalink raw reply
* Serial RapidIO Maintaintance read causes lock up
From: Bastiaan Nijkamp @ 2010-10-01 22:35 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5023 bytes --]
Hi,
We are currently evaluating Serial RapidIO on two WindRiver SBC8548 boards
that use a Freescale Powerquicc III processor (MPC8548E rev. 2). We are
running U-Boot version 2010.09 as bootloader and are using kernel version
2.6.35.6 stable.
We have consulted multiple resources to collect al the requirements for
a successful RapidIO connection (LAW, TLB, Registers) and we seem to have
configured everything correctly. However, as soon as the board that is
configured as the host starts the enumeration process, the system locks up.
It locks in such a manner that we cannot use a JTAG interface to read any of
the registers. We have also added a breakpoint just before the command that
causes the lock up, to make sure the registers are correctly set at that
point, and it seems they are.
We have tripple checked everything that we could possibly think of and
everything seems to be configured as required but the system keeps
locking-up so there must be something that we are missing. I really hope
that someone could point us in the right direction. The lock-up occurs when
__fsl_read_rio_config is called by fsl_rio_config_read in fsl-rio.c.
The LAW and TLB entries we have added to U-Boot are as follows:
#define CONFIG_RIO 1
#define CONFIG_SYS_RIO_MEM_VIRT 0xc0000000 /* base address */
#define CONFIG_SYS_RIO_MEM_BUS 0xc0000000 /* base address */
#define CONFIG_SYS_RIO_MEM_PHYS 0xc0000000
#define CONFIG_SYS_RIO_MEM_SIZE 0x20000000 /* 512M */
SET_LAW(CONFIG_SYS_RIO_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
-------------
Here is the kernel log:
Using SBC8548 machine description
Memory CAM mapping: 256 Mb, residual: 0Mb
Linux version 2.6.35.6 (dl704@lxws006) (gcc version 4.1.2 (Wind River Linux
Sourcery G++ 4.1-91)) #7 We
d Sep 29 13:27:18 CEST 2010
bootconsole [udbg0] enabled
setup_arch: bootmem
sbc8548_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.100.21:/thales/target/rfs/sbc8548_wrlinux4
ip=192
.168.100.151:192.168.100.21:192.168.100.21:255.255.255.0:sbc8548_1:eth0:off
console=ttyS0,115200 riohdid=1
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256884k/262144k available (2712k kernel code, 5260k reserved, 112k
data, 77k bss, 144k init)
Kernel virtual memory layout:
* 0xfffdf000..0xfffff000 : fixmap
* 0xfc7f9000..0xfe000000 : early ioremap
* 0xd1000000..0xfc7f9000 : vmalloc & ioremap
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.
NR_IRQS:512 nr_irqs:512
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 80, shift: 7, mask: 7f
mpic: Initializing for 80 sources
clocksource: timebase mult[50cede6] shift[22] registered
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
bio: create slab <bio-0> at 0
vgaarb: loaded
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Setting up RapidIO peer-to-peer network /soc8548@e0000000/rapidio@c0000
fsl-of-rio e00c0000.rapidio: Of-device full name /soc8548@e0000000
/rapidio@c0000
fsl-of-rio e00c0000.rapidio: Regs: [mem 0xe00c0000-0xe00dffff]
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
0x0000000020000000.
fsl-of-rio e00c0000.rapidio: pwirq: 48, bellirq: 50, txirq: 53, rxirq 54
fsl-of-rio e00c0000.rapidio: DeviceID is 0x1
fsl-of-rio e00c0000.rapidio: Configured as HOST
fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial
fsl-of-rio e00c0000.rapidio: Hardware port width: 4
fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane
fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256
RIO: enumerate master port 0, RIO0 mport
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4
fsl_rio_config_read: Passed IS_ALIGNED.
fsl_rio_config_read: Passed 'out_be32_1'
fsl_rio_config_read: Passed 'out_be32_2'
fsl_rio_config_read: len is 4
fsl_rio_config_read: about to trigger '__fsl_read_rio_config'
Regards,
Bastiaan Nijkamp
[-- Attachment #2: Type: text/html, Size: 6059 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox