* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Grant Likely @ 2008-03-26 21:16 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul Mackerras, Anatolij Gustschin
In-Reply-To: <47EAB9CC.7060002@genesi-usa.com>
On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey <matt@genesi-usa.com> wrote:
> Bartlomiej Sieka wrote:
> > +
> > + phy0:ethernet-phy@0 {
> > + device_type = "ethernet-phy";@0"
> > + reg = <0>;
> > + };
>
> What's the parsing of this pan out to? What does it mean?
>
> Having colons in device names is totally contrary to OF device naming
> spec. Does the part after the colon have a special meaning to the DTC?
"phy0:" is a label used by dtc.
"ethernet-phy@0" is the node name.
>
> I also was under the impression that device_type was invalid in a DTS
> file, have we changed our minds again?
No, we haven't. It kind of sneaked back in for ethernet phys. I
don't know why.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 0/4] 16G huge page support for powerpc
From: Jon Tollefson @ 2008-03-26 21:20 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Adam Litke, Andi Kleen, Paul Mackerras
This patch set builds on Andi Kleen's patches for GB pages for hugetlb
posted on March 16th. This set adds support for 16G huge pages on
ppc64. Supporting multiple huge page sizes on ppc64 as defined in
Andi's patches is not a part of this set; that will be included in a
future patch.
The first patch here adds an arch callback since the 16G pages are not
allocated from bootmem. The 16G pages have to be reserved prior to
boot-time. The location of these pages are indicated in the device tree.
Support for 16G pages requires a POWER5+ or later machine and a little
bit of memory.
Jon
^ permalink raw reply
* [PATCH 1/4] allow arch specific function for allocating gigantic pages
From: Jon Tollefson @ 2008-03-26 21:24 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
Allow alloc_bm_huge_page() to be overridden by architectures that can't always use bootmem.
This requires huge_boot_pages to be available for use by this function. Also huge_page_size()
and other functions need to use a long so that they can handle the 16G page size.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
include/linux/hugetlb.h | 10 +++++++++-
mm/hugetlb.c | 21 +++++++++------------
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index a8de3c1..35a41be 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -35,6 +35,7 @@ void hugetlb_unreserve_pages(struct inode *inode, long offset, long freed);
extern unsigned long hugepages_treat_as_movable;
extern const unsigned long hugetlb_zero, hugetlb_infinity;
extern int sysctl_hugetlb_shm_group;
+extern struct list_head huge_boot_pages;
/* arch callbacks */
@@ -219,9 +220,15 @@ struct hstate {
unsigned int surplus_huge_pages_node[MAX_NUMNODES];
unsigned long parsed_hugepages;
};
+struct huge_bm_page {
+ struct list_head list;
+ struct hstate *hstate;
+};
void __init huge_add_hstate(unsigned order);
struct hstate *huge_lookup_hstate(unsigned long pagesize);
+/* arch callback */
+int alloc_bm_huge_page(struct hstate *h);
#ifndef HUGE_MAX_HSTATE
#define HUGE_MAX_HSTATE 1
@@ -248,7 +255,7 @@ static inline struct hstate *hstate_inode(struct inode *i)
return HUGETLBFS_I(i)->hstate;
}
-static inline unsigned huge_page_size(struct hstate *h)
+static inline unsigned long huge_page_size(struct hstate *h)
{
return PAGE_SIZE << h->order;
}
@@ -273,6 +280,7 @@ extern unsigned long sysctl_overcommit_huge_pages[HUGE_MAX_HSTATE];
#else
struct hstate {};
+#define alloc_bm_huge_page(h) NULL
#define hstate_file(f) NULL
#define hstate_vma(v) NULL
#define hstate_inode(i) NULL
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c28b8b6..a0017b0 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -27,6 +27,7 @@ unsigned long max_huge_pages[HUGE_MAX_HSTATE];
unsigned long sysctl_overcommit_huge_pages[HUGE_MAX_HSTATE];
static gfp_t htlb_alloc_mask = GFP_HIGHUSER;
unsigned long hugepages_treat_as_movable;
+struct list_head huge_boot_pages;
static int max_hstate = 1;
@@ -43,7 +44,8 @@ struct hstate *parsed_hstate __initdata = &global_hstate;
*/
static DEFINE_SPINLOCK(hugetlb_lock);
-static void clear_huge_page(struct page *page, unsigned long addr, unsigned sz)
+static void clear_huge_page(struct page *page, unsigned long addr,
+ unsigned long sz)
{
int i;
@@ -521,14 +523,8 @@ static __init char *memfmt(char *buf, unsigned long n)
return buf;
}
-static __initdata LIST_HEAD(huge_boot_pages);
-
-struct huge_bm_page {
- struct list_head list;
- struct hstate *hstate;
-};
-
-static int __init alloc_bm_huge_page(struct hstate *h)
+/* Can be overriden by architectures */
+__attribute__((weak)) int alloc_bm_huge_page(struct hstate *h)
{
struct huge_bm_page *m;
m = __alloc_bootmem_node_nopanic(NODE_DATA(h->hugetlb_next_nid),
@@ -614,6 +610,7 @@ static int __init hugetlb_init(void)
{
if (HPAGE_SHIFT == 0)
return 0;
+ INIT_LIST_HEAD(&huge_boot_pages);
return hugetlb_init_hstate(&global_hstate);
}
module_init(hugetlb_init);
@@ -866,7 +863,7 @@ int hugetlb_report_meminfo(char *buf)
n += dump_field(buf + n, offsetof(struct hstate, surplus_huge_pages));
n += sprintf(buf + n, "Hugepagesize: ");
for_each_hstate (h)
- n += sprintf(buf + n, " %5u", huge_page_size(h) / 1024);
+ n += sprintf(buf + n, " %5lu", huge_page_size(h) / 1024);
n += sprintf(buf + n, " kB\n");
return n;
}
@@ -947,7 +944,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
unsigned long addr;
int cow;
struct hstate *h = hstate_vma(vma);
- unsigned sz = huge_page_size(h);
+ unsigned long sz = huge_page_size(h);
cow = (vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
@@ -992,7 +989,7 @@ void __unmap_hugepage_range(struct vm_area_struct *vma, unsigned long start,
struct page *page;
struct page *tmp;
struct hstate *h = hstate_vma(vma);
- unsigned sz = huge_page_size(h);
+ unsigned long sz = huge_page_size(h);
/*
* A page gathering list, protected by per file i_mmap_lock. The
^ permalink raw reply related
* [PATCH 2/4] powerpc: function for allocating gigantic pages
From: Jon Tollefson @ 2008-03-26 21:26 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
The 16G page locations have been saved during early boot in an array. The
alloc_bm_huge_page() function adds a page from here to the huge_boot_pages list.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
hugetlbpage.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 94625db..31d977b 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -29,6 +29,10 @@
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
+#define MAX_NUMBER_GPAGES 1024
+
+static void *gpage_freearray[MAX_NUMBER_GPAGES];
+static unsigned nr_gpages;
unsigned int hugepte_shift;
#define PTRS_PER_HUGEPTE (1 << hugepte_shift)
@@ -104,6 +108,21 @@ pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr)
}
#endif
+/* Put 16G page address into temporary huge page list because the mem_map
+ * is not up yet.
+ */
+int alloc_bm_huge_page(struct hstate *h)
+{
+ struct huge_bm_page *m;
+ if (nr_gpages == 0)
+ return 0;
+ m = gpage_freearray[--nr_gpages];
+ list_add(&m->list, &huge_boot_pages);
+ m->hstate = h;
+ return 1;
+}
+
+
/* Modelled after find_linux_pte() */
pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
{
^ permalink raw reply related
* [PATCH 3/4] powerpc: scan device tree and save gigantic page locations
From: Jon Tollefson @ 2008-03-26 21:27 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
The 16G huge pages have to be reserved in the HMC prior to boot. The location of
the pages are placed in the device tree. During very early boot these locations are
saved for use by hugetlbfs.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 41 ++++++++++++++++++++++++++++++++++++++-
arch/powerpc/mm/hugetlbpage.c | 17 ++++++++++++++++
include/asm-powerpc/mmu-hash64.h | 2 +
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index a83dfa3..d3f7d92 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -67,6 +67,7 @@
#define KB (1024)
#define MB (1024*KB)
+#define GB (1024L*MB)
/*
* Note: pte --> Linux PTE
@@ -302,6 +303,41 @@ static int __init htab_dt_scan_page_sizes(unsigned long node,
return 0;
}
+/* Scan for 16G memory blocks that have been set aside for huge pages
+ * and reserve those blocks for 16G huge pages.
+ */
+static int __init htab_dt_scan_hugepage_blocks(unsigned long node,
+ const char *uname, int depth,
+ void *data) {
+ char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ unsigned long *lprop;
+ u32 *prop;
+
+ /* We are scanning "memory" nodes only */
+ if (type == NULL || strcmp(type, "memory") != 0)
+ return 0;
+
+ /* This property is the log base 2 of the number of virtual pages that
+ * will represent this memory block. */
+ prop = of_get_flat_dt_prop(node, "ibm,expected#pages", NULL);
+ if (prop == NULL)
+ return 0;
+ unsigned int expected_pages = (1 << prop[0]);
+ lprop = of_get_flat_dt_prop(node, "reg", NULL);
+ if (lprop == NULL)
+ return 0;
+ long unsigned int phys_addr = lprop[0];
+ long unsigned int block_size = lprop[1];
+ if (block_size != (16 * GB))
+ return 0;
+ printk(KERN_INFO "Reserving huge page memory "
+ "addr = 0x%lX size = 0x%lX pages = %d\n",
+ phys_addr, block_size, expected_pages);
+ lmb_reserve(phys_addr, block_size * expected_pages);
+ add_gpage(phys_addr, block_size, expected_pages);
+ return 0;
+}
+
static void __init htab_init_page_sizes(void)
{
int rc;
@@ -370,7 +406,10 @@ static void __init htab_init_page_sizes(void)
mmu_psize_defs[mmu_io_psize].shift);
#ifdef CONFIG_HUGETLB_PAGE
- /* Init large page size. Currently, we pick 16M or 1M depending
+ /* Reserve 16G huge page memory sections for huge pages */
+ of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
+
+/* Init large page size. Currently, we pick 16M or 1M depending
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 31d977b..44d3d55 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -108,6 +108,23 @@ pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr)
}
#endif
+/* Build list of addresses of gigantic pages. This function is used in early
+ * boot before the buddy allocator is setup.
+ */
+void add_gpage(unsigned long addr, unsigned long page_size,
+ unsigned long number_of_pages)
+{
+ if (addr) {
+ while (number_of_pages > 0) {
+ gpage_freearray[nr_gpages] = __va(addr);
+ nr_gpages++;
+ number_of_pages--;
+ addr += page_size;
+ }
+ }
+}
+
+
/* Put 16G page address into temporary huge page list because the mem_map
* is not up yet.
*/
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 2864fa3..db1276a 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -279,6 +279,8 @@ extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
extern void set_huge_psize(int psize);
+extern void add_gpage(unsigned long addr, unsigned long page_size,
+ unsigned long number_of_pages);
extern void demote_segment_4k(struct mm_struct *mm, unsigned long addr);
extern void htab_initialize(void);
^ permalink raw reply related
* [PATCH 4/4] powerpc: define page support for 16G pages
From: Jon Tollefson @ 2008-03-26 21:29 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
The huge page size is setup for 16G pages if that size is specified at boot-time. The support for
multiple huge page sizes is not being utilized yet. That will be in a future patch.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
hugetlbpage.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 44d3d55..b6a02b7 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -26,6 +26,7 @@
#define HPAGE_SHIFT_64K 16
#define HPAGE_SHIFT_16M 24
+#define HPAGE_SHIFT_16G 34
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
@@ -589,9 +590,11 @@ void set_huge_psize(int psize)
{
/* Check that it is a page size supported by the hardware and
* that it fits within pagetable limits. */
- if (mmu_psize_defs[psize].shift && mmu_psize_defs[psize].shift < SID_SHIFT &&
+ if (mmu_psize_defs[psize].shift &&
+ mmu_psize_defs[psize].shift < SID_SHIFT_1T &&
(mmu_psize_defs[psize].shift > MIN_HUGEPTE_SHIFT ||
- mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K ||
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_16G)) {
HPAGE_SHIFT = mmu_psize_defs[psize].shift;
mmu_huge_psize = psize;
#ifdef CONFIG_PPC_64K_PAGES
@@ -599,6 +602,8 @@ void set_huge_psize(int psize)
#else
if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+ else if (HPAGE_SHIFT == HPAGE_SHIFT_16G)
+ hugepte_shift = (PGDIR_SHIFT-HPAGE_SHIFT);
else
hugepte_shift = (PUD_SHIFT-HPAGE_SHIFT);
#endif
@@ -625,6 +630,9 @@ static int __init hugepage_setup_sz(char *str)
case HPAGE_SHIFT_16M:
mmu_psize = MMU_PAGE_16M;
break;
+ case HPAGE_SHIFT_16G:
+ mmu_psize = MMU_PAGE_16G;
+ break;
}
if (mmu_psize >=0 && mmu_psize_defs[mmu_psize].shift)
^ permalink raw reply related
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Bartlomiej Sieka @ 2008-03-26 21:32 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <47EAB687.5040702@grandegger.com>
Wolfgang Grandegger wrote:
> Grant Likely wrote:
>> On Wed, Mar 26, 2008 at 1:45 PM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>>> The bulk of this patch is taken from
>>> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
>>> other updates.
>>>
>>> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
>>> ---
>>> Addressed comments from the list; would appreciate picking up as the patch
>>> fixes booting issue on TQM5200 and Motion-PRO (cm5200 changes are analogous,
>>> but not tested due to hardware unavailability).
>> I see one obvious error; but other than that it looks good. Once that
>> is fixed I can recommend for Paul to pick it up for .25. It's just
>> dts changes, so I don't expect it to be a problem.
>>
>> Cheers,
[...]
> And whats about the two CAN nodes for tqm5200.dts? Do we have them already?
Hello Wolfgang,
patchwork shows your updates as "Awaiting Upstream"
(http://patchwork.ozlabs.org/linuxppc/patch?q=Grandegger&id=17444), so I
haven't included them in my patch. I suppose you should follow-up with
Grant/Paulus on the status?
Regards,
Bartlomiej
^ permalink raw reply
* Re: [PATCH 0/4] 16G huge page support for powerpc
From: Andi Kleen @ 2008-03-26 21:47 UTC (permalink / raw)
To: Jon Tollefson
Cc: npiggin, Adam Litke, linuxppc-dev, linux-kernel,
Linux Memory Management List, Andi Kleen, Paul Mackerras
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
FWIW i turned over the hugepages patchkit to Nick Piggin. So send
all future patches to him please.
-Andi
^ permalink raw reply
* Re: ppc platform for AMCC-440EPx - ELDK to the rescue
From: Wolfgang Denk @ 2008-03-26 22:22 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080326130837.762DBDE2FB@ozlabs.org>
In message <20080326130837.762DBDE2FB@ozlabs.org> you wrote:
> I finally resolved my nightmare of getting linux-2.6.24/5... to work
> on my AMCC-440Epx - Sequoia spinoff board. Following a clue I derived
> from a reply from Wolfgang Denx, I went to the DENX Engineering site
> where I discoved and downloaded the ELDK for the ppc_4xxFP. the ELDK
> uses the ppc platform instead of the powerpc platform. FINALLY the
This is not exactly correct. Actually it supports both.
> Also, I fail to see what the DTS virtualization layer of the hardware
> buys us. When debugging, it's so much harder to use than the ppc
> platform's straight forward and standard methodologies. I can't
> understand to goal to eliminate the ppc platform, especially given
> the fact that DENX's ELDK is still using it with Linux 2.6.24.2 !!
You miss the fact that the ELDK has full support for arch/powerpc,
and that some board configurations in our kernel (for example, all
MPC5200 based ones) are available in arch/powerpc configurations
only.
But then - what's the difference? All it takes is a redefinition of
the ARCH envrionment variable in your shell...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I've got a bad feeling about this.
^ permalink raw reply
* Re: dtc: Trivial formatting fixes
From: David Gibson @ 2008-03-26 22:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JeVTb-0005tQ-Ae@jdl.com>
On Wed, Mar 26, 2008 at 08:15:35AM -0500, Jon Loeliger wrote:
> > This patch fixes some trivial indentation and brace/bracket style
> > problems.
>
>
> > @@ -179,9 +179,8 @@
> > arg = argv[optind];
> >
> > /* minsize and padsize are mutually exclusive */
> > - if ((minsize) && (padsize)) {
> > + if (minsize && padsize)
> > die("Can't set both -p and -S\n");
> > - }
>
>
> I do not consider extra braces a "problem", and will
> not be applying those changes. The other indentation
> fixes will be applied, of course.
Meh, whatever. Usual kernel style - which is what I originally
adopted for dtc - says no braces for one line blocks.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/4] allow arch specific function for allocating gigantic pages
From: Andi Kleen @ 2008-03-26 21:49 UTC (permalink / raw)
To: Jon Tollefson
Cc: npiggin, Adam Litke, linuxppc-dev, linux-kernel,
Linux Memory Management List, Andi Kleen, Paul Mackerras
In-Reply-To: <47EABF09.6090302@linux.vnet.ibm.com>
Haven't reviewed it in detail, just noticed something.
> @@ -614,6 +610,7 @@ static int __init hugetlb_init(void)
> {
> if (HPAGE_SHIFT == 0)
> return 0;
> + INIT_LIST_HEAD(&huge_boot_pages);
> return hugetlb_init_hstate(&global_hstate);
I don't think adding the INIT_LIST_HEAD here is correct. There can
be huge pages added by the __setup handlers before hugetlb_init
-Andi
^ permalink raw reply
* Re: [PATCH] scanlog_init cleanup, minor fixes
From: Michael Ellerman @ 2008-03-26 22:40 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080323225144.GA7137@localdomain>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
On Sun, 2008-03-23 at 17:51 -0500, Nathan Lynch wrote:
> scanlog_init() could use some love.
> diff --git a/arch/powerpc/platforms/pseries/scanlog.c b/arch/powerpc/platforms/pseries/scanlog.c
> index 8e1ef16..e5b0ea8 100644
> --- a/arch/powerpc/platforms/pseries/scanlog.c
> +++ b/arch/powerpc/platforms/pseries/scanlog.c
> @@ -195,31 +195,30 @@ const struct file_operations scanlog_fops = {
> static int __init scanlog_init(void)
> {
> struct proc_dir_entry *ent;
> + void *data;
> + int err = -ENOMEM;
>
> ibm_scan_log_dump = rtas_token("ibm,scan-log-dump");
> - if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE) {
> - printk(KERN_ERR "scan-log-dump not implemented on this system\n");
> - return -EIO;
> - }
> + if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE)
> + return -ENODEV;
>
> - ent = create_proc_entry("ppc64/rtas/scan-log-dump", S_IRUSR, NULL);
> - if (ent) {
> - ent->proc_fops = &scanlog_fops;
> - /* Ideally we could allocate a buffer < 4G */
> - ent->data = kmalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
> - if (!ent->data) {
> - printk(KERN_ERR "Failed to allocate a buffer\n");
> - remove_proc_entry("scan-log-dump", ent->parent);
> - return -ENOMEM;
> - }
> - ((unsigned int *)ent->data)[0] = 0;
> - } else {
> - printk(KERN_ERR "Failed to create ppc64/scan-log-dump proc entry\n");
> - return -EIO;
> - }
> + /* Ideally we could allocate a buffer < 4G */
> + data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
> + if (!data)
> + goto err;
Not your bug, but what happens if data is > 4G? Kaboom?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
From: Kumar Gala @ 2008-03-26 22:44 UTC (permalink / raw)
To: linuxppc-dev
Now that we have a proper variable that is the address of the top
of low memory we can use it to limit the lmb allocations.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
include/asm-powerpc/lmb.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h
index 028184b..6f5fdf0 100644
--- a/include/asm-powerpc/lmb.h
+++ b/include/asm-powerpc/lmb.h
@@ -6,8 +6,8 @@
#define LMB_DBG(fmt...) udbg_printf(fmt)
#ifdef CONFIG_PPC32
-extern unsigned long __max_low_memory;
-#define LMB_REAL_LIMIT __max_low_memory
+extern phys_addr_t lowmem_end_addr;
+#define LMB_REAL_LIMIT lowmem_end_addr
#else
#define LMB_REAL_LIMIT 0
#endif
--
1.5.4.1
^ permalink raw reply related
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: David Gibson @ 2008-03-26 22:51 UTC (permalink / raw)
To: Grant Likely; +Cc: Anatolij Gustschin, Paul Mackerras, linuxppc-dev
In-Reply-To: <fa686aa40803261416s38164c98ua774731eadc1f85f@mail.gmail.com>
On Wed, Mar 26, 2008 at 03:16:47PM -0600, Grant Likely wrote:
> On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey <matt@genesi-usa.com> wrote:
> > Bartlomiej Sieka wrote:
> > > +
> > > + phy0:ethernet-phy@0 {
> > > + device_type = "ethernet-phy";@0"
> > > + reg = <0>;
> > > + };
> >
> > What's the parsing of this pan out to? What does it mean?
> >
> > Having colons in device names is totally contrary to OF device naming
> > spec. Does the part after the colon have a special meaning to the DTC?
>
> "phy0:" is a label used by dtc.
> "ethernet-phy@0" is the node name.
I would suggest a space after the colon though, to make this clearer.
That's the style I've been using in all my dts files.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
From: Kumar Gala @ 2008-03-26 22:47 UTC (permalink / raw)
To: linuxppc-dev
We always use __initial_memory_limit as an address so rename it
to be clear.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/init_32.c | 10 +++++-----
arch/powerpc/mm/mmu_decl.h | 2 +-
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index 59f6649..ada249b 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -227,5 +227,5 @@ adjust_total_lowmem(void)
__cam0 >> 20, __cam1 >> 20, __cam2 >> 20,
(total_lowmem - __cam0 - __cam1 - __cam2) >> 20);
__max_low_memory = __cam0 + __cam1 + __cam2;
- __initial_memory_limit = memstart_addr + __max_low_memory;
+ __initial_memory_limit_addr = memstart_addr + __max_low_memory;
}
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 345a275..555bb7e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -96,10 +96,10 @@ int __map_without_ltlbs;
unsigned long __max_low_memory = MAX_LOW_MEM;
/*
- * limit of what is accessible with initial MMU setup -
+ * address of the limit of what is accessible with initial MMU setup -
* 256MB usually, but only 16MB on 601.
*/
-unsigned long __initial_memory_limit = 0x10000000;
+unsigned long __initial_memory_limit_addr = 0x10000000;
/*
* Check for command-line options that affect what MMU_init will do.
@@ -132,10 +132,10 @@ void __init MMU_init(void)
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
- __initial_memory_limit = 0x01000000;
+ __initial_memory_limit_addr = 0x01000000;
/* 8xx can only access 8MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 0x50)
- __initial_memory_limit = 0x00800000;
+ __initial_memory_limit_addr = 0x00800000;
/* parse args from command line */
MMU_setup();
@@ -210,7 +210,7 @@ void __init *early_get_page(void)
p = alloc_bootmem_pages(PAGE_SIZE);
} else {
p = __va(lmb_alloc_base(PAGE_SIZE, PAGE_SIZE,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
}
return p;
}
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 67477e7..0480225 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -48,7 +48,7 @@ extern unsigned int num_tlbcam_entries;
extern unsigned long ioremap_bot;
extern unsigned long __max_low_memory;
-extern unsigned long __initial_memory_limit;
+extern phys_addr_t __initial_memory_limit_addr;
extern unsigned long total_memory;
extern unsigned long total_lowmem;
extern phys_addr_t memstart_addr;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 7dea68b..12b6a46 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -234,7 +234,7 @@ void __init MMU_init_hw(void)
*/
if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
Hash = __va(lmb_alloc_base(Hash_size, Hash_size,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
cacheable_memzero(Hash, Hash_size);
_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH 4/5] i2c: MPC837xRDB Power Management and GPIO expander driver
From: Anton Vorontsov @ 2008-03-26 22:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, i2c
In-Reply-To: <47EAB885.7000006@freescale.com>
On Wed, Mar 26, 2008 at 03:56:37PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> > +config MCU_MPC837XRDB
> > + tristate "MPC837XRDB MCU driver"
> > + depends on I2C && MPC837x_RDB && OF_GPIO
>
> The MPC8349E-mITX also has this chip. Can you include support for that board as
> well?
Well, only if it has the same (or compatible) firmware.. then yes.
Thanks for the info, I'll look into this.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Matt Sealey @ 2008-03-26 22:57 UTC (permalink / raw)
To: Grant Likely, Matt Sealey, linuxppc-dev, Paul Mackerras,
Anatolij Gustschin
In-Reply-To: <20080326225128.GB5777@localhost.localdomain>
David Gibson wrote:
> On Wed, Mar 26, 2008 at 03:16:47PM -0600, Grant Likely wrote:
>> On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey <matt@genesi-usa.com> wrote:
>>> Bartlomiej Sieka wrote:
>>> > +
>>> > + phy0:ethernet-phy@0 {
>>> > + device_type = "ethernet-phy";@0"
>>> > + reg = <0>;
>>> > + };
>>>
>>> What's the parsing of this pan out to? What does it mean?
>>>
>>> Having colons in device names is totally contrary to OF device naming
>>> spec. Does the part after the colon have a special meaning to the DTC?
>> "phy0:" is a label used by dtc.
>> "ethernet-phy@0" is the node name.
>
> I would suggest a space after the colon though, to make this clearer.
> That's the style I've been using in all my dts files.
I would suggest taking a hint from C structures...
ethernet-phy@0 {
name = "ethernet-phy";
reg = <0>;
foo = bar;
} phy0;
I mean, this is really intuitive, we all do this every day...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 3/5] leds: implement OpenFirmare GPIO LEDs driver
From: Anton Vorontsov @ 2008-03-26 23:07 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Richard Purdie
In-Reply-To: <47EABA4B.1000105@genesi-usa.com>
On Wed, Mar 26, 2008 at 09:04:11PM +0000, Matt Sealey wrote:
> Can someone throw me a link to the GPIO spec being implemented here (yes,
> I would like docs too!) or a pointer to the relevant DTS which implements
> it?
>
> Supporting GPIO in the device tree is something that has been undefined
> for ages, and I seem to not be able to find the supporting DTS patches for
> this implementation in patchwork..??
Here the last respin starts:
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052881.html
> Grant Likely wrote:
>> On Wed, Mar 26, 2008 at 2:24 PM, Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>>> Despite leds-gpio and leds-of-gpio similar names and purposes, there
>>> is actually very few code can be shared between the two (both drivers
>>> are mostly the driver bindings anyway).
>>>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>
>> Other than the fact that it needs some documentation of the binding in
>> booting-without-of.txt, it looks pretty good to me.
Thanks, will document it.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] scanlog_init cleanup, minor fixes
From: Nathan Lynch @ 2008-03-26 23:09 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1206571210.7482.0.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> > + /* Ideally we could allocate a buffer < 4G */
> > + data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
> > + if (!data)
> > + goto err;
>
> Not your bug, but what happens if data is > 4G? Kaboom?
An old RPA doc (scan-log-dump isn't specified in PAPR) says the buffer
should be "contiguous real storage", so... yeah, probably. That's why
I preserved the comment. Will fix if I get access to a machine to
test this code more thoroughly (plenty of other issues in this file,
too).
^ permalink raw reply
* Re: [PATCH] scanlog_init cleanup, minor fixes
From: Michael Ellerman @ 2008-03-26 23:21 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080326230959.GI7137@localdomain>
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
On Wed, 2008-03-26 at 18:09 -0500, Nathan Lynch wrote:
> Michael Ellerman wrote:
> > > + /* Ideally we could allocate a buffer < 4G */
> > > + data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
> > > + if (!data)
> > > + goto err;
> >
> > Not your bug, but what happens if data is > 4G? Kaboom?
>
> An old RPA doc (scan-log-dump isn't specified in PAPR) says the buffer
> should be "contiguous real storage", so... yeah, probably. That's why
> I preserved the comment. Will fix if I get access to a machine to
> test this code more thoroughly (plenty of other issues in this file,
> too).
Cool, no point changing it if we can't test it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Which Kernel for Ocotea (440GX)?
From: Wolfgang Wegner @ 2008-03-26 23:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20080325224533.97BF3243A7@gemini.denx.de>
Hi Wolfgang,
On Tue, Mar 25, 2008 at 11:45:33PM +0100, Wolfgang Denk wrote:
>
> You can find Ocotea support (still arch/ppc only) in our kenrel
> repository - see git://www.denx.de/git/linux-2.6-denx.git
>
> I think if you just followed the links on AMCC's web site they should
> have taken you there, too. Please let me know if this didn't work for
> some reason.
thank you very much, I fetched the kernel and at least it built
correctly.
It seems I am still doing something wrong with configuration, but as
I am getting this far, it should be possible to solve. I just wanted
to give feedback in time that the build is OK.
Thank you and best regards,
Wolfgang
At the moment this is what I get:
=> bootm 0x400000
## Booting image at 00400000 ...
Image Name: Linux
Created: 2008-03-26 23:12:26 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1428044 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
^ permalink raw reply
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: David Gibson @ 2008-03-26 23:28 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <47EAD4DA.5050907@genesi-usa.com>
On Wed, Mar 26, 2008 at 10:57:30PM +0000, Matt Sealey wrote:
> David Gibson wrote:
>> On Wed, Mar 26, 2008 at 03:16:47PM -0600, Grant Likely wrote:
>>> On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey <matt@genesi-usa.com> wrote:
>>>> Bartlomiej Sieka wrote:
>>>> > +
>>>> > + phy0:ethernet-phy@0 {
>>>> > + device_type = "ethernet-phy";@0"
>>>> > + reg = <0>;
>>>> > + };
>>>>
>>>> What's the parsing of this pan out to? What does it mean?
>>>>
>>>> Having colons in device names is totally contrary to OF device naming
>>>> spec. Does the part after the colon have a special meaning to the DTC?
>>> "phy0:" is a label used by dtc.
>>> "ethernet-phy@0" is the node name.
>> I would suggest a space after the colon though, to make this clearer.
>> That's the style I've been using in all my dts files.
>
> I would suggest taking a hint from C structures...
>
> ethernet-phy@0 {
> name = "ethernet-phy";
> reg = <0>;
> foo = bar;
> } phy0;
>
> I mean, this is really intuitive, we all do this every day...
That's a terrible analogy though. The OF name is in no way like a
structure's type, which is what would go there. Plus it separates the
label from the top of the node which will make it harder to read.
The label syntax is already based on C labels, and can be used more
places than just nodes. Putting a space should make it rather
clearer, and is also closer to normal C style (how many people would
write
out:return(err);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: David Gibson @ 2008-03-26 23:37 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ben, linux-mtd, linuxppc-dev
In-Reply-To: <777c028aa41fe870542afdb4fa7d2db6@kernel.crashing.org>
On Wed, Mar 26, 2008 at 04:34:58PM +0100, Segher Boessenkool wrote:
>>>> {
>>>> + .compatible = "physmap-ram",
>>>> + .data = (void *)"map_ram",
>>>> + },
>>>> + {
>>>> + .compatible = "physmap-rom",
>>>> + .data = (void *)"map_rom",
>>>> + },
>>
>>> Why the cast? It's redundant afaics.
>>
>> To be in line with the surrounding code...
>
> I see _that_, but it's not a great argument IMNSHO. Could I trick
> you into preceding this patch with a cleanup patch for the existing
> casts?
Hrm. Much as I generally dislike redundant casts, these ones do serve
to inform the reader that the data field is not always a string, which
they might otherwise assume.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: DTS question
From: David Gibson @ 2008-03-26 23:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Scott Wood, linuxppc-dev, Sean MacLennan
In-Reply-To: <f789af657dc6001f6337218db90825c5@kernel.crashing.org>
On Wed, Mar 26, 2008 at 04:32:28PM +0100, Segher Boessenkool wrote:
>>>> Well.. stock ticker is the new convention. IEEE1275 used IEEE
>>>> assigned OUI strings (Organization Unique Identifiers). Often those
>>>> are the same as the stock ticker, but not always.
>>>
>>> Erm, an OUI is a 24-bit number. I think you're confusing something
>>> here.
>>
>> Yes, I think I am. I somehow had the impression that in addition to
>> the 24-bit OUIs used in MAC addresses, there were also string-form
>> OUIs assigned.
>
> Perhaps, I'm not an expert on this organisational stuff (wow, big
> understatement). OF uses only the six-hex-digit form though (with
> a prepended 0, to make it unique).
>
>>> Note that a stock symbol needs to be written in uppercase; in lowercase,
>>> it is just a random name that has no collision protection.
>>
>> Um.. bit too late for that. AFAIK, uppercase has been used by
>> *no-one* for stock ticker derived vendor IDs.
>
> No, it's used quite a lot actually. Not in DTS files though ;-)
Sorry, yes, I was meaning specifically in recent, flattened-device
tree practice (which is the context in which the "use stock ticker"
recommendation has been made.
> It doesn't matter a lot, lowercase names are perfectly valid, you just
> don't get the nice non-collision reassurance you would get if you used
> a name in one of the namespaces reserved for that purpose.
>
> It's probably best to not use an uppercase stock symbol if you don't
> have approval from the company in question anyway -- we use a
> lowercase name (i.e. in the "free-for-all" space) for our messed up
> bindings, the companies use an uppercase name (in the stock-ticker
> namespace) for their own, incompatible, messed-up bindings, and
> everyone is happy. Or something like that.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Which Kernel for Ocotea (440GX)? - working now
From: Wolfgang Wegner @ 2008-03-26 23:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20080325224533.97BF3243A7@gemini.denx.de>
Hi again,
sorry for the confusion, I forgot to activate the serial console support,
now the kernel is booting up fine until it tries to mount the root
fs.
Thanks again,
Wolfgang
^ 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