Re: [PATCH] powerpc: Check for unsupported relocs when using CONFIG_RELOCATABLE
On Tue, Sep 15, 2009 at 03:57:02PM +1000, Benjamin Herrenschmidt wrote:
diff --git a/arch/powerpc/relocs_check.pl b/arch/powerpc/relocs_check.pl
new file mode 100755
index 000..215e966
--- /dev/null
+++ b/arch/powerpc/relocs_check.pl
@@ -0,0 +1,57 @@
+#!/usr/bin/perl
+
+# Copyright © 2009 IBM Corporation
+
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version
+# 2 of the License, or (at your option) any later version.
+
+# This script checks the relcoations of a vmlinux for suspicious
+# relocations.
+
+use strict;
+use warnings;
+
+if ($#ARGV != 1) {
+ print $#ARGV\n;
Ooops that line should have been taken out. Sorry.
Yours Tony
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[0/5] Assorted hugepage cleanups (v2)
Currently, ordinary pages use one pagetable layout, and each different hugepage size uses a slightly different variant layout. A number of places which need to walk the pagetable must first check the slice map to see what the pagetable layout then handle the various different forms. New hardware, like Book3E is liable to introduce more possible variants. This patch series, therefore, is designed to simplify the matter by limiting knowledge of the pagetable layout to only the allocation path. With this patch, ordinary pages are handled as ever, with a fixed 4 (or 3) level tree. All other variants branch off from some layer of that with a specially marked PGD/PUD/PMD pointer which also contains enough information to interpret the directories below that point. This means that things walking the pagetables (without allocating) don't need to look up the slice map, they can just step down the tree in the usual way, branching off to the non-standard layout path for hugepages, which uses the embdded information to interpret the tree from that point on. This reduces the source size in a number of places, and means that newer variants on the pagetable layout to handle new hardware and new features will need to alter the existing code in less places. In addition we split out the hash / classic MMU specific code into a separate hugetlbpage-hash64.c file. This will make adding support for other MMUs (like 440 and/or Book3E) easier. I've used the libhugetlbfs testsuite to test these patches on a Power5+ machine, but they could certainly do with more testing. In particular, I don't have any suitable hardware to test 16G pages. V2: Made the tweaks that BenH suggested to patch 2 of the original series. Some corresponding tweaks in patch 3 to match. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[2/5] Cleanup management of kmem_caches for pagetables
Currently we have a fair bit of rather fiddly code to manage the
various kmem_caches used to store page tables of various levels. We
generally have two caches holding some combination of PGD, PUD and PMD
tables, plus several more for the special hugepage pagetables.
This patch cleans this all up by taking a different approach. Rather
than the caches being designated as for PUDs or for hugeptes for 16M
pages, the caches are simply allocated to be a specific size. Thus
sharing of caches between different types/levels of pagetables happens
naturally. The pagetable size, where needed, is passed around encoded
in the same way as {PGD,PUD,PMD}_INDEX_SIZE; that is n where the
pagetable contains 2^n pointers.
Signed-off-by: David Gibson d...@au1.ibm.com
---
arch/powerpc/include/asm/pgalloc-64.h| 51 +++
arch/powerpc/include/asm/pgalloc.h | 30 ++
arch/powerpc/include/asm/pgtable-ppc64.h |1
arch/powerpc/mm/hugetlbpage.c| 45 +++
arch/powerpc/mm/init_64.c| 51 ++-
arch/powerpc/mm/pgtable.c| 25 +--
6 files changed, 89 insertions(+), 114 deletions(-)
Index: working-2.6/arch/powerpc/mm/init_64.c
===
--- working-2.6.orig/arch/powerpc/mm/init_64.c 2009-08-14 16:07:54.0
+1000
+++ working-2.6/arch/powerpc/mm/init_64.c 2009-09-15 16:03:27.0
+1000
@@ -148,30 +148,39 @@ static void pmd_ctor(void *addr)
memset(addr, 0, PMD_TABLE_SIZE);
}
-static const unsigned int pgtable_cache_size[2] = {
- PGD_TABLE_SIZE, PMD_TABLE_SIZE
-};
-static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
-#ifdef CONFIG_PPC_64K_PAGES
- pgd_cache, pmd_cache,
-#else
- pgd_cache, pud_pmd_cache,
-#endif /* CONFIG_PPC_64K_PAGES */
-};
-
-#ifdef CONFIG_HUGETLB_PAGE
-/* Hugepages need an extra cache per hugepagesize, initialized in
- * hugetlbpage.c. We can't put into the tables above, because HPAGE_SHIFT
- * is not compile time constant. */
-struct kmem_cache
*pgtable_cache[ARRAY_SIZE(pgtable_cache_size)+MMU_PAGE_COUNT];
-#else
-struct kmem_cache *pgtable_cache[ARRAY_SIZE(pgtable_cache_size)];
-#endif
+struct kmem_cache *pgtable_cache[MAX_PGTABLE_INDEX_SIZE];
+
+void pgtable_cache_add(unsigned shift, void (*ctor)(void *))
+{
+ char *name;
+ unsigned long table_size = sizeof(void *) shift;
+ unsigned long align = table_size;
+ /* When batching pgtable pointers for RCU freeing, we store
+* the index size in the low bits. Table alignment must be
+* big enough to fit it */
+ unsigned long minalign = MAX_PGTABLE_INDEX_SIZE + 1;
+ struct kmem_cache *new;
+
+ BUILD_BUG_ON(!is_power_of_2(minalign));
+ BUG_ON((shift 1) || (shift MAX_PGTABLE_INDEX_SIZE));
+
+ if (PGT_CACHE(shift))
+ return; /* Already have a cache of this size */
+ align = max_t(unsigned long, align, minalign);
+ name = kasprintf(GFP_KERNEL, pgtable-2^%d, shift);
+ new = kmem_cache_create(name, table_size, table_size, 0, ctor);
+ PGT_CACHE(shift) = new;
+ pr_debug(Allocated pgtable cache for order %d\n, shift);
+}
+
void pgtable_cache_init(void)
{
- pgtable_cache[0] = kmem_cache_create(pgtable_cache_name[0],
PGD_TABLE_SIZE, PGD_TABLE_SIZE, SLAB_PANIC, pgd_ctor);
- pgtable_cache[1] = kmem_cache_create(pgtable_cache_name[1],
PMD_TABLE_SIZE, PMD_TABLE_SIZE, SLAB_PANIC, pmd_ctor);
+ pgtable_cache_add(PGD_INDEX_SIZE, pgd_ctor);
+ pgtable_cache_add(PMD_INDEX_SIZE, pmd_ctor);
+ if (!PGT_CACHE(PGD_INDEX_SIZE) || !PGT_CACHE(PMD_INDEX_SIZE))
+ panic(Couldn't allocate pgtable caches);
+ BUG_ON(PUD_INDEX_SIZE !PGT_CACHE(PUD_INDEX_SIZE));
}
#ifdef CONFIG_SPARSEMEM_VMEMMAP
Index: working-2.6/arch/powerpc/include/asm/pgalloc-64.h
===
--- working-2.6.orig/arch/powerpc/include/asm/pgalloc-64.h 2009-08-03
16:00:45.0 +1000
+++ working-2.6/arch/powerpc/include/asm/pgalloc-64.h 2009-09-15
15:45:49.0 +1000
@@ -11,27 +11,30 @@
#include linux/cpumask.h
#include linux/percpu.h
+/*
+ * This needs to be big enough to allow any pagetable sizes we need,
+ * but small enough to fit in the low bits of any page table pointer.
+ * In other words all pagetables, even tiny ones, must be aligned to
+ * allow at least enough low 0 bits to contain this value.
+ */
+#define MAX_PGTABLE_INDEX_SIZE 0xf
+
#ifndef CONFIG_PPC_SUBPAGE_PROT
static inline void subpage_prot_free(pgd_t *pgd) {}
#endif
extern struct kmem_cache *pgtable_cache[];
-
-#define PGD_CACHE_NUM 0
-#define PUD_CACHE_NUM 1
-#define PMD_CACHE_NUM 1
-#define HUGEPTE_CACHE_NUM 2
-#define PTE_NONCACHE_NUM 7 /* from GFP rather than kmem_cache */
[1/5] Make hpte_need_flush() correctly mask for multiple page sizes
Currently, hpte_need_flush() only correctly flushes the given address
for normal pages. Callers for hugepages are required to mask the
address themselves.
But hpte_need_flush() already looks up the page sizes for its own
reasons, so this is a rather silly imposition on the callers. This
patch alters it to mask based on the pagesize it has looked up itself,
and removes the awkward masking code in the hugepage caller.
Signed-off-by: David Gibson d...@au1.ibm.com
---
arch/powerpc/mm/hugetlbpage.c |6 +-
arch/powerpc/mm/tlb_hash64.c |8 +++-
2 files changed, 4 insertions(+), 10 deletions(-)
Index: working-2.6/arch/powerpc/mm/tlb_hash64.c
===
--- working-2.6.orig/arch/powerpc/mm/tlb_hash64.c 2009-09-04
14:35:30.0 +1000
+++ working-2.6/arch/powerpc/mm/tlb_hash64.c2009-09-04 14:36:12.0
+1000
@@ -53,11 +53,6 @@ void hpte_need_flush(struct mm_struct *m
i = batch-index;
- /* We mask the address for the base page size. Huge pages will
-* have applied their own masking already
-*/
- addr = PAGE_MASK;
-
/* Get page size (maybe move back to caller).
*
* NOTE: when using special 64K mappings in 4K environment like
@@ -75,6 +70,9 @@ void hpte_need_flush(struct mm_struct *m
} else
psize = pte_pagesize_index(mm, addr, pte);
+ /* Mask the address for the correct page size */
+ addr = ~((1UL mmu_psize_defs[psize].shift) - 1);
+
/* Build full vaddr */
if (!is_kernel_addr(addr)) {
ssize = user_segment_size(addr);
Index: working-2.6/arch/powerpc/mm/hugetlbpage.c
===
--- working-2.6.orig/arch/powerpc/mm/hugetlbpage.c 2009-09-04
14:35:30.0 +1000
+++ working-2.6/arch/powerpc/mm/hugetlbpage.c 2009-09-04 14:36:12.0
+1000
@@ -445,11 +445,7 @@ void set_huge_pte_at(struct mm_struct *m
* necessary anymore if we make hpte_need_flush() get the
* page size from the slices
*/
- unsigned int psize = get_slice_psize(mm, addr);
- unsigned int shift = mmu_psize_to_shift(psize);
- unsigned long sz = ((1UL) shift);
- struct hstate *hstate = size_to_hstate(sz);
- pte_update(mm, addr hstate-mask, ptep, ~0UL, 1);
+ pte_update(mm, addr, ptep, ~0UL, 1);
}
*ptep = __pte(pte_val(pte) ~_PAGE_HPTEFLAGS);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[4/5] Cleanup initialization of hugepages on powerpc
This patch simplifies the logic used to initialize hugepages on
powerpc. The somewhat oddly named set_huge_psize() is renamed to
add_huge_page_size() and now does all necessary verification of
whether it's given a valid hugepage sizes (instead of just some) and
instantiates the generic hstate structure (but no more).
hugetlbpage_init() now steps through the available pagesizes, checks
if they're valid for hugepages by calling add_huge_page_size() and
initializes the kmem_caches for the hugepage pagetables. This means
we can now eliminate the mmu_huge_psizes array, since we no longer
need to pass the sizing information for the pagetable caches from
set_huge_psize() into hugetlbpage_init()
Signed-off-by: David Gibson d...@au1.ibm.com
---
arch/powerpc/mm/hugetlbpage.c | 106 +++---
1 file changed, 49 insertions(+), 57 deletions(-)
Index: working-2.6/arch/powerpc/mm/hugetlbpage.c
===
--- working-2.6.orig/arch/powerpc/mm/hugetlbpage.c 2009-09-09
15:15:12.0 +1000
+++ working-2.6/arch/powerpc/mm/hugetlbpage.c 2009-09-09 15:22:49.0
+1000
@@ -37,11 +37,6 @@
static unsigned long gpage_freearray[MAX_NUMBER_GPAGES];
static unsigned nr_gpages;
-/* Array of valid huge page sizes - non-zero value(hugepte_shift) is
- * stored for the huge page sizes that are valid.
- */
-static unsigned int mmu_huge_psizes[MMU_PAGE_COUNT] = { }; /* initialize all
to 0 */
-
/* Flag to mark huge PD pointers. This means pmd_bad() and pud_bad()
* will choke on pointers to hugepte tables, which is handy for
* catching screwups early. */
@@ -502,8 +497,6 @@ unsigned long hugetlb_get_unmapped_area(
struct hstate *hstate = hstate_file(file);
int mmu_psize = shift_to_mmu_psize(huge_page_shift(hstate));
- if (!mmu_huge_psizes[mmu_psize])
- return -EINVAL;
return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1, 0);
}
@@ -666,47 +659,46 @@ repeat:
return err;
}
-static void __init set_huge_psize(int psize)
+static int __init add_huge_page_size(unsigned long long size)
{
- unsigned pdshift;
+ int shift = __ffs(size);
+ int mmu_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_1T
- (mmu_psize_defs[psize].shift MIN_HUGEPTE_SHIFT ||
-mmu_psize_defs[psize].shift == PAGE_SHIFT_64K ||
-mmu_psize_defs[psize].shift == PAGE_SHIFT_16G)) {
- /* Return if huge page size has already been setup or is the
-* same as the base page size. */
- if (mmu_huge_psizes[psize] ||
- mmu_psize_defs[psize].shift == PAGE_SHIFT)
- return;
- hugetlb_add_hstate(mmu_psize_defs[psize].shift - PAGE_SHIFT);
+* that it fits within pagetable and slice limits. */
+ if (!is_power_of_2(size)
+ || (shift SLICE_HIGH_SHIFT) || (shift = PAGE_SHIFT))
+ return -EINVAL;
- if (mmu_psize_defs[psize].shift PMD_SHIFT)
- pdshift = PMD_SHIFT;
- else if (mmu_psize_defs[psize].shift PUD_SHIFT)
- pdshift = PUD_SHIFT;
- else
- pdshift = PGDIR_SHIFT;
- mmu_huge_psizes[psize] = pdshift - mmu_psize_defs[psize].shift;
- }
+ if ((mmu_psize = shift_to_mmu_psize(shift)) 0)
+ return -EINVAL;
+
+#ifndef CONFIG_SPU_FS_64K_LS
+ /* Disable support for 64K huge pages when 64K SPU local store
+* support is enabled as the current implementation conflicts.
+*/
+ if (size == PAGE_SIZE_64K)
+ return -EINVAL;
+#endif /* CONFIG_SPU_FS_64K_LS */
+
+ BUG_ON(mmu_psize_defs[mmu_psize].shift != shift);
+
+ /* Return if huge page size has already been setup */
+ if (size_to_hstate(size))
+ return 0;
+
+ hugetlb_add_hstate(shift - PAGE_SHIFT);
+
+ return 0;
}
static int __init hugepage_setup_sz(char *str)
{
unsigned long long size;
- int mmu_psize;
- int shift;
size = memparse(str, str);
- shift = __ffs(size);
- mmu_psize = shift_to_mmu_psize(shift);
- if (mmu_psize = 0 mmu_psize_defs[mmu_psize].shift)
- set_huge_psize(mmu_psize);
- else
+ if (add_huge_page_size(size) != 0)
printk(KERN_WARNING Invalid huge page size specified(%llu)\n,
size);
return 1;
@@ -720,31 +712,31 @@ static int __init hugetlbpage_init(void)
if (!cpu_has_feature(CPU_FTR_16M_PAGE))
return -ENODEV;
- /* Add supported huge page sizes. Need to change HUGE_MAX_HSTATE
-* and adjust PTE_NONCACHE_NUM if the
[3/5] Allow more flexible layouts for hugepage pagetables
Currently each available hugepage size uses a slightly different
pagetable layout: that is, the bottem level table of pointers to
hugepages is a different size, and may branch off from the normal page
tables at a different level. Every hugepage aware path that needs to
walk the pagetables must therefore look up the hugepage size from the
slice info first, and work out the correct way to walk the pagetables
accordingly. Future hardware is likely to add more possible hugepage
sizes, more layout options and more mess.
This patch, therefore reworks the handling of hugepage pagetables to
reduce this complexity. In the new scheme, instead of having to
consult the slice mask, pagetable walking code can check a flag in the
PGD/PUD/PMD entries to see where to branch off to hugepage pagetables,
and the entry also contains the information (eseentially hugepage
shift) necessary to then interpret that table without recourse to the
slice mask. This scheme can be extended neatly to handle multiple
levels of self-describing special hugepage pagetables, although for
now we assume only one level exists.
This approach means that only the pagetable allocation path needs to
know how the pagetables should be set out. All other (hugepage)
pagetable walking paths can just interpret the structure as they go.
There already was a flag bit in PGD/PUD/PMD entries for hugepage
directory pointers, but it was only used for debug. We alter that
flag bit to instead be a 0 in the MSB to indicate a hugepage pagetable
pointer (normally it would be 1 since the pointer lies in the linear
mapping). This means that asm pagetable walking can test for (and
punt on) hugepage pointers with the same test that checks for
unpopulated page directory entries (beq becomes bge), since hugepage
pointers will always be positive, and normal pointers always negative.
While we're at it, we get rid of the confusing (and grep defeating)
#defining of hugepte_shift to be the same thing as mmu_huge_psizes.
Signed-off-by: David Gibson d...@au1.ibm.com
---
arch/powerpc/include/asm/hugetlb.h | 12
arch/powerpc/include/asm/mmu-hash64.h| 14
arch/powerpc/include/asm/pgtable-ppc64.h | 13
arch/powerpc/kernel/perf_callchain.c | 20 -
arch/powerpc/mm/gup.c| 149 +
arch/powerpc/mm/hash_utils_64.c | 17 -
arch/powerpc/mm/hugetlbpage.c| 473 ++-
arch/powerpc/mm/init_64.c| 10
8 files changed, 302 insertions(+), 406 deletions(-)
Index: working-2.6/arch/powerpc/mm/hugetlbpage.c
===
--- working-2.6.orig/arch/powerpc/mm/hugetlbpage.c 2009-09-15
16:03:08.0 +1000
+++ working-2.6/arch/powerpc/mm/hugetlbpage.c 2009-09-15 16:08:02.0
+1000
@@ -40,25 +40,11 @@ static unsigned nr_gpages;
/* Array of valid huge page sizes - non-zero value(hugepte_shift) is
* stored for the huge page sizes that are valid.
*/
-unsigned int mmu_huge_psizes[MMU_PAGE_COUNT] = { }; /* initialize all to 0 */
-
-#define hugepte_shift mmu_huge_psizes
-#define HUGEPTE_INDEX_SIZE(psize) (mmu_huge_psizes[(psize)])
-#define PTRS_PER_HUGEPTE(psize)(1 mmu_huge_psizes[psize])
-
-#define HUGEPD_SHIFT(psize)(mmu_psize_to_shift(psize) \
-+ HUGEPTE_INDEX_SIZE(psize))
-#define HUGEPD_SIZE(psize) (1UL HUGEPD_SHIFT(psize))
-#define HUGEPD_MASK(psize) (~(HUGEPD_SIZE(psize)-1))
+static unsigned int mmu_huge_psizes[MMU_PAGE_COUNT] = { }; /* initialize all
to 0 */
/* Flag to mark huge PD pointers. This means pmd_bad() and pud_bad()
* will choke on pointers to hugepte tables, which is handy for
* catching screwups early. */
-#define HUGEPD_OK 0x1
-
-typedef struct { unsigned long pd; } hugepd_t;
-
-#define hugepd_none(hpd) ((hpd).pd == 0)
static inline int shift_to_mmu_psize(unsigned int shift)
{
@@ -82,71 +68,126 @@ static inline unsigned int mmu_psize_to_
BUG();
}
+#define hugepd_none(hpd) ((hpd).pd == 0)
+
static inline pte_t *hugepd_page(hugepd_t hpd)
{
- BUG_ON(!(hpd.pd HUGEPD_OK));
- return (pte_t *)(hpd.pd ~HUGEPD_OK);
+ BUG_ON(!hugepd_ok(hpd));
+ return (pte_t *)((hpd.pd ~HUGEPD_SHIFT_MASK) | 0xc000);
}
-static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned long addr,
- struct hstate *hstate)
+static inline unsigned int hugepd_shift(hugepd_t hpd)
{
- unsigned int shift = huge_page_shift(hstate);
- int psize = shift_to_mmu_psize(shift);
- unsigned long idx = ((addr shift) (PTRS_PER_HUGEPTE(psize)-1));
+ return hpd.pd HUGEPD_SHIFT_MASK;
+}
+
+static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned long addr,
unsigned pdshift)
+{
+ unsigned long idx = (addr ((1UL pdshift) - 1))
hugepd_shift(*hpdp);
pte_t *dir =
[5/5] Split hash MMU specific hugepage code into a new file
This patch separates the parts of hugetlbpage.c which are inherently
specific to the hash MMU into a new hugelbpage-hash64.c file.
Signed-off-by: David Gibson d...@au1.ibm.com
---
arch/powerpc/include/asm/hugetlb.h |3
arch/powerpc/mm/Makefile |5 -
arch/powerpc/mm/hugetlbpage-hash64.c | 167 ++
arch/powerpc/mm/hugetlbpage.c| 168 ---
4 files changed, 176 insertions(+), 167 deletions(-)
Index: working-2.6/arch/powerpc/mm/Makefile
===
--- working-2.6.orig/arch/powerpc/mm/Makefile 2009-08-14 16:07:54.0
+1000
+++ working-2.6/arch/powerpc/mm/Makefile2009-09-09 15:24:33.0
+1000
@@ -28,7 +28,10 @@ obj-$(CONFIG_44x)+= 44x_mmu.o
obj-$(CONFIG_FSL_BOOKE)+= fsl_booke_mmu.o
obj-$(CONFIG_NEED_MULTIPLE_NODES) += numa.o
obj-$(CONFIG_PPC_MM_SLICES)+= slice.o
-obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
+ifeq ($(CONFIG_HUGETLB_PAGE),y)
+obj-y += hugetlbpage.o
+obj-$(CONFIG_PPC_STD_MMU_64) += hugetlbpage-hash64.o
+endif
obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
obj-$(CONFIG_HIGHMEM) += highmem.o
Index: working-2.6/arch/powerpc/mm/hugetlbpage-hash64.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ working-2.6/arch/powerpc/mm/hugetlbpage-hash64.c2009-09-09
15:25:35.0 +1000
@@ -0,0 +1,167 @@
+/*
+ * PPC64 Huge TLB Page Support for hash based MMUs (POWER4 and later)
+ *
+ * Copyright (C) 2003 David Gibson, IBM Corporation.
+ *
+ * Based on the IA-32 version:
+ * Copyright (C) 2002, Rohit Seth rohit.s...@intel.com
+ */
+
+#include linux/mm.h
+#include linux/hugetlb.h
+#include asm/pgtable.h
+#include asm/pgalloc.h
+#include asm/cacheflush.h
+#include asm/machdep.h
+
+/*
+ * Called by asm hashtable.S for doing lazy icache flush
+ */
+static unsigned int hash_huge_page_do_lazy_icache(unsigned long rflags,
+ pte_t pte, int trap, unsigned long sz)
+{
+ struct page *page;
+ int i;
+
+ if (!pfn_valid(pte_pfn(pte)))
+ return rflags;
+
+ page = pte_page(pte);
+
+ /* page is dirty */
+ if (!test_bit(PG_arch_1, page-flags) !PageReserved(page)) {
+ if (trap == 0x400) {
+ for (i = 0; i (sz / PAGE_SIZE); i++)
+ __flush_dcache_icache(page_address(page+i));
+ set_bit(PG_arch_1, page-flags);
+ } else {
+ rflags |= HPTE_R_N;
+ }
+ }
+ return rflags;
+}
+
+int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long
vsid,
+pte_t *ptep, unsigned long trap, int local, int ssize,
+unsigned int shift, unsigned int mmu_psize)
+{
+ unsigned long old_pte, new_pte;
+ unsigned long va, rflags, pa, sz;
+ long slot;
+ int err = 1;
+
+ BUG_ON(shift != mmu_psize_defs[mmu_psize].shift);
+
+ /* Search the Linux page table for a match with va */
+ va = hpt_va(ea, vsid, ssize);
+
+ /*
+* Check the user's access rights to the page. If access should be
+* prevented then send the problem up to do_page_fault.
+*/
+ if (unlikely(access ~pte_val(*ptep)))
+ goto out;
+ /*
+* At this point, we have a pte (old_pte) which can be used to build
+* or update an HPTE. There are 2 cases:
+*
+* 1. There is a valid (present) pte with no associated HPTE (this is
+* the most common case)
+* 2. There is a valid (present) pte with an associated HPTE. The
+* current values of the pp bits in the HPTE prevent access
+* because we are doing software DIRTY bit management and the
+* page is currently not DIRTY.
+*/
+
+
+ do {
+ old_pte = pte_val(*ptep);
+ if (old_pte _PAGE_BUSY)
+ goto out;
+ new_pte = old_pte | _PAGE_BUSY | _PAGE_ACCESSED;
+ } while(old_pte != __cmpxchg_u64((unsigned long *)ptep,
+old_pte, new_pte));
+
+ rflags = 0x2 | (!(new_pte _PAGE_RW));
+ /* _PAGE_EXEC - HW_NO_EXEC since it's inverted */
+ rflags |= ((new_pte _PAGE_EXEC) ? 0 : HPTE_R_N);
+ sz = ((1UL) shift);
+ if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
+ /* No CPU has hugepages but lacks no execute, so we
+* don't need to worry about that case */
+ rflags = hash_huge_page_do_lazy_icache(rflags, __pte(old_pte),
+ trap, sz);
+
+ /* Check if pte already has an hpte
Re: [git pull] Please pull powerpc.git next branch
On Fri, 2009-09-11 at 17:18 +1000, Benjamin Herrenschmidt wrote: Hi Linus ! This is the powerpc batch for 2.6.32. You will notice a bunch of generic swiotlb changes along with corresponding changes to arch/sparc and arch/x86 from Fujita Tomonori. There are due to my tree having pulled Ingo's iommu tree do sort out various dependencies. If you pull Ingo's first, you'll already have all these. I'm happy for you to defer the pulling of my tree until you have those bits via Ingo if you prefer, and I'll then send a pull request cleared of that noise. So you pulled from Ingo, gitk or git log origin/master..powerpc/next only shows my new stuff but git shortlog and git diff --stat still get everything from the merge base including Fujita stuff... So I don't know at this stage how to generate a clean pull request ... In any case, the tree is still there waiting for you to pull. It seems to merge cleanly tonight though I haven't yet got a chance to test the result much. Cheers, Ben. Among other non-arch/powerpc patches: Some PS3 and PowerMac specific driver changes (yes, I think we are still the only users of generic_nvram), some changes to HVC console and that should be it. Cheers, Ben. The following changes since commit e07cccf4046978df10f2e13fe2b99b2f9b3a65db: Linus Torvalds (1): Linux 2.6.31-rc9 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next Anton Blanchard (3): powerpc: Move 64bit VDSO to improve context switch performance powerpc: Rearrange SLB preload code powerpc: Preload application text segment instead of TASK_UNMAPPED_BASE Anton Vorontsov (7): powerpc/83xx: Add support for MPC8377E-WLAN boards powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards powerpc/83xx: Add eSDHC support for MPC837xE-RDB/WLAN boards powerpc/85xx: Add eSDHC support for MPC8536DS boards powerpc/82xx: Fix BCSR bits for MPC8272ADS boards powerpc/82xx: Add CPM USB Gadget support for MPC8272ADS boards powerpc/85xx: Add QE USB support for MPC8569E-MDS boards Arnd Bergmann (1): dma-ops: Remove flush_write_buffers() in dma-mapping-common.h Bastian Blank (1): powerpc: Remove SMP warning from PowerMac cpufreq Becky Bruce (1): powerpc: Name xpn x fields in HW Hash PTE format Benjamin Herrenschmidt (37): powerpc: Rename exception.h to exception-64s.h powerpc: Use names rather than numbers for SPRGs (v2) powerpc: Remove use of a second scratch SPRG in STAB code powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig powerpc/pmac: Fix PowerSurge SMP IPI allocation powerpc: Change PACA from SPRG3 to SPRG1 powerpc: Add compat_sys_truncate powerpc/mm: Fix misplaced #endif in pgtable-ppc64-64k.h powerpc/of: Remove useless register save/restore when calling OF back powerpc/mm: Add HW threads support to no_hash TLB management powerpc/mm: Add opcode definitions for tlbivax and tlbsrx. powerpc/mm: Add more bit definitions for Book3E MMU registers powerpc/mm: Add support for early ioremap on non-hash 64-bit processors powerpc: Modify some ppc_asm.h macros to accomodate 64-bits Book3E powerpc/mm: Make low level TLB flush ops on BookE take additional args powerpc/mm: Call mmu_context_init() from ppc64 powerpc: Clean ifdef usage in copy_thread() powerpc: Move definitions of secondary CPU spinloop to header file powerpc/mm: Rework cleanup page table freeing code path powerpc: Add SPR definitions for new 64-bit BookE powerpc: Add memory management headers for new 64-bit BookE powerpc: Add definitions used by exception handling on 64-bit Book3E powerpc: Add PACA fields specific to 64-bit Book3E processors powerpc/mm: Move around mmu_gathers definition on 64-bit powerpc: Add TLB management code for 64-bit Book3E powerpc/mm: Add support for SPARSEMEM_VMEMMAP on 64-bit Book3E powerpc: Remaining 64-bit Book3E support powerpc/mm: Fix encoding of page table cache numbers Merge commit 'paulus-perf/master' into next Merge commit 'origin/master' into next powerpc/mm: Cleanup handling of execute permission Merge commit 'kumar/next' into next Merge commit 'tip/iommu-for-powerpc' into next powerpc: Properly start decrementer on BookE secondary CPUs powerpc: Fix some late PowerMac G5 with PCIe ATI graphics powerpc/booke: Don't set DABR on 64-bit BookE, use DAC1 instead powerpc/iseries: Fix oops reading from /proc/iSeries/mf/*/cmdline Benjamin Krill (1): powerpc/prom_init: Evaluate mem kernel parameter for early allocation Brian King (1): powerpc/pseries: Fix to handle slb resize across migration Casey Dahlin (1): lib/swiotlb.c: Fix strange panic message
Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009/9/15 Benjamin Herrenschmidt b...@kernel.crashing.org: On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote: 2009/9/14 Josh Boyer jwbo...@linux.vnet.ibm.com: On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote: Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) 2.6.10? Really? If that is truly the case, you probably aren't going to get a whole lot of help from the list, since that kernel is pretty ancient. I can only acknowledge that, but we're stuck to that kernel for now... kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Posting the oops output would perhaps help. Or maybe not. josh Here it goes, you never know: Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C0148050 LR: C013BC64 SP: C07CFEA0 REGS: c07cfdf0 TRAP: 0300 Not tainted MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 DAR: E3093000, DSISR: TASK = c07cdb70[1] 'swapper' THREAD: c07ce000 Last syscall: 120 GPR00: C07CFEA0 C07CDB70 E3093000 DFE829FE 0100 C01184E8 C021B270 GPR08: C022 C02D0F60 C07CDEF8 C07CDEF8 7000 1FFF6400 0001 GPR16: 0001 1FFF06C0 0001 C022 C028 00029000 GPR24: C02D0F60 C01F C0148040 0080 DFE82A00 C02D0FF0 NIP [c0148050] ide_insw+0x10/0x24 LR [c013bc64] ata_input_data+0x74/0x114 Call backtrace: c013e6a4 try_to_identify+0x2ec/0x5ec c013eaa8 do_probe+0x104/0x304 c013f0c4 probe_hwif+0x358/0x6c4 c0140068 ideprobe_init+0xa8/0x1a0 c02a4ef8 ide_generic_init+0x10/0x28 c0001324 init+0xc4/0x244 c0004254 kernel_thread+0x44/0x60 Kernel panic - not syncing: Attempted to kill init! 0Rebooting in 180 seconds.. ide_insw is a asm routine to read in 16bit words and swap them. Copied from arch/ppc/kernel/misc.S. Works fine when PCI is disabled. Probably because ide_insw uses isnw which offsets everything from _IO_BASE which changes value when you have a PCI bus with an IO space... If your IDE isn't PCI IO space based you shouldn't use ide_insw but the MMIO variants instead. Ben. Thnx for the suggestion, but the ide_insw is in fact of copy of the _insw assembly routine, and it gets passed the effective address, without the _IO_BASE offset. I was thinking about TLB stuff. I'm not a u-boot expert, but could it be that I need to tweak/reconfigure u-boot so I can access the address returned from ioremap64? KR, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
On Tue, 2009-09-15 at 10:57 +0200, Ludo Van Put wrote: Thnx for the suggestion, but the ide_insw is in fact of copy of the _insw assembly routine, and it gets passed the effective address, without the _IO_BASE offset. I was thinking about TLB stuff. I'm not a u-boot expert, but could it be that I need to tweak/reconfigure u-boot so I can access the address returned from ioremap64? No. If you pass the right physical address to ioremap64, the result should be useable as-is. The TLB entries will be faulted in automatically by the kernel when doing accesses. At this stage, I can't say what's wrong, it looks like you may be accessing the wrong virtual address or something like that. Hard to tell. It's a data access exception, not a machine check, so that means that in some ways, the virtual address accessed by ide_insw is not mapped by the kernel page tables, which is what the kernel TLB miss handler uses to populate the TLB. 2.6.10 is so old, that I really have little memories of what is going on in that area and I'm afraid am of little help here. If you have a HW debugger such as a BDI, you may want to trace through the access, what kind of TLB faults it generates and why the TLB miss handler doesn't handle it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/irq: Add generic API for setting up cascaded IRQs
I'm a reverse polish kind of guy. I preferring 'subject'_'action' over 'action'_'subject' just because it groups like subjects together. But it doesn't matter much, especially in this case where 'subject' is in a group of exactly 1. :-) I'll do whichever you prefer. I just caught myself calling something relocs_check instead of check_relocs so I suppose it's fair game :-) Whatever you want. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources
diff --git a/drivers/message/fusion/mptbase.c
b/drivers/message/fusion/mptbase.c
index 5d496a9..d5b0f15 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1510,11 +1510,12 @@ static int
mpt_mapresources(MPT_ADAPTER *ioc)
{
u8 __iomem *mem;
+ u8 __iomem *port;
int ii;
- unsigned longmem_phys;
- unsigned longport;
- u32 msize;
- u32 psize;
+ phys_addr_t mem_phys;
+ phys_addr_t port_phys;
+ resource_size_t msize;
+ resource_size_t psize;
Is phys_addr_t defined for all archs nowadays ? Why not use
resource_size_t for everything ? resource_size_t is a bit of a misnomer,
it's not a type supposed to reference a size but really a physical
address (or a size)... it's been called resource_size_t I believe
because it's sized appropriately for holding a physical address.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/irq: Add generic API for setting up cascaded IRQs
On Tue, 2009-09-15 at 20:02 +1000, Benjamin Herrenschmidt wrote: I'm a reverse polish kind of guy. I preferring 'subject'_'action' over 'action'_'subject' just because it groups like subjects together. But it doesn't matter much, especially in this case where 'subject' is in a group of exactly 1. :-) I'll do whichever you prefer. I just caught myself calling something relocs_check instead of check_relocs so I suppose it's fair game :-) Yeah but that sounds stupid :) Whatever you want. I want a pony. And setup_cascade() is definitely better IMHO. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/3] cpu: pseries: Cpu offline states framework
Hi, RFC not for inclusion This is the version 3 of the patch series to provide a cpu-offline framework that enables the administrators choose the state of a CPU when it is offlined, when multiple such states are exposed by the underlying architecture. Changes from Version 2:(can be found here: http://lkml.org/lkml/2009/8/28/102) - Addressed Andrew Morton's review comments regarding names of global variables, handling of error conditions and documentation of the interfaces. - Implemented a patch to provide helper functions to set the cede latency specifier value in the VPA indicating latency expectation of the guest OS when the vcpu is ceded from a subsequent H_CEDE hypercall. Hypervisor may use this for better energy savings. - Renamed of the cpu-hotplug states. deallocate is renamed as offline and deactivate is renamed as inactive. The patch-series exposes the following sysfs tunables to allow the system-adminstrator to choose the state of a CPU: To query the available hotplug states, one needs to read the sysfs tunable: /sys/devices/system/cpu/cpunumber/available_hotplug_states To query or set the current state, on needs to read/write the sysfs tunable: /sys/devices/system/cpu/cpunumber/current_hotplug_state The patchset ensures that the writes to the current_hotplug_state sysfs file are serialized against the writes to the online file. This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined even in the absense of this driver. The CPU would call make an rtas_stop_self() call and hand over the CPU back to the resource pool, thereby effectively deallocating that vCPU from the LPAR. NOTE: This would result in a configuration change to the LPAR which is visible to the outside world. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. NOTE: This option does not result in a configuration change and the vCPU would be still entitled to the LPAR to which it earlier belong to. Any feedback on the patchset will be immensely valuable. --- Arun R Bharadwaj (1): pSeries: cede latency specifier helper function. Gautham R Shenoy (2): cpu: Implement cpu-offline-state callbacks for pSeries. cpu: Offline state Framework. Documentation/cpu-hotplug.txt | 22 +++ arch/powerpc/include/asm/lppaca.h |9 + arch/powerpc/platforms/pseries/Makefile |2 arch/powerpc/platforms/pseries/hotplug-cpu.c| 88 ++- arch/powerpc/platforms/pseries/offline_driver.c | 148 +++ arch/powerpc/platforms/pseries/offline_driver.h | 20 +++ arch/powerpc/platforms/pseries/plpar_wrappers.h | 17 ++ arch/powerpc/platforms/pseries/smp.c| 17 ++ arch/powerpc/xmon/xmon.c|3 drivers/base/cpu.c | 181 ++- include/linux/cpu.h | 10 + 11 files changed, 498 insertions(+), 19 deletions(-) create mode 100644 arch/powerpc/platforms/pseries/offline_driver.c create mode 100644 arch/powerpc/platforms/pseries/offline_driver.h -- Thanks and Regards gautham. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/3] pSeries: cede latency specifier helper function.
From: Arun R Bharadwaj a...@linux.vnet.ibm.com
This patch provides helper functions to set the cede latency specifier
value in the VPA indicating the latency expectation of the guest OS to
inform the hypervisor's choice of the platform dependent energy saving
mode chosen for the processor when unused during the subsequent
H_CEDE hypercall.
Signed-off-by: Arun R Bharadwaj a...@linux.vnet.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
arch/powerpc/include/asm/lppaca.h |9 -
arch/powerpc/platforms/pseries/plpar_wrappers.h | 17 +
arch/powerpc/xmon/xmon.c|3 ++-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index f78f65c..aaa0066 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -100,7 +100,14 @@ struct lppaca {
// Used to pass parms from the OS to PLIC for SetAsrAndRfid
u64 saved_gpr3; // Saved GPR3 x20-x27
u64 saved_gpr4; // Saved GPR4 x28-x2F
- u64 saved_gpr5; // Saved GPR5 x30-x37
+ union {
+ u64 saved_gpr5; // Saved GPR5 x30-x37
+ struct {
+ u8 cede_latency_hint; // x30
+ u8 reserved[7];// x31-x36
+ } fields;
+ } gpr5_dword;
+
u8 dtl_enable_mask;// Dispatch Trace Log mask x38-x38
u8 donate_dedicated_cpu; // Donate dedicated CPU cycles x39-x39
diff --git a/arch/powerpc/platforms/pseries/plpar_wrappers.h
b/arch/powerpc/platforms/pseries/plpar_wrappers.h
index a24a6b2..1174d4b 100644
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -9,11 +9,28 @@ static inline long poll_pending(void)
return plpar_hcall_norets(H_POLL_PENDING);
}
+static inline u8 get_cede_latency_hint(void)
+{
+ return get_lppaca()-gpr5_dword.fields.cede_latency_hint;
+}
+
+static inline void set_cede_latency_hint(u8 latency_hint)
+{
+ get_lppaca()-gpr5_dword.fields.cede_latency_hint = latency_hint;
+}
+
static inline long cede_processor(void)
{
return plpar_hcall_norets(H_CEDE);
}
+static inline long extended_cede_processor(u8 latency_hint)
+{
+ set_cede_latency_hint(latency_hint);
+ cede_processor();
+
+}
+
static inline long vpa_call(unsigned long flags, unsigned long cpu,
unsigned long vpa)
{
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index e1f33a8..a2089cd 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1613,7 +1613,8 @@ static void super_regs(void)
ptrLpPaca-saved_srr0, ptrLpPaca-saved_srr1);
printf(Saved Gpr3=%.16lx Saved Gpr4=%.16lx \n,
ptrLpPaca-saved_gpr3, ptrLpPaca-saved_gpr4);
- printf(Saved Gpr5=%.16lx \n,
ptrLpPaca-saved_gpr5);
+ printf(Saved Gpr5=%.16lx \n,
+ ptrLpPaca-gpr5_dword.saved_gpr5);
}
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/3] cpu: Offline state Framework.
Provide an interface by which the system administrator can decide what state
should the CPU go to when it is offlined.
To query the hotplug states, on needs to perform a read on:
/sys/devices/system/cpu/cpunumber/available_hotplug_states
To query or set the current state for a particular CPU, one needs to
use the sysfs interface
/sys/devices/system/cpu/cpunumber/current_hotplug_state
This patch implements the architecture independent bits of the
cpu-offline-state framework.
The architecture specific bits are expected to register the actual code which
implements the callbacks when the above mentioned sysfs interfaces are read or
written into. Thus the values provided by reading available_offline_states vary
with the architecture.
The patch provides serialization for writes to the current_hotplug_state
with respect to with the writes to the online sysfs tunable.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
Documentation/cpu-hotplug.txt | 22 +
drivers/base/cpu.c| 181 +++--
include/linux/cpu.h | 10 ++
3 files changed, 204 insertions(+), 9 deletions(-)
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9d620c1..dcec06d 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -115,6 +115,28 @@ Just remember the critical section cannot call any
function that can sleep or schedule this process away. The preempt_disable()
will work as long as stop_machine_run() is used to take a cpu down.
+CPU-offline states
+--
+On architectures which allow the more than one valid state when
+the CPU goes offline, the system administrator can decide
+the state the CPU needs to go to when it is offlined.
+
+If the architecture has implemented a cpu-offline driver exposing these
+multiple offline states, the system administrator can use the following sysfs
+interfaces to query the available hotplug states and also query and set the
+current hotplug state for a given cpu:
+
+To query the hotplug states, on needs to perform a read on:
+/sys/devices/system/cpu/cpunumber/available_hotplug_states
+
+To query or set the current state for a particular CPU,
+one needs to use the sysfs interface
+
+/sys/devices/system/cpu/cpunumber/current_hotplug_state
+
+Writes to the online sysfs files are serialized against the writes to the
+current_hotplug_state file.
+
CPU Hotplug - Frequently Asked Questions.
Q: How to enable my kernel to support CPU hotplug?
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index e62a4cc..00c38be 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -20,7 +20,166 @@ EXPORT_SYMBOL(cpu_sysdev_class);
static DEFINE_PER_CPU(struct sys_device *, cpu_sys_devices);
+struct sys_device *get_cpu_sysdev(unsigned cpu)
+{
+ if (cpu nr_cpu_ids cpu_possible(cpu))
+ return per_cpu(cpu_sys_devices, cpu);
+ else
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(get_cpu_sysdev);
+
+
#ifdef CONFIG_HOTPLUG_CPU
+
+struct cpu_offline_driver *cpu_offline_driver;
+static DEFINE_MUTEX(cpu_offline_driver_lock);
+
+ssize_t show_available_hotplug_states(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ int cpu_num = cpu-sysdev.id;
+ ssize_t ret;
+
+ mutex_lock(cpu_offline_driver_lock);
+ if (!cpu_offline_driver) {
+ ret = -EEXIST;
+ goto out_unlock;
+ }
+
+ ret = cpu_offline_driver-read_available_states(cpu_num, buf);
+
+out_unlock:
+ mutex_unlock(cpu_offline_driver_lock);
+
+ return ret;
+
+}
+
+ssize_t show_current_hotplug_state(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ int cpu_num = cpu-sysdev.id;
+ ssize_t ret = 0;
+
+ mutex_lock(cpu_offline_driver_lock);
+ if (!cpu_offline_driver) {
+ ret = -EEXIST;
+ goto out_unlock;
+ }
+
+ ret = cpu_offline_driver-read_current_state(cpu_num, buf);
+
+out_unlock:
+ mutex_unlock(cpu_offline_driver_lock);
+
+ return ret;
+}
+
+ssize_t store_current_hotplug_state(struct sys_device *dev,
+ struct sysdev_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ int cpu_num = cpu-sysdev.id;
+ ssize_t ret = count;
+
+ mutex_lock(cpu_offline_driver_lock);
+ if (!cpu_offline_driver) {
+ ret = -EEXIST;
+ goto out_unlock;
+ }
+
+ ret = cpu_offline_driver-write_current_state(cpu_num, buf);
+
+out_unlock:
+ mutex_unlock(cpu_offline_driver_lock);
+
+ if (ret = 0)
+ ret = count;
+ return ret;
+}
+
+static
[PATCH v3 3/3] cpu: Implement cpu-offline-state callbacks for pSeries.
This patch implements the callbacks to handle the reads/writes into the sysfs
interfaces
/sys/devices/system/cpu/cpunumber/available_hotplug_states
and
/sys/devices/system/cpu/cpunumber/current_hotplug_state
Currently, the patch defines two states which the processor can go to when it
is offlined. They are
- offline: The current behaviour when the cpu is offlined.
The CPU would call make an rtas_stop_self() call and hand over the
CPU back to the resource pool, thereby effectively deallocating
that vCPU from the LPAR.
- inactive: This is expected to cede the processor to the hypervisor with a
latency hint specifier value. Hypervisor may use this hint to provide
better energy savings. In this state, the control of the vCPU will continue
to be with the LPAR.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
arch/powerpc/platforms/pseries/Makefile |2
arch/powerpc/platforms/pseries/hotplug-cpu.c| 88 +-
arch/powerpc/platforms/pseries/offline_driver.c | 148 +++
arch/powerpc/platforms/pseries/offline_driver.h | 20 +++
arch/powerpc/platforms/pseries/smp.c| 17 +++
5 files changed, 267 insertions(+), 8 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/offline_driver.c
create mode 100644 arch/powerpc/platforms/pseries/offline_driver.h
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 790c0b8..3a569c7 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
obj-$(CONFIG_PCI) += pci.o pci_dlpar.o
obj-$(CONFIG_PSERIES_MSI) += msi.o
-obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu.o
+obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu.o offline_driver.o
obj-$(CONFIG_MEMORY_HOTPLUG) += hotplug-memory.o
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index a20ead8..1e06bb1 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -30,6 +30,7 @@
#include asm/pSeries_reconfig.h
#include xics.h
#include plpar_wrappers.h
+#include offline_driver.h
/* This version can't take the spinlock, because it never returns */
static struct rtas_args rtas_stop_self_args = {
@@ -54,13 +55,74 @@ static void rtas_stop_self(void)
panic(Alas, I survived.\n);
}
+static void cede_on_offline(u8 cede_latency_hint)
+{
+ unsigned int cpu = smp_processor_id();
+ unsigned int hwcpu = hard_smp_processor_id();
+ u8 old_cede_latency_hint;
+
+ old_cede_latency_hint = get_cede_latency_hint();
+ get_lppaca()-idle = 1;
+ if (!get_lppaca()-shared_proc)
+ get_lppaca()-donate_dedicated_cpu = 1;
+
+ printk(KERN_INFO cpu %u (hwid %u) ceding for offline with hint %d\n,
+ cpu, hwcpu, cede_latency_hint);
+ while (get_preferred_offline_state(cpu) != CPU_STATE_ONLINE) {
+ extended_cede_processor(cede_latency_hint);
+ printk(KERN_INFO cpu %u (hwid %u) returned from cede.\n,
+ cpu, hwcpu);
+ printk(KERN_INFO
+ Decrementer value = %x Timebase value = %llx\n,
+ get_dec(), get_tb());
+ }
+
+ printk(KERN_INFO cpu %u (hwid %u) got prodded to go online\n,
+ cpu, hwcpu);
+
+ if (!get_lppaca()-shared_proc)
+ get_lppaca()-donate_dedicated_cpu = 0;
+ get_lppaca()-idle = 0;
+
+ /* Reset the cede_latency specifier value */
+ set_cede_latency_hint(old_cede_latency_hint);
+
+ unregister_slb_shadow(hwcpu, __pa(get_slb_shadow()));
+
+ /*
+* NOTE: Calling start_secondary() here for now to start
+* a new context.
+*
+* However, need to do it cleanly by resetting the stack
+* pointer.
+*/
+ start_secondary();
+}
+
static void pseries_mach_cpu_die(void)
{
+ unsigned int cpu = smp_processor_id();
+ u8 cede_latency_hint = 0;
+
local_irq_disable();
idle_task_exit();
xics_teardown_cpu();
- unregister_slb_shadow(hard_smp_processor_id(), __pa(get_slb_shadow()));
- rtas_stop_self();
+
+ if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
+
+ set_cpu_current_state(cpu, CPU_STATE_OFFLINE);
+ unregister_slb_shadow(hard_smp_processor_id(),
+ __pa(get_slb_shadow()));
+ rtas_stop_self();
+ goto out_bug;
+ } else if (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
+ set_cpu_current_state(cpu, CPU_STATE_INACTIVE);
+ cede_latency_hint = 2;
+ cede_on_offline(cede_latency_hint);
+
+ }
+
+out_bug:
/* Should never get here... */
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined even in the absense of this driver. The CPU would call make an rtas_stop_self() call and hand over the CPU back to the resource pool, thereby effectively deallocating that vCPU from the LPAR. NOTE: This would result in a configuration change to the LPAR which is visible to the outside world. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. NOTE: This option does not result in a configuration change and the vCPU would be still entitled to the LPAR to which it earlier belong to. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined even in the absense of this driver. The CPU would call make an rtas_stop_self() call and hand over the CPU back to the resource pool, thereby effectively deallocating that vCPU from the LPAR. NOTE: This would result in a configuration change to the LPAR which is visible to the outside world. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. NOTE: This option does not result in a configuration change and the vCPU would be still entitled to the LPAR to which it earlier belong to. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. Yeah it probably is a layering violation, but when has that stopped us before :) Is it anticipated that this will be useful on platforms other than pseries? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] dynamic logical partitioning infrastructure
Brian King wrote:
Nathan Fontenot wrote:
+#include linux/kernel.h
+#include linux/kref.h
+#include linux/notifier.h
+#include linux/proc_fs.h
+#include linux/spinlock.h
+
+#include asm/prom.h
+#include asm/machdep.h
+#include asm/uaccess.h
+#include asm/rtas.h
+#include asm/pSeries_reconfig.h
+
+#define CFG_CONN_WORK_SIZE4096
+static char workarea[CFG_CONN_WORK_SIZE];
+spinlock_t workarea_lock;
This can be:
static DEFINE_SPINLOCK(workarea_lock);
Then you can get rid of the runtime initializer.
Good catch, I will fix it in the updated patches.
+
+int release_drc(u32 drc_index)
+{
+int dr_status, rc;
+
+rc = rtas_call(rtas_token(get-sensor-state), 2, 2, dr_status,
+ DR_ENTITY_SENSE, drc_index);
+if (rc || dr_status != DR_ENTITY_PRESENT)
+return -1;
+
+rc = rtas_set_indicator(ISOLATION_STATE, drc_index, ISOLATE);
+if (rc)
+return -1;
+
+rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
+if (rc) {
+rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
+return -1;
+}
Is there a better return value here that might be more descriptive than -1?
Yes, I could return the rtas error code to the user to allow the caller to
evaluate it if they wanted to. For what I am doing I am only concerned with
success/failure so I did not deal with returning anything other than -1.
I'll update the next patch to return the rtas error for failures and 0
for success.
+
+return 0;
+}
+
+static int pseries_dlpar_init(void)
+{
+spin_lock_init(workarea_lock);
+
+if (!machine_is(pseries))
+return 0;
What's the point of this if check if you return 0 either way?
Yes, it seems a bit odd here, but in patches later in this series I
add additional initialization steps after the machine_is() check
such that it makes sense to bail out here if the check fails.
+
+return 0;
+}
+__initcall(pseries_dlpar_init);
Index: powerpc/arch/powerpc/platforms/pseries/reconfig.c
===
--- powerpc.orig/arch/powerpc/platforms/pseries/reconfig.c2009-09-11
12:43:39.0 -0500
+++ powerpc/arch/powerpc/platforms/pseries/reconfig.c2009-09-11
12:51:52.0 -0500
@@ -95,7 +95,7 @@
return parent;
}
-static BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
+struct blocking_notifier_head pSeries_reconfig_chain =
BLOCKING_NOTIFIER_INIT(pSeries_reconfig_chain);
Can't this just be?
BLOCKING_NOTIFIER_HEAD(pSeries_reconfig_chain);
I think I tried this and was having issues, I don't remember what they
were though. I will try to fix this in the updated patch.
-Nathan Fontenot
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RFC: delete UART current-speed from 4xx DTS?
One of the guys here was getting a messed up console on a bamboo board (on linux boot), which he traced to the fact that the default dts has a 9600 baudrate coded into it (board was running 115k2, not 9600). Either deleting the line, or replacing the 9600 with zero fixed the problem. Looking at the Fsl boards, it seems that 99% of them don't list any current-speed at all. I'm willing to whip up a patch to delete them from the various boards, but I thought I'd check 1st to see if there was some other reasoning/input. I suppose one could argue that u-boot should be replacing the 9600 with 115k2 on the fly, but if the explicit specification isn't helping anyone, then it probably just makes sense to delete them anyway, I figured. Here is the subset of boards I was considering deleting the lines from: bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts sequoia.dts taishan.dts walnut.dts yosemite.dts Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/5] move of_drconf_cell definition to prom.h
Nathan Fontenot wrote:
Move the definition of the of_drconf_cell struct from numa.c to prom.h.
This
is needed so that we can parse the ibm,dynamic-memory device-tree property
when DLPAR adding and removing memory.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
Index: powerpc/arch/powerpc/include/asm/prom.h
===
--- powerpc.orig/arch/powerpc/include/asm/prom.h2009-09-11
12:43:39.0 -0500
+++ powerpc/arch/powerpc/include/asm/prom.h2009-09-11
12:52:11.0 -0500
@@ -349,6 +349,18 @@
*/
extern void __iomem *of_iomap(struct device_node *device, int index);
+struct of_drconf_cell {
+u64base_addr;
+u32drc_index;
+u32reserved;
+u32aa_index;
+u32flags;
+};
Might as well fix this up to use a tab instead of spaces for the indentation
if you are moving it.
+
+#define DRCONF_MEM_ASSIGNED0x0008
+#define DRCONF_MEM_AI_INVALID0x0040
+#define DRCONF_MEM_RESERVED0x0080
+
/*
* NB: This is here while we transition from using asm/prom.h
* to linux/of.h
Index: powerpc/arch/powerpc/mm/numa.c
===
--- powerpc.orig/arch/powerpc/mm/numa.c2009-09-11 12:43:39.0
-0500
+++ powerpc/arch/powerpc/mm/numa.c2009-09-11 12:52:11.0 -0500
@@ -296,18 +296,6 @@
return result;
}
-struct of_drconf_cell {
-u64base_addr;
-u32drc_index;
-u32reserved;
-u32aa_index;
-u32flags;
-};
-
-#define DRCONF_MEM_ASSIGNED0x0008
-#define DRCONF_MEM_AI_INVALID0x0040
-#define DRCONF_MEM_RESERVED0x0080
-
/*
* Read the next lmb list entry from the ibm,dynamic-memory property
* and return the information in the provided of_drconf_cell structure.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] kernel handling of CPU DLPAR
Nathan Fontenot wrote:
+static ssize_t cpu_probe_store(struct class *class, const char *buf,
+ size_t count)
+{
+struct device_node *dn;
+u32 drc_index;
+char *cpu_name;
+int rc;
+
+drc_index = simple_strtoull(buf, NULL, 0);
Can just use simple_strtoul here instead.
+if (!drc_index)
+return -EINVAL;
+
+rc = acquire_drc(drc_index);
+if (rc)
+return rc;
+
+dn = configure_connector(drc_index);
+if (!dn) {
+release_drc(drc_index);
+return rc;
+}
+
+/* fixup dn name */
+cpu_name = kzalloc(strlen(dn-full_name) + strlen(/cpus/) + 1,
+ GFP_KERNEL);
+sprintf(cpu_name, /cpus/%s, dn-full_name);
+kfree(dn-full_name);
+dn-full_name = cpu_name;
+
+rc = add_device_tree_nodes(dn);
+if (rc)
+release_drc(drc_index);
+
+return rc ? rc : count;
+}
+
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] pSeries: cede latency specifier helper function.
On Tue, 2009-09-15 at 17:37 +0530, Gautham R Shenoy wrote:
// Used to pass parms from the OS to PLIC for SetAsrAndRfid
u64 saved_gpr3; // Saved GPR3
x20-x27
u64 saved_gpr4; // Saved GPR4
x28-x2F
- u64 saved_gpr5; // Saved GPR5
x30-x37
+ union {
+ u64 saved_gpr5; // Saved GPR5
x30-x37
+ struct {
+ u8 cede_latency_hint; // x30
+ u8 reserved[7];//
x31-x36
+ } fields;
+ } gpr5_dword;
+
u8 dtl_enable_mask;// Dispatch Trace Log mask
x38-x38
u8 donate_dedicated_cpu; // Donate dedicated CPU cycles
x39-x39
Could you drop the C99 style comments (use /* */ instead)? If you run
checkpatch on this it will error on these lines..
Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
* Peter Zijlstra a.p.zijls...@chello.nl [2009-09-15 14:11:41]: On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote: This patchset contains the offline state driver implemented for pSeries. For pSeries, we define three available_hotplug_states. They are: online: The processor is online. offline: This is the the default behaviour when the cpu is offlined even in the absense of this driver. The CPU would call make an rtas_stop_self() call and hand over the CPU back to the resource pool, thereby effectively deallocating that vCPU from the LPAR. NOTE: This would result in a configuration change to the LPAR which is visible to the outside world. inactive: This cedes the vCPU to the hypervisor with a cede latency specifier value 2. NOTE: This option does not result in a configuration change and the vCPU would be still entitled to the LPAR to which it earlier belong to. Any feedback on the patchset will be immensely valuable. I still think its a layering violation... its the hypervisor manager that should be bothered in what state an off-lined cpu is in. From a design standpoint where we stand today is 1. A cede indicates that the CPU is no longer needed and can be reassigned (remember we do dedicated CPU partitions in power) 2. What this patch is trying to do is to say We don't need the CPU, but please don't reassign, put it to sleep We work the same way with the hypervisor, that applications work with the OS today, by providing madvise and other hints. -- Balbir ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: One of the guys here was getting a messed up console on a bamboo board (on linux boot), which he traced to the fact that the default dts has a 9600 baudrate coded into it (board was running 115k2, not 9600). Either deleting the line, or replacing the 9600 with zero fixed the problem. Once booted, was there a valid current-speed property in /proc/device-tree for the serial node? I'm curious if U-Boot created it, or if the kernel just used whatever baud was present already. When I did the bamboo port a while ago, I recall having issues with either a missing clock-frequency or current-speed (or both perhaps) and the bootloader on the board was the original PIBS. It might have been an issue with PIBS but I'm guessing the rest of the 4xx boards copied from either Ebony or Bamboo in their ports and hence contain that property. Looking at the Fsl boards, it seems that 99% of them don't list any current-speed at all. I'm willing to whip up a patch to delete them I think 99% of them use U-Boot, which should fix things up either way. from the various boards, but I thought I'd check 1st to see if there was some other reasoning/input. I suppose one could argue that u-boot should be replacing the 9600 with 115k2 on the fly, but if the explicit specification isn't helping anyone, then it probably just makes sense to delete them anyway, I figured. Yeah, that's probably valid. I'd be happy to test on the set of boards I have. Here is the subset of boards I was considering deleting the lines from: bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts sequoia.dts taishan.dts walnut.dts yosemite.dts I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few of the 405 boards I have as well. It's easy enough for me to whip up a patch, and since I'll be testing either way I'd be happy to do that if you'd like. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Tue, 15 Sep 2009, Benjamin Herrenschmidt wrote: So I don't know at this stage how to generate a clean pull request ... It's rare, for but future reference, what you can do is to just do a merge in a temporary branch, and get it that way. 'git shortlog' should have worked, though. It's only the 'diff' that is based on the direct difference between two end-points, rather than based on working with intersections of sets of commits. Maybe the scripts use 'origin...master' or something for the shortlog, and then the merge-base thing will confuse it? Haven't looked. In any case, the tree is still there waiting for you to pull. It seems to merge cleanly tonight though I haven't yet got a chance to test the result much. It got a conflict with the AGP merge, but I fixed it up in what _seemed_ to be the obvious manner. But somebody should check out the resulting drivers/char/agp/uninorth-agp.c file. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Driver for using MPC8572's eTSEC12 in 16b encoded FIFO Mode?
On the MPC8572, eTSEC1 and eTSEC2 can be configured to jointly operate in 16-bit encoded FIFO mode. Is there currently a Linux driver for interfacing with this FIFO mode? Thanks, Christopher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote: On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: One of the guys here was getting a messed up console on a bamboo board I meant to say Yosemite board (and hence u-boot), sorry for that. It gives garbage up until the udbg - ttyS0 handover, at which point the console=ttyS0,115200 fixes things. (on linux boot), which he traced to the fact that the default dts has a 9600 baudrate coded into it (board was running 115k2, not 9600). Either deleting the line, or replacing the 9600 with zero fixed the problem. Once booted, was there a valid current-speed property in /proc/device-tree for the serial node? I'm curious if U-Boot created it, or if the kernel just used whatever baud was present already. Had to go back to get this info; it turns out there is a valid prop in all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600). When I did the bamboo port a while ago, I recall having issues with either a missing clock-frequency or current-speed (or both perhaps) and the bootloader on the board was the original PIBS. It might have been an issue with PIBS but I'm guessing the rest of the 4xx boards copied from either Ebony or Bamboo in their ports and hence contain that property. Right - so there could still perhaps be the same issue with PIBS/bamboo present that you saw earlier (given my inability to keep board names straight) Looking at the Fsl boards, it seems that 99% of them don't list any current-speed at all. I'm willing to whip up a patch to delete them I think 99% of them use U-Boot, which should fix things up either way. This is the interesting part -- being a yosemite (u-boot), I would have thought so as well. I've not looked at the u-boot code, but it may only add a current-speed if there isn't one yet. At least that is what the behaviour tends to indicate. Board is running u-boot 1.3.3 so what we are seeing here may not reflect what current u-boot code is doing anyway... from the various boards, but I thought I'd check 1st to see if there was some other reasoning/input. I suppose one could argue that u-boot should be replacing the 9600 with 115k2 on the fly, but if the explicit specification isn't helping anyone, then it probably just makes sense to delete them anyway, I figured. Yeah, that's probably valid. I'd be happy to test on the set of boards I have. Here is the subset of boards I was considering deleting the lines from: bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts sequoia.dts taishan.dts walnut.dts yosemite.dts I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few of the 405 boards I have as well. It's easy enough for me to whip up a patch, and since I'll be testing either way I'd be happy to do that if you'd like. Sure -- the testing effort will be greater than the time to make the patch, so you doing coverage on all those would be great. I think I've probably only got easy immediate access to a PIBS/bamboo at the moment. We already know the yosemite is OK with the change, so that is one less to test. Thanks, Paul. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: delete UART current-speed from 4xx DTS?
On Tue, Sep 15, 2009 at 03:32:05PM -0400, Paul Gortmaker wrote: [Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote: On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: One of the guys here was getting a messed up console on a bamboo board I meant to say Yosemite board (and hence u-boot), sorry for that. It gives garbage up until the udbg - ttyS0 handover, at which point the console=ttyS0,115200 fixes things. Ok. (on linux boot), which he traced to the fact that the default dts has a 9600 baudrate coded into it (board was running 115k2, not 9600). Either deleting the line, or replacing the 9600 with zero fixed the problem. Once booted, was there a valid current-speed property in /proc/device-tree for the serial node? I'm curious if U-Boot created it, or if the kernel just used whatever baud was present already. Had to go back to get this info; it turns out there is a valid prop in all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600). Sorry, that was after you removed the property in the DTS entirely, or setting it to 0, or just using the existing DTS as-is? I should have phrased my question better, but I think I answered it myself already. In my brief test with Sequoia and Bamboo, I removed the current-speed property entirely and once booted there was no property in the serial node, which is what I would expect for the old version of U-Boot on these boards. The good news is that it seems to work fine :). When I did the bamboo port a while ago, I recall having issues with either a missing clock-frequency or current-speed (or both perhaps) and the bootloader on the board was the original PIBS. It might have been an issue with PIBS but I'm guessing the rest of the 4xx boards copied from either Ebony or Bamboo in their ports and hence contain that property. Right - so there could still perhaps be the same issue with PIBS/bamboo present that you saw earlier (given my inability to keep board names straight) OK. I'll be sure to test PIBS. Looking at the Fsl boards, it seems that 99% of them don't list any current-speed at all. I'm willing to whip up a patch to delete them I think 99% of them use U-Boot, which should fix things up either way. This is the interesting part -- being a yosemite (u-boot), I would have thought so as well. I've not looked at the u-boot code, but it may only add a current-speed if there isn't one yet. At least that is what the behaviour tends to indicate. Board is running u-boot 1.3.3 so what we are seeing here may not reflect what current u-boot code is doing anyway... Yeah, 1.3.3 is pretty old. However, I _think_ the kernel will just leave the baud rate alone entirely without a current-speed property and without console=ttyS0,baud rate. Example: linux:/proc/device-tree/plb/opb/ser...@ef600300 # ls clock-frequency device_type interrupts reg compatible interrupt-parent namevirtual-reg linux:/proc/device-tree/plb/opb/ser...@ef600300 # cat /proc/cmdline rootdelay=15 root=/dev/sda1 rw ip=off linux:/proc/device-tree/plb/opb/ser...@ef600300 # uname -a Linux linux 2.6.31 #4 Tue Sep 15 16:57:49 UTC 2009 ppc ppc ppc GNU/Linux linux:/proc/device-tree/plb/opb/ser...@ef600300 # cat /proc/cpuinfo processor : 0 cpu : 440EP Rev. B clock : 399.96MHz revision: 24.211 (pvr 4222 18d3) bogomips: 799.99 timebase: 39996 platform: PowerPC 44x Platform model : amcc,bamboo Memory : 191 MB linux:/proc/device-tree/plb/opb/ser...@ef600300 # I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's a tree name) with PIBS, sequoia, taishan, yosemite, and walnut. Perhaps a few of the 405 boards I have as well. It's easy enough for me to whip up a patch, and since I'll be testing either way I'd be happy to do that if you'd like. Sure -- the testing effort will be greater than the time to make the patch, so you doing coverage on all those would be great. I think I've probably only got easy immediate access to a PIBS/bamboo at the moment. We already know the yosemite is OK with the change, so that is one less to test. OK, sounds good. I'll do some more testing over the next few days and post a patch. Thanks for bringing this to
Re: RFC: delete UART current-speed from 4xx DTS?
[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 16:02) Josh Boyer wrote: On Tue, Sep 15, 2009 at 03:32:05PM -0400, Paul Gortmaker wrote: [Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote: On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: One of the guys here was getting a messed up console on a bamboo board I meant to say Yosemite board (and hence u-boot), sorry for that. It gives garbage up until the udbg - ttyS0 handover, at which point the console=ttyS0,115200 fixes things. Ok. (on linux boot), which he traced to the fact that the default dts has a 9600 baudrate coded into it (board was running 115k2, not 9600). Either deleting the line, or replacing the 9600 with zero fixed the problem. Once booted, was there a valid current-speed property in /proc/device-tree for the serial node? I'm curious if U-Boot created it, or if the kernel just used whatever baud was present already. Had to go back to get this info; it turns out there is a valid prop in all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600). Sorry, that was after you removed the property in the DTS entirely, or setting it to 0, or just using the existing DTS as-is? I should have phrased my question better, but I think I answered it myself already. In my brief test with Sequoia and Bamboo, I removed the current-speed property entirely and once booted there was no property in the serial node, which is what I would expect for the old version of U-Boot on these boards. The good news is that it seems to work fine :). Yep - and if there is a node with a current-speed that differs from what u-boot (1.3.3) is actively using, that current-speed setting will take precedence for early printk and also that baud will appear in the /proc/device-tree (just to clarify on what I'd tried to convey earlier). [...] It's easy enough for me to whip up a patch, and since I'll be testing either way I'd be happy to do that if you'd like. Sure -- the testing effort will be greater than the time to make the patch, so you doing coverage on all those would be great. I think I've probably only got easy immediate access to a PIBS/bamboo at the moment. We already know the yosemite is OK with the change, so that is one less to test. OK, sounds good. I'll do some more testing over the next few days and post a patch. Thanks for bringing this to my attention. No problem; thanks for the quick response and volunteering to test on the boards you have. Paul. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
Hi Ben, On 09/11/2009 12:17 AM, Benjamin Herrenschmidt wrote: This is the powerpc batch for 2.6.32. Will we ever get this one in... http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073567.html -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 0/7] Suspend/resume support for some 83xx/85xx/86xx boards
On Tue, Sep 15, 2009 at 01:47:36AM +0400, Anton Vorontsov wrote: On Mon, Sep 14, 2009 at 03:45:10PM -0500, Scott Wood wrote: [...] You can't request the firmware in the qe driver's -suspend() routine necause the firmware may be on e.g. NFS filesystem or USB stick (implies having QE Ethernet or QE USB fully functional). Is there any way for software to read out the current firmware from the device, or is it write-only? Hm, I didn't look into iram stuff that much, but seemingly I can read it back and save. In the end, it's just a ram that we access in a weird way... Let me try it. Okay... that might sound silly, but the microcode stuff isn't needed at all. While the QE really shuts down, its iram is preserved. I'm not sure why it didn't work for me before, but now it does work. Heh. Note that QE reset is still needed, it's QE microcode reload that we don't need. I was also curious if MPC8568 QE needs reset after sleep, so I unpacked the board and tested it. It needs the reset just as MPC8569. I also found a paragraph in reference manual that somewhat proves QE turns off during sleep behaviour. So here is a new patch set. Changes: - Removed QE stuff from fsl_pmc; - New patches added: powerpc/qe: QE also shuts down on MPC8568 powerpc/qe: Implement QE driver for handling resume on MPC85xx Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/7] powerpc/qe: Make qe_reset() code path safe for repeated invocation
For MPC8569 CPUs we'll need to reset QE after each suspend, so make
qe_reset() code path suitable for repeated invocation, that is:
- Don't initialize rheap structures if already initialized;
- Don't allocate muram for SDMA if already allocated, just reinitialize
registers with previously allocated muram offset;
- Remove __init attributes from qe_reset() and cpm_muram_init();
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/include/asm/qe.h|2 +-
arch/powerpc/sysdev/cpm_common.c |5 -
arch/powerpc/sysdev/qe_lib/qe.c | 12 +++-
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 20c0b07..fe507ff 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -87,7 +87,7 @@ extern spinlock_t cmxgcr_lock;
/* Export QE common operations */
#ifdef CONFIG_QUICC_ENGINE
-extern void __init qe_reset(void);
+extern void qe_reset(void);
#else
static inline void qe_reset(void) {}
#endif
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index e4b6d66..9de72c9 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -72,7 +72,7 @@ static phys_addr_t muram_pbase;
/* Max address size we deal with */
#define OF_MAX_ADDR_CELLS 4
-int __init cpm_muram_init(void)
+int cpm_muram_init(void)
{
struct device_node *np;
struct resource r;
@@ -81,6 +81,9 @@ int __init cpm_muram_init(void)
int i = 0;
int ret = 0;
+ if (muram_pbase)
+ return 0;
+
spin_lock_init(cpm_muram_lock);
/* initialize the info header */
rh_init(cpm_muram_info, 1,
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index fff2701..1ed1a9f 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -104,7 +104,7 @@ phys_addr_t get_qe_base(void)
EXPORT_SYMBOL(get_qe_base);
-void __init qe_reset(void)
+void qe_reset(void)
{
if (qe_immr == NULL)
qe_immr = ioremap(get_qe_base(), QE_IMMAP_SIZE);
@@ -330,16 +330,18 @@ EXPORT_SYMBOL(qe_put_snum);
static int qe_sdma_init(void)
{
struct sdma __iomem *sdma = qe_immr-sdma;
- unsigned long sdma_buf_offset;
+ static unsigned long sdma_buf_offset = (unsigned long)-ENOMEM;
if (!sdma)
return -ENODEV;
/* allocate 2 internal temporary buffers (512 bytes size each) for
* the SDMA */
- sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
- if (IS_ERR_VALUE(sdma_buf_offset))
- return -ENOMEM;
+ if (IS_ERR_VALUE(sdma_buf_offset)) {
+ sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
+ if (IS_ERR_VALUE(sdma_buf_offset))
+ return -ENOMEM;
+ }
out_be32(sdma-sdebcr, (u32) sdma_buf_offset QE_SDEBCR_BA_MASK);
out_be32(sdma-sdmr, (QE_SDMR_GLB_1_MSK |
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] powerpc/qe: QE also shuts down on MPC8568
It appears that QE shuts down on all MPC85xx CPUs (i.e. MPC8568 and
MPC8569) and thus needs reset upon resume.
So modify qe_alive_during_sleep() to account that.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/include/asm/qe.h | 23 ++-
arch/powerpc/sysdev/qe_lib/qe.c | 13 -
2 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index fe507ff..0947b36 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -163,7 +163,28 @@ int qe_get_snum(void);
void qe_put_snum(u8 snum);
unsigned int qe_get_num_of_risc(void);
unsigned int qe_get_num_of_snums(void);
-int qe_alive_during_sleep(void);
+
+static inline int qe_alive_during_sleep(void)
+{
+ /*
+* MPC8568E reference manual says:
+*
+* ...power down sequence waits for all I/O interfaces to become idle.
+* In some applications this may happen eventually without actively
+* shutting down interfaces, but most likely, software will have to
+* take steps to shut down the eTSEC, QUICC Engine Block, and PCI
+* interfaces before issuing the command (either the write to the core
+* MSR[WE] as described above or writing to POWMGTCSR) to put the
+* device into sleep state.
+*
+* MPC8569E reference manual has a similar paragraph.
+*/
+#ifdef CONFIG_PPC_85xx
+ return 0;
+#else
+ return 1;
+#endif
+}
/* we actually use cpm_muram implementation, define this for convenience */
#define qe_muram_init cpm_muram_init
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 1ed1a9f..4eaf2a9 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -65,19 +65,6 @@ static unsigned int qe_num_of_snum;
static phys_addr_t qebase = -1;
-int qe_alive_during_sleep(void)
-{
- static int ret = -1;
-
- if (ret != -1)
- return ret;
-
- ret = !of_find_compatible_node(NULL, NULL, fsl,mpc8569-pmc);
-
- return ret;
-}
-EXPORT_SYMBOL(qe_alive_during_sleep);
-
phys_addr_t get_qe_base(void)
{
struct device_node *qe;
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] powerpc/qe: Implement QE driver for handling resume on MPC85xx
So far the driver is used to reset QE upon resume, which is needed on
85xx. Later we can move some QE initialization steps into probe().
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/sysdev/qe_lib/qe.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 4eaf2a9..149393c 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -27,6 +27,8 @@
#include linux/delay.h
#include linux/ioport.h
#include linux/crc32.h
+#include linux/mod_devicetable.h
+#include linux/of_platform.h
#include asm/irq.h
#include asm/page.h
#include asm/pgtable.h
@@ -647,3 +649,35 @@ unsigned int qe_get_num_of_snums(void)
return num_of_snums;
}
EXPORT_SYMBOL(qe_get_num_of_snums);
+
+#if defined(CONFIG_SUSPEND) defined(CONFIG_PPC_85xx)
+static int qe_resume(struct of_device *ofdev)
+{
+ if (!qe_alive_during_sleep())
+ qe_reset();
+ return 0;
+}
+
+static int qe_probe(struct of_device *ofdev, const struct of_device_id *id)
+{
+ return 0;
+}
+
+static const struct of_device_id qe_ids[] = {
+ { .compatible = fsl,qe, },
+ { },
+};
+
+static struct of_platform_driver qe_driver = {
+ .driver.name = fsl-qe,
+ .match_table = qe_ids,
+ .probe = qe_probe,
+ .resume = qe_resume,
+};
+
+static int __init qe_drv_init(void)
+{
+ return of_register_platform_driver(qe_driver);
+}
+device_initcall(qe_drv_init);
+#endif /* defined(CONFIG_SUSPEND) defined(CONFIG_PPC_85xx) */
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/7] powerpc/85xx/86xx: Add suspend/resume support
This patch adds suspend/resume support for MPC8540 and MPC8641D-
compatible CPUs. To reach sleep state, we just write the SLP bit
into the PM control and status register.
So far we don't support Deep Sleep mode as found in newer MPC85xx
CPUs (i.e. MPC8536). It can be relatively easy implemented though,
and for it we reserve 'mem' suspend type.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Acked-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/Kconfig | 11 +-
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_pmc.c | 88 +
3 files changed, 99 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_pmc.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d00131c..a0743a7 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -212,7 +212,8 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
+ PPC_85xx || PPC_86xx
config PPC_DCR_NATIVE
bool
@@ -642,6 +643,14 @@ config FSL_PCI
select PPC_INDIRECT_PCI
select PCI_QUIRKS
+config FSL_PMC
+ bool
+ default y
+ depends on SUSPEND (PPC_85xx || PPC_86xx)
+ help
+ Freescale MPC85xx/MPC86xx power management controller support
+ (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
+
config 4xx_SOC
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 9d4b174..5642924 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
+obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
diff --git a/arch/powerpc/sysdev/fsl_pmc.c b/arch/powerpc/sysdev/fsl_pmc.c
new file mode 100644
index 000..a7635a9
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_pmc.c
@@ -0,0 +1,88 @@
+/*
+ * Suspend/resume support
+ *
+ * Copyright 2009 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov avoront...@ru.mvista.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/init.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/suspend.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/of_platform.h
+
+struct pmc_regs {
+ __be32 devdisr;
+ __be32 devdisr2;
+ __be32 :32;
+ __be32 :32;
+ __be32 pmcsr;
+#define PMCSR_SLP (1 17)
+};
+
+static struct device *pmc_dev;
+static struct pmc_regs __iomem *pmc_regs;
+
+static int pmc_suspend_enter(suspend_state_t state)
+{
+ int ret;
+
+ setbits32(pmc_regs-pmcsr, PMCSR_SLP);
+ /* At this point, the CPU is asleep. */
+
+ /* Upon resume, wait for SLP bit to be clear. */
+ ret = spin_event_timeout((in_be32(pmc_regs-pmcsr) PMCSR_SLP) == 0,
+1, 10) ? 0 : -ETIMEDOUT;
+ if (ret)
+ dev_err(pmc_dev, tired waiting for SLP bit to clear\n);
+ return ret;
+}
+
+static int pmc_suspend_valid(suspend_state_t state)
+{
+ if (state != PM_SUSPEND_STANDBY)
+ return 0;
+ return 1;
+}
+
+static struct platform_suspend_ops pmc_suspend_ops = {
+ .valid = pmc_suspend_valid,
+ .enter = pmc_suspend_enter,
+};
+
+static int pmc_probe(struct of_device *ofdev, const struct of_device_id *id)
+{
+ pmc_regs = of_iomap(ofdev-node, 0);
+ if (!pmc_regs)
+ return -ENOMEM;
+
+ pmc_dev = ofdev-dev;
+ suspend_set_ops(pmc_suspend_ops);
+ return 0;
+}
+
+static const struct of_device_id pmc_ids[] = {
+ { .compatible = fsl,mpc8548-pmc, },
+ { .compatible = fsl,mpc8641d-pmc, },
+ { },
+};
+
+static struct of_platform_driver pmc_driver = {
+ .driver.name = fsl-pmc,
+ .match_table = pmc_ids,
+ .probe = pmc_probe,
+};
+
+static int __init pmc_init(void)
+{
+ return of_register_platform_driver(pmc_driver);
+}
+device_initcall(pmc_init);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/7] powerpc/85xx: Add power management support for MPC85xxMDS boards
- Add power management controller nodes;
- Add interrupts for RTC nodes, the RTC interrupt may be used as a
wakeup source;
- Add sleep properties and sleep-nexus nodes.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Acked-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/boot/dts/mpc8568mds.dts | 119 +++--
arch/powerpc/boot/dts/mpc8569mds.dts | 111 ++-
arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 +
3 files changed, 153 insertions(+), 78 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 00c2bbd..6d892ba 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -40,6 +40,8 @@
i-cache-line-size = 32; // 32 bytes
d-cache-size = 0x8000;// L1, 32K
i-cache-size = 0x8000;// L1, 32K
+ sleep = pmc 0x8000// core
+pmc 0x4000; // timebase
timebase-frequency = 0;
bus-frequency = 0;
clock-frequency = 0;
@@ -94,31 +96,41 @@
interrupts = 16 2;
};
- i...@3000 {
+ i2c-sleep-nexus {
#address-cells = 1;
- #size-cells = 0;
- cell-index = 0;
- compatible = fsl-i2c;
- reg = 0x3000 0x100;
- interrupts = 43 2;
- interrupt-parent = mpic;
- dfsrr;
+ #size-cells = 1;
+ compatible = simple-bus;
+ sleep = pmc 0x0004;
+ ranges;
- r...@68 {
- compatible = dallas,ds1374;
- reg = 0x68;
+ i...@3000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+
+ r...@68 {
+ compatible = dallas,ds1374;
+ reg = 0x68;
+ interrupts = 3 1;
+ interrupt-parent = mpic;
+ };
};
- };
- i...@3100 {
- #address-cells = 1;
- #size-cells = 0;
- cell-index = 1;
- compatible = fsl-i2c;
- reg = 0x3100 0x100;
- interrupts = 43 2;
- interrupt-parent = mpic;
- dfsrr;
+ i...@3100 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
};
d...@21300 {
@@ -128,6 +140,8 @@
reg = 0x21300 0x4;
ranges = 0x0 0x21100 0x200;
cell-index = 0;
+ sleep = pmc 0x0400;
+
dma-chan...@0 {
compatible = fsl,mpc8568-dma-channel,
fsl,eloplus-dma-channel;
@@ -176,6 +190,7 @@
interrupt-parent = mpic;
tbi-handle = tbi0;
phy-handle = phy2;
+ sleep = pmc 0x0080;
m...@520 {
#address-cells = 1;
@@ -228,6 +243,7 @@
interrupt-parent = mpic;
tbi-handle = tbi1;
phy-handle = phy3;
+ sleep = pmc 0x0040;
m...@520 {
#address-cells = 1;
@@ -242,30 +258,47 @@
};
};
- serial0: ser...@4500 {
- cell-index = 0;
- device_type = serial;
- compatible = ns16550;
- reg = 0x4500 0x100;
-
[PATCH 6/7] powerpc/86xx: Add power management support for MPC8610HPCD boards
This patch adds needed nodes and properties to support suspend/resume
on the MPC8610HPCD boards.
There is a dedicated switch (SW9) that is used to wake up the boards.
By default the SW9 button is routed to IRQ8, but could be re-routed
(via PIXIS) to sreset.
With 'no_console_suspend' kernel command line argument specified, the
board is also able to wakeup upon serial port input.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Acked-by: Scott Wood scottw...@freescale.com [dts]
---
Documentation/powerpc/dts-bindings/fsl/board.txt |4 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 26
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 48 --
3 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt
b/Documentation/powerpc/dts-bindings/fsl/board.txt
index e8b5bc2..39e9415 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt
@@ -20,12 +20,16 @@ Required properities:
- compatible : should be fsl,fpga-pixis.
- reg : should contain the address and the length of the FPPGA register
set.
+- interrupt-parent: should specify phandle for the interrupt controller.
+- interrupts : should specify event (wakeup) IRQ.
Example (MPC8610HPCD):
board-cont...@e800 {
compatible = fsl,fpga-pixis;
reg = 0xe800 32;
+ interrupt-parent = mpic;
+ interrupts = 8 8;
};
* Freescale BCSR GPIO banks
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index f468d21..9535ce6 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -35,6 +35,8 @@
i-cache-line-size = 32;
d-cache-size = 32768; // L1
i-cache-size = 32768; // L1
+ sleep = pmc 0x8000 0 // core
+pmc 0x4000 0;// timebase
timebase-frequency = 0; // From uboot
bus-frequency = 0;// From uboot
clock-frequency = 0; // From uboot
@@ -60,6 +62,7 @@
5 0 0xe848 0x8000
6 0 0xe84c 0x8000
3 0 0xe800 0x0020;
+ sleep = pmc 0x0800 0;
fl...@0,0 {
compatible = cfi-flash;
@@ -105,6 +108,8 @@
compatible = fsl,fpga-pixis;
reg = 3 0 0x20;
ranges = 0 3 0 0x20;
+ interrupt-parent = mpic;
+ interrupts = 8 8;
sdcsr_pio: gpio-control...@a {
#gpio-cells = 2;
@@ -163,6 +168,7 @@
reg = 0x3100 0x100;
interrupts = 43 2;
interrupt-parent = mpic;
+ sleep = pmc 0x0004 0;
dfsrr;
};
@@ -174,6 +180,7 @@
clock-frequency = 0;
interrupts = 42 2;
interrupt-parent = mpic;
+ sleep = pmc 0x0002 0;
};
serial1: ser...@4600 {
@@ -184,6 +191,7 @@
clock-frequency = 0;
interrupts = 42 2;
interrupt-parent = mpic;
+ sleep = pmc 0x0008 0;
};
s...@7000 {
@@ -196,6 +204,7 @@
interrupt-parent = mpic;
mode = cpu;
gpios = sdcsr_pio 7 0;
+ sleep = pmc 0x0800 0;
mmc-s...@0 {
compatible = fsl,mpc8610hpcd-mmc-slot,
@@ -213,6 +222,7 @@
reg = 0x2c000 100;
interrupts = 72 2;
interrupt-parent = mpic;
+ sleep = pmc 0x0400 0;
};
mpic: interrupt-control...@4 {
@@ -241,9 +251,18 @@
};
global-utilit...@e {
+ #address-cells = 1;
+ #size-cells = 1;
compatible = fsl,mpc8610-guts;
reg = 0xe 0x1000;
+ ranges = 0 0xe 0x1000;
fsl,has-rstcr;
+
+ pmc: po...@70 {
+ compatible = fsl,mpc8610-pmc,
+fsl,mpc8641d-pmc;
+ reg = 0x70 0x20;
+ };
};
w...@e4000 {
@@ -262,6 +281,7 @@
[PATCH 7/7] powerpc/83xx: Add power management support for MPC83xx QE boards
Simply add power management controller nodes and sleep properties.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Acked-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/boot/dts/kmeter1.dts |7 +++
arch/powerpc/boot/dts/mpc832x_mds.dts |9 +
arch/powerpc/boot/dts/mpc832x_rdb.dts |9 +
arch/powerpc/boot/dts/mpc836x_mds.dts |9 +
arch/powerpc/boot/dts/mpc836x_rdk.dts |9 +
5 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/kmeter1.dts
b/arch/powerpc/boot/dts/kmeter1.dts
index 167044f..65b8b4f 100644
--- a/arch/powerpc/boot/dts/kmeter1.dts
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -59,6 +59,13 @@
reg = 0xe000 0x0200;
bus-frequency = 0;/* Filled in by U-Boot */
+ pmc: po...@b00 {
+ compatible = fsl,mpc8360-pmc, fsl,mpc8349-pmc;
+ reg = 0xb00 0x100 0xa00 0x100;
+ interrupts = 80 0x8;
+ interrupt-parent = ipic;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index 436c9c6..05ad8c9 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -79,6 +79,13 @@
reg = 0x200 0x100;
};
+ pmc: po...@b00 {
+ compatible = fsl,mpc8323-pmc, fsl,mpc8349-pmc;
+ reg = 0xb00 0x100 0xa00 0x100;
+ interrupts = 80 0x8;
+ interrupt-parent = ipic;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
@@ -163,6 +170,7 @@
fsl,channel-fifo-len = 24;
fsl,exec-units-mask = 0x4c;
fsl,descriptor-types-mask = 0x0122003f;
+ sleep = pmc 0x0300;
};
ipic: p...@700 {
@@ -428,5 +436,6 @@
0xe0008300 0x8; /* config space access
registers */
compatible = fsl,mpc8349-pci;
device_type = pci;
+ sleep = pmc 0x0001;
};
};
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 9a0952f..f4fadb2 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -62,6 +62,13 @@
reg = 0x200 0x100;
};
+ pmc: po...@b00 {
+ compatible = fsl,mpc8323-pmc, fsl,mpc8349-pmc;
+ reg = 0xb00 0x100 0xa00 0x100;
+ interrupts = 80 0x8;
+ interrupt-parent = ipic;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
@@ -141,6 +148,7 @@
fsl,channel-fifo-len = 24;
fsl,exec-units-mask = 0x4c;
fsl,descriptor-types-mask = 0x0122003f;
+ sleep = pmc 0x0300;
};
ipic:p...@700 {
@@ -360,5 +368,6 @@
0xe0008300 0x8; /* config space access
registers */
compatible = fsl,mpc8349-pci;
device_type = pci;
+ sleep = pmc 0x0001;
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 39ff4c8..45cfa1c 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -99,6 +99,13 @@
reg = 0x200 0x100;
};
+ pmc: po...@b00 {
+ compatible = fsl,mpc8360-pmc, fsl,mpc8349-pmc;
+ reg = 0xb00 0x100 0xa00 0x100;
+ interrupts = 80 0x8;
+ interrupt-parent = ipic;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
@@ -194,6 +201,7 @@
fsl,channel-fifo-len = 24;
fsl,exec-units-mask = 0x7e;
fsl,descriptor-types-mask = 0x01010ebf;
+ sleep = pmc 0x0300;
};
ipic: p...@700 {
@@ -470,5 +478,6 @@
0xe0008300 0x8; /* config space access
registers */
compatible = fsl,mpc8349-pci;
device_type = pci;
+ sleep = pmc 0x0001;
};
};
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index 6315d6f..bdf4459 100644
---
Re: RFC: delete UART current-speed from 4xx DTS?
On Tue, 2009-09-15 at 11:32 -0400, Josh Boyer wrote: On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote: One of the guys here was getting a messed up console on a bamboo board (on linux boot), which he traced to the fact that the default dts has a 9600 baudrate coded into it (board was running 115k2, not 9600). Either deleting the line, or replacing the 9600 with zero fixed the problem. Once booted, was there a valid current-speed property in /proc/device-tree for the serial node? I'm curious if U-Boot created it, or if the kernel just used whatever baud was present already. When I did the bamboo port a while ago, I recall having issues with either a missing clock-frequency or current-speed (or both perhaps) and the bootloader on the board was the original PIBS. It might have been an issue with PIBS but I'm guessing the rest of the 4xx boards copied from either Ebony or Bamboo in their ports and hence contain that property. I think I recently added code to legacy_serial probe the speed from the HW if the property is absent, which should help. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Tue, 2009-09-15 at 09:53 -0700, Linus Torvalds wrote: It got a conflict with the AGP merge, but I fixed it up in what _seemed_ to be the obvious manner. But somebody should check out the resulting drivers/char/agp/uninorth-agp.c file. Thanks. Michel, can you dbl check it ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Pravin Bathija pbath...@amcc.com
Powerpc 44x uses 36 bit real address while the real address defined
in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and driver
fails to initialize. This fix changes the data types representing the real
address from unsigned long 32-bit types to phys_addr_t which is 64-bit. The
driver has been tested, the disks get discovered correctly and can do IO. Also,
replaced phys_addr_t with resource_size_t as suggested by Ben.
Signed-off-by: Pravin Bathija pbath...@amcc.com
Acked-by: Feng Kan f...@amcc.com
Acked-by: Prodyut Hazarika phazar...@amcc.com
Acked-by: Loc Ho l...@amcc.com
Acked-by: Tirumala Reddy Marri tma...@amcc.com
Acked-by: Victor Gallardo vgalla...@amcc.com
---
drivers/message/fusion/mptbase.c | 34 +-
drivers/message/fusion/mptbase.h |5 +++--
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 5d496a9..e296f2e 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1510,11 +1510,12 @@ static int
mpt_mapresources(MPT_ADAPTER *ioc)
{
u8 __iomem *mem;
+ u8 __iomem *port;
int ii;
- unsigned longmem_phys;
- unsigned longport;
- u32 msize;
- u32 psize;
+ resource_size_t mem_phys;
+ resource_size_t port_phys;
+ resource_size_t msize;
+ resource_size_t psize;
u8 revision;
int r = -ENODEV;
struct pci_dev *pdev;
@@ -1552,13 +1553,13 @@ mpt_mapresources(MPT_ADAPTER *ioc)
}
mem_phys = msize = 0;
- port = psize = 0;
+ port_phys = psize = 0;
for (ii = 0; ii DEVICE_COUNT_RESOURCE; ii++) {
if (pci_resource_flags(pdev, ii) PCI_BASE_ADDRESS_SPACE_IO) {
if (psize)
continue;
/* Get I/O space! */
- port = pci_resource_start(pdev, ii);
+ port_phys = pci_resource_start(pdev, ii);
psize = pci_resource_len(pdev, ii);
} else {
if (msize)
@@ -1580,14 +1581,23 @@ mpt_mapresources(MPT_ADAPTER *ioc)
return -EINVAL;
}
ioc-memmap = mem;
- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT mem = %p, mem_phys = %lx\n,
- ioc-name, mem, mem_phys));
+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT mem = %p, mem_phys = %llx\n,
+ ioc-name, mem, (u64)mem_phys));
ioc-mem_phys = mem_phys;
ioc-chip = (SYSIF_REGS __iomem *)mem;
/* Save Port IO values in case we need to do downloadboot */
- ioc-pio_mem_phys = port;
+ port = ioremap(port_phys, psize);
+ if (port == NULL) {
+ printk(MYIOC_s_ERR_FMT : ERROR - Unable to map adapter
+port !\n, ioc-name);
+ return -EINVAL;
+ }
+ ioc-portmap = port;
+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT port=%p, port_phys=%llx\n,
+ ioc-name, port, (u64)port_phys));
+ ioc-pio_mem_phys = port_phys;
ioc-pio_chip = (SYSIF_REGS __iomem *)port;
return 0;
@@ -1822,6 +1832,7 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
if (ioc-alt_ioc)
ioc-alt_ioc-alt_ioc = NULL;
iounmap(ioc-memmap);
+ iounmap(ioc-portmap);
if (r != -5)
pci_release_selected_regions(pdev, ioc-bars);
@@ -2583,6 +2594,11 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
ioc-memmap = NULL;
}
+ if (ioc-portmap != NULL) {
+ iounmap(ioc-portmap);
+ ioc-portmap = NULL;
+ }
+
pci_disable_device(ioc-pcidev);
pci_release_selected_regions(ioc-pcidev, ioc-bars);
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index b3e981d..7091f13 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -584,8 +584,8 @@ typedef struct _MPT_ADAPTER
SYSIF_REGS __iomem *chip; /* == c8817000 (mmap) */
SYSIF_REGS __iomem *pio_chip; /* Programmed IO (downloadboot)
*/
u8 bus_type;
- u32 mem_phys; /* == f402 (mmap) */
- u32 pio_mem_phys; /* Programmed IO (downloadboot)
*/
+ resource_size_t mem_phys; /* == f402 (mmap) */
+ resource_size_t pio_mem_phys; /* Programmed IO (downloadboot)
*/
int mem_size; /* mmap memory size */
int number_of_buses;
int devices_per_bus;
@@ -635,6 +635,7 @@ typedef
Re: [git pull] Please pull powerpc.git next branch
On Wed, 2009-09-16 at 07:51 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-09-15 at 09:53 -0700, Linus Torvalds wrote: It got a conflict with the AGP merge, but I fixed it up in what _seemed_ to be the obvious manner. But somebody should check out the resulting drivers/char/agp/uninorth-agp.c file. Thanks. Michel, can you dbl check it ? Looks good to me, thanks. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Hang in inflate_dynamic() mpc8321
Hi All, Iam working on the new board bringup of linux ppc image on 2.6.24 using the powerpc mpc832x. I used the file system image (based on the initrd ram disk image), dtb file(generated by the dtc compiler for our mpc832x_rdb.dts) and the kernel powepc compiled. Iam facing a hang up in the booting in the call inflate_dynamic() from the gunzip() function. Initially I suspected it could be RAM issues, and I performed the simple RAM test (mtest) from the bootloader and it went through succesfully. Below is the log message observed in the system booting stuck at checking if image is initramfs... Log messages : - Booting image at 0020 ... Image Name: Linux-2.6.24 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 808788 Bytes = 789.8 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0100 ... Image Name: TESTIMAGE Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1066209 Bytes = 1 MB Load Address: Entry Point: Verifying Checksum ... OK Booting using the fdt at 0x40 Loading Ramdisk to 03ea, end 03fa44e1 ... OK Using MPC832x RDB machine description Linux version 2.6.24 (t...@test-desktop) (gcc version 4.2.1 (Sourcery G++ Lite 4.2-82)) #39 Fri Sep 4 13:04:50 IST 2009 Found initrd at 0xc3ea:0xc3fa44e1 console [udbg0] enabled setup_arch: bootmem mpc832x_rdb_setup_arch() arch: exit Zone PFN ranges: DMA 0 - 16384 Normal 16384 - 16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 - 16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/ram ramdisk_size=20 rw ip=10.0.0.2:10 .0.0.1:10.0.0.1:255.0.0.0:Test:eth1:off console=t tyS0,115200 IPIC (128 IRQ sources) at fdefd700 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[781] shift[22] registered Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 62068k/65536k available (1592k kernel code, 3400k reserved, 88k data, 60k bss, 112k init) Mount-cache hash table entries: 512 SCSI subsystem initialized checking if image is initramfs... Please let me know what could be the problem. Thanks in advance. Regards, kumar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] USB: Add support for Xilinx USB host controller
Add bus glue driver for Xilinx USB host controller. The controller can be
configured as HS only or HS/FS hybrid. The driver uses the device tree file
to configure the driver according to the setting in the hardware system.
This driver has been tested with usbtest using the NET2280 PCI card.
Signed-off-by: Julie Zhu julie@xilinx.com
---
drivers/usb/host/Kconfig | 15 ++-
drivers/usb/host/ehci-hcd.c |5 +
drivers/usb/host/ehci-xilinx-of.c | 303 +
3 files changed, 321 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/host/ehci-xilinx-of.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1a920c7..95e4689 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -90,14 +90,25 @@ config USB_EHCI_TT_NEWSCHED
config USB_EHCI_BIG_ENDIAN_MMIO
bool
- depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX)
+ depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX || XPS_USB_HCD_XILINX)
default y
config USB_EHCI_BIG_ENDIAN_DESC
bool
- depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX)
+ depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX)
default y
+config XPS_USB_HCD_XILINX
+ bool Use Xilinx usb host EHCI controller core
+ depends on USB_EHCI_HCD (PPC32 || MICROBLAZE)
+ select USB_EHCI_BIG_ENDIAN_DESC
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ ---help---
+ Xilinx xps USB host controller core is EHCI compilant and has
+ transaction translator built-in. It can be configured to either
+ support both high speed and full speed devices, or high speed
+ devices only.
+
config USB_EHCI_FSL
bool Support for Freescale on-chip EHCI USB controller
depends on USB_EHCI_HCD FSL_SOC
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 11c627c..7672624 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1107,6 +1107,11 @@ MODULE_LICENSE (GPL);
#define OF_PLATFORM_DRIVER ehci_hcd_ppc_of_driver
#endif
+#ifdef CONFIG_XPS_USB_HCD_XILINX
+#include ehci-xilinx-of.c
+#define OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver
+#endif
+
#ifdef CONFIG_PLAT_ORION
#include ehci-orion.c
#definePLATFORM_DRIVER ehci_orion_driver
diff --git a/drivers/usb/host/ehci-xilinx-of.c
b/drivers/usb/host/ehci-xilinx-of.c
new file mode 100644
index 000..58e1f14
--- /dev/null
+++ b/drivers/usb/host/ehci-xilinx-of.c
@@ -0,0 +1,303 @@
+/*
+ * EHCI HCD (Host Controller Driver) for USB.
+ *
+ * Bus Glue for Xilinx EHCI core on the of_platform bus
+ *
+ * Copyright (c) 2009 Xilinx, Inc.
+ *
+ * Based on ehci-ppc-of.c by Valentine Barshak vbars...@ru.mvista.com
+ * and ehci-ppc-soc.c by Stefan Roese s...@denx.de
+ * and ohci-ppc-of.c by Sylvain Munaut t...@246tnt.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/signal.h
+
+#include linux/of.h
+#include linux/of_platform.h
+
+/**
+ * ehci_xilinx_of_setup - Initialize the device for ehci_reset()
+ * @hcd: Pointer to the usb_hcd device to which the host controller bound
+ *
+ * called during probe() after chip reset completes.
+ */
+static int ehci_xilinx_of_setup(struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ int retval;
+
+ retval = ehci_halt(ehci);
+ if (retval)
+ return retval;
+
+ retval = ehci_init(hcd);
+ if (retval)
+ return retval;
+
+ ehci-sbrn = 0x20;
+
+ return ehci_reset(ehci);
+}
+
+/**
+ * ehci_xilinx_port_handed_over - hand the port out if failed to enable it
+ * @hcd: Pointer to the usb_hcd device to which the host controller bound
+ * @portnum:Port number to which the device is attached.
+ *
+ * This function is used as a place to tell the user that the Xilinx USB host
+ * controller does support LS devices. And in an HS only configuration, it
+ * does not support FS devices neither. It is hoped that this can help a
+ * confused user.
+ *
+ * There are cases when the host controller fails to enable the port due to,
+ * for example, insufficient power that can be supplied to the device from
+ *
Re: [git pull] Please pull powerpc.git next branch
On Tue, 2009-09-15 at 14:09 -0700, Geoff Levand wrote: Hi Ben, On 09/11/2009 12:17 AM, Benjamin Herrenschmidt wrote: This is the powerpc batch for 2.6.32. Will we ever get this one in... http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073567.html I thought it was in. It's marked as Not Applicable in patchwork, possibly because Ben thought you were going to take it. I've marked it as new, so it should get picked up or NAK'ed by Ben. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] dynamic logical partitioning infrastructure
On Fri, 2009-09-11 at 16:10 -0500, Nathan Fontenot wrote:
This patch provides the kernel DLPAR infrastructure in a new filed named
dlpar.c. The functionality provided is for acquiring and releasing a
resource from firmware and the parsing of information returned from the
ibm,configure-connector rtas call. Additionally this exports the
pSeries reconfiguration notifier chain so that it can be invoked when
device tree updates are made.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ powerpc/arch/powerpc/platforms/pseries/dlpar.c2009-09-11
12:51:52.0 -0500
@@ -0,0 +1,416 @@
+/*
+ * dlpar.c - support for dynamic reconfiguration (including PCI
+ * Hotplug and Dynamic Logical Partitioning on RPA platforms).
+ *
+ * Copyright (C) 2009 Nathan Fontenot
+ * Copyright (C) 2009 IBM Corporation
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/kref.h
+#include linux/notifier.h
+#include linux/proc_fs.h
+#include linux/spinlock.h
+
+#include asm/prom.h
+#include asm/machdep.h
+#include asm/uaccess.h
+#include asm/rtas.h
+#include asm/pSeries_reconfig.h
+
+#define CFG_CONN_WORK_SIZE 4096
+static char workarea[CFG_CONN_WORK_SIZE];
+spinlock_t workarea_lock;
+
+static struct property *parse_cc_property(char *workarea)
+{
+ struct property *prop;
+ u32 *work_ints;
+ char *name;
+ char *value;
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ if (!prop)
+ return NULL;
+
+ work_ints = (u32 *)workarea;
+ name = workarea + work_ints[2];
+ prop-name = kzalloc(strlen(name) + 1, GFP_KERNEL);
+ if (!prop-name) {
+ kfree(prop);
+ return NULL;
+ }
+
+ strcpy(prop-name, name);
+
+ prop-length = work_ints[3];
+ value = workarea + work_ints[4];
+ prop-value = kzalloc(prop-length, GFP_KERNEL);
The use of work_ints is a bit opaque, it might be clearer if you define
a struct, something like:
struct cc_prop {
u32 ?;
u32 ?;
u32 name_offset;
u32 length;
u32 value_offset;
};
cc = (struct cc_prop *)workarea;
name = workarea + cc-name_offset;
..
prop-length = cc-length;
value = workarea + cc-value_offset;
etc.
Also I don't see any checking of the offsets into workarea (for name
value), vs the size of workarea.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Driver for using MPC8572's eTSEC12 in 16b encoded FIFO Mode?
On Sep 15, 2009, at 1:37 PM, Christopher Best wrote: On the MPC8572, eTSEC1 and eTSEC2 can be configured to jointly operate in 16-bit encoded FIFO mode. Is there currently a Linux driver for interfacing with this FIFO mode? Not that I'm aware of. You should be able to modify drivers/net/ gianfar.c for this purpose. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
