Re: Long boot delay on 460EX with 2.6.28-rc8
On Friday 19 December 2008, Felix Radensky wrote: > Thanks a lot to everyone who replied. I've managed to identify the cause > of the delay. The board is equipped with 256 MiB Samsung NAND flash. > Since NAND support is a must for this platform, I've intergated the ndfc > driver recently posted by Sean McLennan. With this driver enabled the delay > is present, without it messages appear on the console immediately. > > Is this an expected behavior - detection of 256 MiB NAND flash > takes around 20 seconds. The ndfc driver works fine after boot. No, 20 seconds is definitely too long. Something must be wrong with the ndfc driver or the NAND dts entries. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH 02/11][v2] async_tx: add support for asynchronous GF multiplication
Hello Dan,
On Wednesday, December 17, 2008 you wrote:
[..]
>> + /* DMAs use destinations as sources, so use BIDIRECTIONAL mapping */
>> + dma_dest[0] = !blocks[src_cnt] ? 0 :
>> + dma_map_page(dma->dev, blocks[src_cnt],
>> +offset, len, DMA_BIDIRECTIONAL);
> "0" could be a valid dma address on some architectures.
> DMA_ERROR_CODE looks like the closest fit for what we are trying to do
> here, but that only exists on sparc and powerpc. We could add a
> "dest_mask" parameter to device_prep_dma_pq where the mask is 1 =
> p-only, 2 = q-only, and 3 = p and q.
Understood. We can just introduce new DMA_xxx flags and pass them
among the other ones passed with device_prep_dma_pq() to ADMA driver
instead of introducing a new "dest_mask" parameter. Though, I guess,
you meant exactly the same.
>> + dma_dest[1] = !blocks[src_cnt+1] ? 0 :
>> + dma_map_page(dma->dev, blocks[src_cnt+1],
>> +offset, len, DMA_BIDIRECTIONAL);
>> +
>> + for (i = 0; i < src_cnt; i++)
>> + dma_src[i] = dma_map_page(dma->dev, blocks[i],
>> + offset, len, DMA_TO_DEVICE);
>> +
>> + while (src_cnt) {
>> + async_flags = flags;
>> + pq_src_cnt = min(src_cnt, dma->max_pq);
>> + /* if we are submitting additional pqs, leave the chain open,
>> +* clear the callback parameters, and leave the destination
>> +* buffers mapped
>> +*/
>> + if (src_cnt > pq_src_cnt) {
>> + async_flags &= ~ASYNC_TX_ACK;
>> + dma_flags |= DMA_COMPL_SKIP_DEST_UNMAP;
>> + _cb_fn = NULL;
>> + _cb_param = NULL;
>> + } else {
>> + _cb_fn = cb_fn;
>> + _cb_param = cb_param;
>> + }
>> + if (_cb_fn)
>> + dma_flags |= DMA_PREP_INTERRUPT;
>> +
>> + /* Since we have clobbered the src_list we are committed
>> +* to doing this asynchronously. Drivers force forward
>> +* progress in case they can not provide a descriptor
>> +*/
>> + tx = dma->device_prep_dma_pq(chan, dma_dest,
>> +&dma_src[src_off], pq_src_cnt,
>> +scf_list ? &scf_list[src_off] :
>> + NULL,
>> +len, dma_flags);
> ...one nit for readability can we replace these ternary conditionals
> with proper if-else statements? i.e.
> if (scf_list)
> scf = &scf_list[src_off];
> else
> scf = NULL;
> tx = dma->device_prep_dma_pq(chan, dma_dest,
> &dma_src[src_off], pq_src_cnt,
> scf, len, dma_flags);
Thanks for pointing this. Sure. Furthermore, it's additionally even a
question of performance: e.g. in do_async_pq() we do this "? : " in a
cycle, whereas there is absolutely no reason to think it changes.
[..]
>> +/**
>> + * async_pq_zero_sum - attempt a PQ parities check with a dma engine.
>> + * @blocks: array of source pages. The 0..src_cnt-1 are the sources, the
>> + * src_cnt and src_cnt+1 are the P and Q destinations to check, resp.
>> + * Only one of two destinations may be present.
>> + * NOTE: client code must assume the contents of this array are
>> destroyed
>> + * @scf: coefficients to use in GF-multiplications
>> + * @offset: offset in pages to start transaction
>> + * @src_cnt: number of source pages
>> + * @len: length in bytes
>> + * @presult: where to store the result of P-ckeck, which is 0 if P-parity
>> + * OK, and non-zero otherwise.
>> + * @qresult: where to store the result of P-ckeck, which is 0 if Q-parity
>> + * OK, and non-zero otherwise.
>> + * @flags: ASYNC_TX_ASSUME_COHERENT, ASYNC_TX_ACK, ASYNC_TX_DEP_ACK
>> + * @depend_tx: depends on the result of this transaction.
>> + * @cb_fn: function to call when the xor completes
>> + * @cb_param: parameter to pass to the callback routine
>> + */
>> +struct dma_async_tx_descriptor *
>> +async_pq_zero_sum(struct page **blocks, unsigned char *scf,
>> + unsigned int offset, int src_cnt, size_t len,
>> + u32 *presult, u32 *qresult, enum async_tx_flags flags,
>> + struct dma_async_tx_descriptor *depend_tx,
>> + dma_async_tx_callback cb_fn, void *cb_param)
>> +{
>> + struct dma_chan *chan = async_tx_find_channel(depend_tx,
>> + DMA_PQ_ZERO_SUM,
>> +
Re: [PATCH v5] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On Thursday 18 December 2008, Grant Erickson wrote: > Added additional information for type and compatibility strings and > interrupt information to the SDRAM0 memory-controller device tree > nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding > with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver. > > Signed-off-by: Grant Erickson Acked-by: Stefan Roese Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
Josh Boyer-3 wrote: > > On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote: >> > > > I booted on a canyonlands this morning (after having removed the brown > paper bag that preventing me from booting it yesterday). I saw no > delay. > > josh > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > Thanks a lot to everyone who replied. I've managed to identify the cause of the delay. The board is equipped with 256 MiB Samsung NAND flash. Since NAND support is a must for this platform, I've intergated the ndfc driver recently posted by Sean McLennan. With this driver enabled the delay is present, without it messages appear on the console immediately. Is this an expected behavior - detection of 256 MiB NAND flash takes around 20 seconds. The ndfc driver works fine after boot. Felix. -- View this message in context: http://www.nabble.com/Long-boot-delay-on-460EX-with-2.6.28-rc8-tp21070179p21087072.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc 44x: support for 256KB PAGE_SIZE
This patch adds support for 256KB pages on ppc44x-based boards.
For simplification of implementation with 256KB pages we still assume
2-level paging. As a side effect this leads to wasting extra memory space
reserved for PTE tables: only 1/4 of pages allocated for PTEs are
actually used. But this may be an acceptable trade-off to achieve the
high performance we have with big PAGE_SIZEs in some applications (e.g.
RAID).
Also with 256KB PAGE_SIZE we increase THREAD_SIZE up to 32KB to minimize
the risk of stack overflows in the cases of on-stack arrays, which size
depends on the page size (e.g. multipage BIOs, NTFS, etc.).
With 256KB PAGE_SIZE we need to decrease the PKMAP_ORDER at least down
to 9, otherwise all high memory (2 ^ 10 * PAGE_SIZE == 256MB) we'll be
occupied by PKMAP addresses leaving no place for vmalloc. We do not
separate PKMAP_ORDER for 256K from 16K/64K PAGE_SIZE here; actually that
value of 10 in support for 16K/64K had been selected rather intuitively.
Thus now for all cases of PAGE_SIZE on ppc44x (including the default, 4KB,
one) we have 512 pages for PKMAP.
Because ELF standard supports only page sizes up to 64K, then you should
use patched binutils for building applications to be run with the 256KB-
page sized kernel. The patch for binutils is rather trivial, and may
look as follows:
--- binutils/bfd/elf32-ppc.c.orig
+++ binutils/bfd/elf32-ppc.c
-#define ELF_MAXPAGESIZE0x1
+#define ELF_MAXPAGESIZE0x4
Signed-off-by: Yuri Tikhonov
Signed-off-by: Ilya Yanok
---
arch/powerpc/Kconfig | 10 ++
arch/powerpc/include/asm/highmem.h | 10 +-
arch/powerpc/include/asm/mmu-44x.h |2 ++
arch/powerpc/include/asm/page.h|6 --
arch/powerpc/include/asm/page_32.h |4
arch/powerpc/include/asm/thread_info.h |4
arch/powerpc/kernel/head_booke.h | 10 +-
init/Kconfig | 10 ++
8 files changed, 48 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index cd8ff7c..348702c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -436,6 +436,14 @@ config PPC_64K_PAGES
bool "64k page size" if 44x || PPC_STD_MMU_64
select PPC_HAS_HASH_64K if PPC_STD_MMU_64
+config PPC_256K_PAGES
+ bool "256k page size" if 44x
+ depends on !STDBINUTILS
+ help
+ ELF standard supports only page sizes up to 64K so you need a patched
+ binutils in order to use 256K pages. Chose it only if you know what
+ you are doing.
+
endchoice
config FORCE_MAX_ZONEORDER
@@ -448,6 +456,8 @@ config FORCE_MAX_ZONEORDER
default "9" if PPC_STD_MMU_32 && PPC_16K_PAGES
range 7 64 if PPC_STD_MMU_32 && PPC_64K_PAGES
default "7" if PPC_STD_MMU_32 && PPC_64K_PAGES
+ range 5 64 if PPC_STD_MMU_32 && PPC_256K_PAGES
+ default "5" if PPC_STD_MMU_32 && PPC_256K_PAGES
range 11 64
default "11"
help
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index 7d6bb37..0d1333f 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -39,15 +39,15 @@ extern pte_t *pkmap_page_table;
* chunk of RAM.
*/
/*
- * We use one full pte table with 4K pages. And with 16K/64K pages pte
- * table covers enough memory (32MB and 512MB resp.) that both FIXMAP
- * and PKMAP can be placed in single pte table. We use 1024 pages for
- * PKMAP in case of 16K/64K pages.
+ * We use one full pte table with 4K pages. And with 16K/64K/256K pages pte
+ * table covers enough memory (32MB/512MB/2GB resp.), so that both FIXMAP
+ * and PKMAP can be placed in a single pte table. We use 512 pages for PKMAP
+ * in case of 16K/64K/256K page sizes.
*/
#ifdef CONFIG_PPC_4K_PAGES
#define PKMAP_ORDERPTE_SHIFT
#else
-#define PKMAP_ORDER10
+#define PKMAP_ORDER9
#endif
#define LAST_PKMAP (1 << PKMAP_ORDER)
#ifndef CONFIG_PPC_4K_PAGES
diff --git a/arch/powerpc/include/asm/mmu-44x.h
b/arch/powerpc/include/asm/mmu-44x.h
index 73e1909..52a2339 100644
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -81,6 +81,8 @@ typedef struct {
#define PPC44x_TLBE_SIZE PPC44x_TLB_16K
#elif (PAGE_SHIFT == 16)
#define PPC44x_TLBE_SIZE PPC44x_TLB_64K
+#elif (PAGE_SHIFT == 18)
+#define PPC44x_TLBE_SIZE PPC44x_TLB_256K
#else
#error "Unsupported PAGE_SIZE"
#endif
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 197d569..32cbf16 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -19,12 +19,14 @@
#include
/*
- * On regular PPC32 page size is 4K (but we support 4K/16K/64K pages
+ * On regular PPC32 page size is 4K (but we support 4K/16K/64K/256K pages
* on PPC44x). For PPC64 we support either 4K or 64K software
* page size. When using 64K pages however, whethe
[PATCH] mm/shmem.c: fix division by zero
The following patch fixes division by zero, which we have in
shmem_truncate_range() and shmem_unuse_inode(), if use big
PAGE_SIZE values (e.g. 256KB on ppc44x).
With 256KB PAGE_SIZE the ENTRIES_PER_PAGEPAGE constant becomes
too large (0x1..), so this patch just changes the types
from 'ulong' to 'ullong' where it's necessary.
Signed-off-by: Yuri Tikhonov
---
mm/shmem.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 0ed0752..99d7c91 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -57,7 +57,7 @@
#include
#define ENTRIES_PER_PAGE (PAGE_CACHE_SIZE/sizeof(unsigned long))
-#define ENTRIES_PER_PAGEPAGE (ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
+#define ENTRIES_PER_PAGEPAGE ((unsigned long
long)ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
#define BLOCKS_PER_PAGE (PAGE_CACHE_SIZE/512)
#define SHMEM_MAX_INDEX (SHMEM_NR_DIRECT + (ENTRIES_PER_PAGEPAGE/2) *
(ENTRIES_PER_PAGE+1))
@@ -95,7 +95,7 @@ static unsigned long shmem_default_max_inodes(void)
}
#endif
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
struct page **pagep, enum sgp_type sgp, int *type);
static inline struct page *shmem_dir_alloc(gfp_t gfp_mask)
@@ -533,7 +533,7 @@ static void shmem_truncate_range(struct inode *inode,
loff_t start, loff_t end)
int punch_hole;
spinlock_t *needs_lock;
spinlock_t *punch_lock;
- unsigned long upper_limit;
+ unsigned long long upper_limit;
inode->i_ctime = inode->i_mtime = CURRENT_TIME;
idx = (start + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
@@ -1175,7 +1175,7 @@ static inline struct mempolicy *shmem_get_sbmpol(struct
shmem_sb_info *sbinfo)
* vm. If we swap it in we mark it dirty since we also free the swap
* entry since a page cannot live in both the swap and page cache
*/
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
struct page **pagep, enum sgp_type sgp, int *type)
{
struct address_space *mapping = inode->i_mapping;
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH][v2] fork_init: fix division by zero
Hello Andrew, On Friday, December 19, 2008 you wrote: [snip] >> There is one more warning from the common code when I use 256KB pages: >> >>CC mm/shmem.o >> mm/shmem.c: In function 'shmem_truncate_range': >> mm/shmem.c:613: warning: division by zero >> mm/shmem.c:619: warning: division by zero >> mm/shmem.c:644: warning: division by zero >> mm/shmem.c: In function 'shmem_unuse_inode': >> mm/shmem.c:873: warning: division by zero >> >> The problem here is that ENTRIES_PER_PAGEPAGE becomes 0x1.. >> when PAGE_SIZE is 256K. >> >> How about the following fix ? [snip] > Looks sane. Thanks for reviewing. > But to apply this I'd prefer a changelog, a signoff and a grunt from Hugh. Sure, I'll post this in the separate thread then; keeping Hugh in CC. Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] powerpc: ftrace updates to previous patch series
On Fri, 19 Dec 2008, Paul Mackerras wrote: > Steven Rostedt writes: > > > Sorry, I rebased to edit the change log where I mispelled Paul's name. > > So, what commits should I be pulling into powerpc.git, or what patches > should I be committing, for dynamic ftrace on powerpc? Ingo did not like the rebase and kept the original commits (the one with the change log with the incorrect spelling). From: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git tracing/powerpc commit 8fd6e5a8c81e2e9b912ea33c8425a10729db469b Author: Steven Rostedt Date: Fri Nov 14 16:21:19 2008 -0800 powerpc: ftrace, convert to new dynamic ftrace arch API Impact: update to PowerPC ftrace arch API This patch converts PowerPC to use the new dynamic ftrace arch API. Thanks to Paul Mackennas for pointing out the mistakes of my original test_24bit_addr function. Signed-off-by: Steven Rostedt The branch in my tree 'ppc/ftrace' has not been changed since. The only reason the commits in my tree are different than the ones in tip was because I rebased to fixed the spelling in the change log. From: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git ppc/ftrace commit a3520364f9376943e4d6c76931bf4df8569fa555 Author: Steven Rostedt Date: Fri Nov 14 16:21:19 2008 -0800 powerpc: ftrace, convert to new dynamic ftrace arch API Impact: update to PowerPC ftrace arch API This patch converts PowerPC to use the new dynamic ftrace arch API. Thanks to Paul Mackerras for pointing out the mistakes of my original test_24bit_addr function. Signed-off-by: Steven Rostedt Take your pick for which to pull from. Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 10/10] powerpc/44x: 44x TLB doesn't need "Guarded" set for all pages
After discussing with chip designers, it appears that it's not necessary to set G everywhere on 440 cores. The various core errata related to prefetch should be sorted out by firmware by disabling icache prefetching in CCR0. We add the workaround to the kernel however just in case ld firmwares don't do it. This is valid for -all- 4xx core variants. Later ones hard wire the absence of prefetch but it doesn't harm to clear the bits in CCR0 (they should already be cleared anyway). We still leave G=1 on the linear mapping for now, we need to stop over-mapping RAM to be able to remove it. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/head_44x.S | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) --- linux-work.orig/arch/powerpc/kernel/head_44x.S 2008-12-10 16:11:35.0 +1100 +++ linux-work/arch/powerpc/kernel/head_44x.S 2008-12-10 16:29:08.0 +1100 @@ -69,6 +69,17 @@ _ENTRY(_start); li r24,0 /* CPU number */ /* + * In case the firmware didn't do it, we apply some workarounds + * that are good for all 440 core variants here + */ + mfspr r3,SPRN_CCR0 + rlwinm r3,r3,0,0,27/* disable icache prefetch */ + isync + mtspr SPRN_CCR0,r3 + isync + sync + +/* * Set up the initial MMU state * * We are still executing code at the virtual address @@ -570,7 +581,6 @@ finish_tlb_load: rlwimi r10,r12,29,30,30/* DIRTY -> SW position */ and r11,r12,r10 /* Mask PTE bits to keep */ andi. r10,r12,_PAGE_USER /* User page ? */ - ori r11,r11,_PAGE_GUARDED /* 440 errata, needs G set */ beq 1f /* nope, leave U bits empty */ rlwimi r11,r11,3,26,28 /* yes, copy S bits to U */ 1: tlbwe r11,r13,PPC44x_TLB_ATTRIB /* Write ATTRIB */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 9/10] powerpc/mm: Rework usage of _PAGE_COHERENT/NO_CACHE/GUARDED v2
Currently, we never set _PAGE_COHERENT in the PTEs, we just OR it in
in the hash code based on some CPU feature bit. We also manipulate
_PAGE_NO_CACHE and _PAGE_GUARDED by hand in all sorts of places.
This changes the logic so that instead, the PTE now contains
_PAGE_COHERENT for all normal RAM pages thay have I = 0 on platforms
that need it. The hash code clears it if the feature bit is not set.
It also adds some clean accessors to setup various valid combinations
of access flags and change various bits of code to use them instead.
This should help having the PTE actually containing the bit
combinations that we really want.
I also removed _PAGE_GUARDED from _PAGE_BASE on 44x and instead
set it explicitely from the TLB miss. I will ultimately remove it
completely as it appears that it might not be needed after all
but in the meantime, having it in the TLB miss makes things a
lot easier.
Signed-off-by: Benjamin Herrenschmidt
---
v2. Make _PAGE_NO_CACHE part of _PAGE_BASE_NC and fixup typo in
the definition of _PAGE_CACHE_CTL
arch/powerpc/include/asm/pgtable-ppc32.h | 42 ---
arch/powerpc/include/asm/pgtable-ppc64.h | 13 -
arch/powerpc/include/asm/pgtable.h | 26 +++
arch/powerpc/kernel/head_44x.S |1
arch/powerpc/kernel/pci-common.c | 24 ++---
arch/powerpc/mm/hash_low_32.S|4 +-
arch/powerpc/mm/mem.c|4 +-
arch/powerpc/platforms/cell/spufs/file.c | 27 ++-
drivers/video/controlfb.c|4 +-
9 files changed, 68 insertions(+), 77 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc32.h2008-11-24
14:48:55.0 +1100
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc32.h 2008-12-17
12:35:16.0 +1100
@@ -228,9 +228,10 @@ extern int icache_44x_need_flush;
* - FILE *must* be in the bottom three bits because swap cache
* entries use the top 29 bits for TLB2.
*
- * - CACHE COHERENT bit (M) has no effect on PPC440 core, because it
- * doesn't support SMP. So we can use this as software bit, like
- * DIRTY.
+ * - CACHE COHERENT bit (M) has no effect on original PPC440 cores,
+ * because it doesn't support SMP. However, some later 460 variants
+ * have -some- form of SMP support and so I keep the bit there for
+ * future use
*
* With the PPC 44x Linux implementation, the 0-11th LSBs of the PTE are used
* for memory protection related functions (see PTE structure in
@@ -436,20 +437,23 @@ extern int icache_44x_need_flush;
_PAGE_USER | _PAGE_ACCESSED | \
_PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | \
_PAGE_EXEC | _PAGE_HWEXEC)
+
/*
- * Note: the _PAGE_COHERENT bit automatically gets set in the hardware
- * PTE if CONFIG_SMP is defined (hash_page does this); there is no need
- * to have it in the Linux PTE, and in fact the bit could be reused for
- * another purpose. -- paulus.
+ * We define 2 sets of base prot bits, one for basic pages (ie,
+ * cacheable kernel and user pages) and one for non cacheable
+ * pages. We always set _PAGE_COHERENT when SMP is enabled or
+ * the processor might need it for DMA coherency.
*/
-
-#ifdef CONFIG_44x
-#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
+#if defined(CONFIG_SMP) || defined(CONFIG_PPC_STD_MMU)
+#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT)
#else
#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
#endif
+#define _PAGE_BASE_NC (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_NO_CACHE)
+
#define _PAGE_WRENABLE (_PAGE_RW | _PAGE_DIRTY | _PAGE_HWWRITE)
#define _PAGE_KERNEL (_PAGE_BASE | _PAGE_SHARED | _PAGE_WRENABLE)
+#define _PAGE_KERNEL_NC(_PAGE_BASE_NC | _PAGE_SHARED | _PAGE_WRENABLE)
#ifdef CONFIG_PPC_STD_MMU
/* On standard PPC MMU, no user access implies kernel read/write access,
@@ -459,7 +463,7 @@ extern int icache_44x_need_flush;
#define _PAGE_KERNEL_RO(_PAGE_BASE | _PAGE_SHARED)
#endif
-#define _PAGE_IO (_PAGE_KERNEL | _PAGE_NO_CACHE | _PAGE_GUARDED)
+#define _PAGE_IO (_PAGE_KERNEL_NC | _PAGE_GUARDED)
#define _PAGE_RAM (_PAGE_KERNEL | _PAGE_HWEXEC)
#if defined(CONFIG_KGDB) || defined(CONFIG_XMON) || defined(CONFIG_BDI_SWITCH)
||\
@@ -552,9 +556,6 @@ static inline int pte_young(pte_t pte)
static inline int pte_file(pte_t pte) { return pte_val(pte) &
_PAGE_FILE; }
static inline int pte_special(pte_t pte) { return pte_val(pte) &
_PAGE_SPECIAL; }
-static inline void pte_uncache(pte_t pte) { pte_val(pte) |=
_PAGE_NO_CACHE; }
-static inline void pte_cache(pte_t pte) { pte_val(pte) &=
~_PAGE_NO_CACHE; }
-
static inline pte_t pte_wrprotect(pte_t pte) {
pte_val(pte) &= ~(_PAGE_RW | _PAGE_HWWRITE); return pte; }
static inline pte_t pte_mkclean(pte_t pte) {
@@ -693,10 +694,11 @@ stat
[PATCH 8/10] powerpc/mm: Runtime allocation of mmu context maps for nohash CPUs v2
This makes the MMU context code used for CPUs with no hash table
(except 603) dynamically allocate the various maps used to track
the state of contexts.
Only the main free map and CPU 0 stale map are allocated at boot
time. Other CPU maps are allocated when those CPUs are brought up
and freed if they are unplugged.
This also moves the initialization of the MMU context management
slightly later during the boot process, which should be fine as
it's really only needed when userland if first started anyways.
Signed-off-by: Benjamin Herrenschmidt
---
v2. rebased and add some more debug
arch/powerpc/kernel/setup_32.c |5 +
arch/powerpc/mm/init_32.c|4
arch/powerpc/mm/mmu_context_nohash.c | 161 ---
3 files changed, 116 insertions(+), 54 deletions(-)
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c2008-12-19
16:06:46.0 +1100
+++ linux-work/arch/powerpc/mm/mmu_context_nohash.c 2008-12-19
16:07:05.0 +1100
@@ -28,54 +28,30 @@
#undef DEBUG
#define DEBUG_STEAL_ONLY
#undef DEBUG_MAP_CONSISTENCY
+/*#define DEBUG_CLAMP_LAST_CONTEXT 15 */
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
-#include
-
-/*
- * The MPC8xx has only 16 contexts. We rotate through them on each
- * task switch. A better way would be to keep track of tasks that
- * own contexts, and implement an LRU usage. That way very active
- * tasks don't always have to pay the TLB reload overhead. The
- * kernel pages are mapped shared, so the kernel can run on behalf
- * of any task that makes a kernel entry. Shared does not mean they
- * are not protected, just that the ASID comparison is not performed.
- * -- Dan
- *
- * The IBM4xx has 256 contexts, so we can just rotate through these
- * as a way of "switching" contexts. If the TID of the TLB is zero,
- * the PID/TID comparison is disabled, so we can use a TID of zero
- * to represent all kernel pages as shared among all contexts.
- * -- Dan
- */
-
-#ifdef CONFIG_8xx
-#define LAST_CONTEXT 15
-#define FIRST_CONTEXT 0
-
-#elif defined(CONFIG_4xx)
-#define LAST_CONTEXT 255
-#define FIRST_CONTEXT 1
-
-#elif defined(CONFIG_E200) || defined(CONFIG_E500)
-#define LAST_CONTEXT 255
-#define FIRST_CONTEXT 1
-
-#else
-#error Unsupported processor type
-#endif
+static unsigned int first_context, last_context;
static unsigned int next_context, nr_free_contexts;
-static unsigned long context_map[LAST_CONTEXT / BITS_PER_LONG + 1];
-static unsigned long stale_map[NR_CPUS][LAST_CONTEXT / BITS_PER_LONG + 1];
-static struct mm_struct *context_mm[LAST_CONTEXT+1];
+static unsigned long *context_map;
+static unsigned long *stale_map[NR_CPUS];
+static struct mm_struct **context_mm;
static spinlock_t context_lock = SPIN_LOCK_UNLOCKED;
+#define CTX_MAP_SIZE \
+ (sizeof(unsigned long) * (last_context / BITS_PER_LONG + 1))
+
+
/* Steal a context from a task that has one at the moment.
*
* This is used when we are running out of available PID numbers
@@ -98,7 +74,7 @@ static unsigned int steal_context_smp(un
unsigned int cpu, max;
again:
- max = LAST_CONTEXT - FIRST_CONTEXT;
+ max = last_context - first_context;
/* Attempt to free next_context first and then loop until we manage */
while (max--) {
@@ -110,8 +86,8 @@ static unsigned int steal_context_smp(un
*/
if (mm->context.active) {
id ++;
- if (id > LAST_CONTEXT)
- id = FIRST_CONTEXT;
+ if (id > last_context)
+ id = first_context;
continue;
}
pr_debug("[%d] steal context %d from mm @%p\n",
@@ -169,7 +145,7 @@ static void context_check_map(void)
unsigned int id, nrf, nact;
nrf = nact = 0;
- for (id = FIRST_CONTEXT; id <= LAST_CONTEXT; id++) {
+ for (id = first_context; id <= last_context; id++) {
int used = test_bit(id, context_map);
if (!used)
nrf++;
@@ -187,6 +163,8 @@ static void context_check_map(void)
if (nact > num_online_cpus())
pr_err("MMU: More active contexts than CPUs ! (%d vs %d)\n",
nact, num_online_cpus());
+ if (first_context > 0 && !test_bit(0, context_map))
+ pr_err("MMU: Context 0 has been freed !!!\n");
}
#else
static void context_check_map(void) { }
@@ -209,6 +187,10 @@ void switch_mmu_context(struct mm_struct
/* Mark us active and the previous one not anymore */
next->context.active++;
if (prev) {
+#ifndef DEBUG_STEAL_ONLY
+ pr_debug(" old context %p active was: %d\n",
+prev, prev->context.active);
+#endif
WARN_ON(prev->con
[PATCH 7/10] powerpc/44x: No need to mask MSR:CE, ME or DE in _tlbil_va on 440
The handlers for Critical, Machine Check or Debug interrupts will save and restore MMUCR nowadays, thus we only need to disable normal interrupts when invalidating TLB entries. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/mm/tlb_nohash_low.S | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) --- linux-work.orig/arch/powerpc/mm/tlb_nohash_low.S2008-12-15 13:34:57.0 +1100 +++ linux-work/arch/powerpc/mm/tlb_nohash_low.S 2008-12-15 13:35:07.0 +1100 @@ -75,18 +75,19 @@ _GLOBAL(_tlbil_va) mfspr r5,SPRN_MMUCR rlwimi r5,r4,0,24,31 /* Set TID */ - /* We have to run the search with interrupts disabled, even critical -* and debug interrupts (in fact the only critical exceptions we have -* are debug and machine check). Otherwise an interrupt which causes -* a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */ + /* We have to run the search with interrupts disabled, otherwise +* an interrupt which causes a TLB miss can clobber the MMUCR +* between the mtspr and the tlbsx. +* +* Critical and Machine Check interrupts take care of saving +* and restoring MMUCR, so only normal interrupts have to be +* taken care of. +*/ mfmsr r4 - lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha - addir6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l - andcr6,r4,r6 - mtmsr r6 + wrteei 0 mtspr SPRN_MMUCR,r5 tlbsx. r3, 0, r3 - mtmsr r4 + wrtee r4 bne 1f sync /* There are only 64 TLB entries, so r3 < 64, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/10] powerpc/mm: Split low level tlb invalidate for nohash processors
Currently, the various forms of low level TLB invalidations are all
implemented in misc_32.S for 32-bit processors, in a fairly scary
mess of #ifdef's and with interesting duplication such as a whole
bunch of code for FSL _tlbie and _tlbia which are no longer used.
This moves things around such that _tlbie is now defined in
hash_low_32.S and is only used by the 32-bit hash code, and all
nohash CPUs use the various _tlbil_* forms that are now moved to
a new file, tlb_nohash_low.S.
I moved all the definitions for that stuff out of include/asm/tlbflush.h as
they are really internal mm stuff, into mm/mmu_decl.h
The code should have no functional changes. I kept some variants
inline for trivial forms on things like 40x and 8xx.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/tlbflush.h | 14 --
arch/powerpc/kernel/misc_32.S | 233
arch/powerpc/kvm/powerpc.c |2
arch/powerpc/mm/Makefile|3
arch/powerpc/mm/hash_low_32.S | 76 +++
arch/powerpc/mm/mmu_decl.h | 48 +++
arch/powerpc/mm/tlb_nohash_low.S| 165 +
7 files changed, 292 insertions(+), 249 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/tlbflush.h 2008-12-15
15:46:23.0 +1100
+++ linux-work/arch/powerpc/include/asm/tlbflush.h 2008-12-15
15:46:56.0 +1100
@@ -33,17 +33,6 @@
#define MMU_NO_CONTEXT ((unsigned int)-1)
-extern void _tlbil_all(void);
-extern void _tlbil_pid(unsigned int pid);
-extern void _tlbil_va(unsigned long address, unsigned int pid);
-extern void _tlbivax_bcast(unsigned long address, unsigned int pid);
-
-#if defined(CONFIG_40x) || defined(CONFIG_8xx)
-#define _tlbia() asm volatile ("tlbia; sync" : : : "memory")
-#else /* CONFIG_44x || CONFIG_FSL_BOOKE */
-extern void _tlbia(void);
-#endif
-
extern void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
unsigned long end);
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
@@ -65,9 +54,6 @@ extern void flush_tlb_page(struct vm_are
/*
* TLB flushing for "classic" hash-MMU 32-bit CPUs, 6xx, 7xx, 7xxx
*/
-extern void _tlbie(unsigned long address);
-extern void _tlbia(void);
-
extern void flush_tlb_mm(struct mm_struct *mm);
extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
extern void flush_tlb_page_nohash(struct vm_area_struct *vma, unsigned long
addr);
Index: linux-work/arch/powerpc/mm/mmu_decl.h
===
--- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2008-12-15 15:46:23.0
+1100
+++ linux-work/arch/powerpc/mm/mmu_decl.h 2008-12-15 15:46:56.0
+1100
@@ -22,10 +22,58 @@
#include
#include
+#ifdef CONFIG_PPC_MMU_NOHASH
+
+/*
+ * On 40x and 8xx, we directly inline tlbia and tlbivax
+ */
+#if defined(CONFIG_40x) || defined(CONFIG_8xx)
+static inline void _tlbil_all(void)
+{
+ asm volatile ("sync; tlbia; isync" : : : "memory")
+}
+static inline void _tlbil_pid(unsigned int pid)
+{
+ asm volatile ("sync; tlbia; isync" : : : "memory")
+}
+#else /* CONFIG_40x || CONFIG_8xx */
+extern void _tlbil_all(void);
+extern void _tlbil_pid(unsigned int pid);
+#endif /* !(CONFIG_40x || CONFIG_8xx) */
+
+/*
+ * On 8xx, we directly inline tlbie, on others, it's extern
+ */
+#ifdef CONFIG_8xx
+static inline void _tlbil_va(unsigned long address, unsigned int pid)
+{
+ asm volatile ("tlbie %0; sync" : : "r" (address) : "memory")
+}
+#else /* CONFIG_8xx */
+extern void _tlbil_va(unsigned long address, unsigned int pid);
+#endif /* CONIFG_8xx */
+
+/*
+ * As of today, we don't support tlbivax broadcast on any
+ * implementation. When that becomes the case, this will be
+ * an extern.
+ */
+static inline void _tlbivax_bcast(unsigned long address, unsigned int pid)
+{
+ BUG();
+}
+
+#else /* CONFIG_PPC_MMU_NOHASH */
+
extern void hash_preload(struct mm_struct *mm, unsigned long ea,
unsigned long access, unsigned long trap);
+extern void _tlbie(unsigned long address);
+extern void _tlbia(void);
+
+#endif /* CONFIG_PPC_MMU_NOHASH */
+
#ifdef CONFIG_PPC32
extern void mapin_ram(void);
extern int map_page(unsigned long va, phys_addr_t pa, int flags);
Index: linux-work/arch/powerpc/mm/tlb_nohash_low.S
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/mm/tlb_nohash_low.S 2008-12-15 15:47:57.0
+1100
@@ -0,0 +1,165 @@
+/*
+ * This file contains low-level functions for performing various
+ * types of TLB invalidations on various processors with no hash
+ * table.
+ *
+ * This file implements the following functions for all no-hash
+ * processors. Some aren't implemented for some variants. Some
+ * are inline in tlbflush.h
+ *
+ * - tlbil_va
+ * - tlbil_pid
+ *
[PATCH 5/10] powerpc/mm: Add SMP support to no-hash TLB handling v5
This patch moves the whole no-hash TLB handling out of line into a
new tlb_nohash.c file, and implements some basic SMP support using
IPIs and/or broadcast tlbivax instructions.
Note that I'm using local invalidations for D->I cache coherency.
At worst, if another processor is trying to execute the same and
has the old entry in its TLB, it will just take a fault and re-do
the TLB flush locally (it won't re-do the cache flush in any case).
Signed-off-by: Benjamin Herrenschmidt
---
v2. This variant fixes usage of linux/spinlock.h instead of asm/spinlock.h
v3. Invadvertently un-EXPORT_SYMBOL'ed some cache flush calls on ppc64
v4. Fix differences in local_* flush variants between CPU types and
corresponding clash with highmem code. Remove remaining _tlbie calls
from nohash code.
v5. HAS->USE and some comments on MMU features
arch/powerpc/include/asm/highmem.h |4
arch/powerpc/include/asm/mmu.h | 16 ++
arch/powerpc/include/asm/tlbflush.h | 84 ++
arch/powerpc/kernel/misc_32.S |9 +
arch/powerpc/kernel/ppc_ksyms.c |6 -
arch/powerpc/mm/Makefile|2
arch/powerpc/mm/fault.c |2
arch/powerpc/mm/mem.c |2
arch/powerpc/mm/tlb_hash32.c|4
arch/powerpc/mm/tlb_nohash.c| 209
10 files changed, 281 insertions(+), 57 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/tlbflush.h 2008-12-16
10:17:43.0 +1100
+++ linux-work/arch/powerpc/include/asm/tlbflush.h 2008-12-16
10:22:34.0 +1100
@@ -6,7 +6,9 @@
*
* - flush_tlb_mm(mm) flushes the specified mm context TLB's
* - flush_tlb_page(vma, vmaddr) flushes one page
- * - local_flush_tlb_page(vmaddr) flushes one page on the local processor
+ * - local_flush_tlb_mm(mm) flushes the specified mm context on
+ * the local processor
+ * - local_flush_tlb_page(vma, vmaddr) flushes one page on the local processor
* - flush_tlb_page_nohash(vma, vmaddr) flushes one page if SW loaded TLB
* - flush_tlb_range(vma, start, end) flushes a range of pages
* - flush_tlb_kernel_range(start, end) flushes a range of kernel pages
@@ -18,7 +20,7 @@
*/
#ifdef __KERNEL__
-#if defined(CONFIG_4xx) || defined(CONFIG_8xx) || defined(CONFIG_FSL_BOOKE)
+#ifdef CONFIG_PPC_MMU_NOHASH
/*
* TLB flushing for software loaded TLB chips
*
@@ -31,10 +33,10 @@
#define MMU_NO_CONTEXT ((unsigned int)-1)
-extern void _tlbie(unsigned long address, unsigned int pid);
extern void _tlbil_all(void);
extern void _tlbil_pid(unsigned int pid);
extern void _tlbil_va(unsigned long address, unsigned int pid);
+extern void _tlbivax_bcast(unsigned long address, unsigned int pid);
#if defined(CONFIG_40x) || defined(CONFIG_8xx)
#define _tlbia() asm volatile ("tlbia; sync" : : : "memory")
@@ -42,48 +44,26 @@ extern void _tlbil_va(unsigned long addr
extern void _tlbia(void);
#endif
-static inline void local_flush_tlb_mm(struct mm_struct *mm)
-{
- _tlbil_pid(mm->context.id);
-}
-
-static inline void flush_tlb_mm(struct mm_struct *mm)
-{
- _tlbil_pid(mm->context.id);
-}
-
-static inline void local_flush_tlb_page(unsigned long vmaddr)
-{
- _tlbil_va(vmaddr, 0);
-}
-
-static inline void flush_tlb_page(struct vm_area_struct *vma,
- unsigned long vmaddr)
-{
- _tlbil_va(vmaddr, vma ? vma->vm_mm->context.id : 0);
-}
+extern void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
+ unsigned long end);
+extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
-static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
-unsigned long vmaddr)
-{
- flush_tlb_page(vma, vmaddr);
-}
+extern void local_flush_tlb_mm(struct mm_struct *mm);
+extern void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long
vmaddr);
-static inline void flush_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
-{
- _tlbil_pid(vma->vm_mm->context.id);
-}
+#ifdef CONFIG_SMP
+extern void flush_tlb_mm(struct mm_struct *mm);
+extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
+#else
+#define flush_tlb_mm(mm) local_flush_tlb_mm(mm)
+#define flush_tlb_page(vma,addr) local_flush_tlb_page(vma,addr)
+#endif
+#define flush_tlb_page_nohash(vma,addr)flush_tlb_page(vma,addr)
-static inline void flush_tlb_kernel_range(unsigned long start,
- unsigned long end)
-{
- _tlbil_pid(0);
-}
+#elif defined(CONFIG_PPC_STD_MMU_32)
-#elif defined(CONFIG_PPC32)
/*
- * TLB flushing for "classic" hash-MMMU 32-bit CPUs, 6xx, 7xx, 7xxx
+ * TLB flushing for "classic" hash-MMU 32-bit CPUs, 6xx, 7xx, 7xxx
*/
extern void _tlbie(unsigned long address);
extern void _tlbia(void);
@
[PATCH 3/10] powerpc/mm: Rework context management for CPUs with no hash table v2
This reworks the context management code used by 4xx,8xx and
freescale BookE. It adds support for SMP by implementing a
concept of stale context map to lazily flush the TLB on
processors where a context may have been invalidated. This
also contains the ground work for generalizing such lazy TLB
flushing by just picking up a new PID and marking the old one
stale. This will be implemented later.
This is a first implementation that uses a global spinlock.
Ideally, we should try to get at least the fast path (context ID
already assigned) lockless or limited to a per context lock,
but for now this will do.
I tried to keep the UP case reasonably simple to avoid adding
too much overhead to 8xx which does a lot of context stealing
since it effectively has only 16 PIDs available.
Signed-off-by: Benjamin Herrenschmidt
---
v2. remove some bugs with active tracking on SMP
arch/powerpc/include/asm/mmu-40x.h |5
arch/powerpc/include/asm/mmu-44x.h |5
arch/powerpc/include/asm/mmu-8xx.h |3
arch/powerpc/include/asm/mmu-fsl-booke.h |5
arch/powerpc/include/asm/tlbflush.h |2
arch/powerpc/mm/mmu_context_nohash.c | 270 +--
6 files changed, 235 insertions(+), 55 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/mmu-40x.h 2008-09-29
14:21:37.0 +1000
+++ linux-work/arch/powerpc/include/asm/mmu-40x.h 2008-12-19
15:41:54.0 +1100
@@ -54,8 +54,9 @@
#ifndef __ASSEMBLY__
typedef struct {
- unsigned long id;
- unsigned long vdso_base;
+ unsigned intid;
+ unsigned intactive;
+ unsigned long vdso_base;
} mm_context_t;
#endif /* !__ASSEMBLY__ */
Index: linux-work/arch/powerpc/include/asm/mmu-44x.h
===
--- linux-work.orig/arch/powerpc/include/asm/mmu-44x.h 2008-09-29
14:21:37.0 +1000
+++ linux-work/arch/powerpc/include/asm/mmu-44x.h 2008-12-19
15:42:26.0 +1100
@@ -56,8 +56,9 @@
extern unsigned int tlb_44x_hwater;
typedef struct {
- unsigned long id;
- unsigned long vdso_base;
+ unsigned intid;
+ unsigned intactive;
+ unsigned long vdso_base;
} mm_context_t;
#endif /* !__ASSEMBLY__ */
Index: linux-work/arch/powerpc/include/asm/mmu-fsl-booke.h
===
--- linux-work.orig/arch/powerpc/include/asm/mmu-fsl-booke.h2008-12-08
15:40:33.0 +1100
+++ linux-work/arch/powerpc/include/asm/mmu-fsl-booke.h 2008-12-19
15:41:54.0 +1100
@@ -76,8 +76,9 @@
#ifndef __ASSEMBLY__
typedef struct {
- unsigned long id;
- unsigned long vdso_base;
+ unsigned intid;
+ unsigned intactive;
+ unsigned long vdso_base;
} mm_context_t;
#endif /* !__ASSEMBLY__ */
Index: linux-work/arch/powerpc/mm/mmu_context_nohash.c
===
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c2008-12-19
15:41:54.0 +1100
+++ linux-work/arch/powerpc/mm/mmu_context_nohash.c 2008-12-19
16:06:46.0 +1100
@@ -14,13 +14,28 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
+ * TODO:
+ *
+ * - The global context lock will not scale very well
+ * - The maps should be dynamically allocated to allow for processors
+ * that support more PID bits at runtime
+ * - Implement flush_tlb_mm() by making the context stale and picking
+ * a new one
+ * - More aggressively clear stale map bits and maybe find some way to
+ * also clear mm->cpu_vm_mask bits when processes are migrated
*/
+#undef DEBUG
+#define DEBUG_STEAL_ONLY
+#undef DEBUG_MAP_CONSISTENCY
+
+#include
#include
#include
#include
#include
+#include
/*
* The MPC8xx has only 16 contexts. We rotate through them on each
@@ -40,17 +55,14 @@
*/
#ifdef CONFIG_8xx
-#define NO_CONTEXT 16
#define LAST_CONTEXT 15
#define FIRST_CONTEXT 0
#elif defined(CONFIG_4xx)
-#define NO_CONTEXT 256
#define LAST_CONTEXT 255
#define FIRST_CONTEXT 1
#elif defined(CONFIG_E200) || defined(CONFIG_E500)
-#define NO_CONTEXT 256
#define LAST_CONTEXT 255
#define FIRST_CONTEXT 1
@@ -58,66 +70,208 @@
#error Unsupported processor type
#endif
-static unsigned long next_mmu_context;
+static unsigned int next_context, nr_free_contexts;
static unsigned long context_map[LAST_CONTEXT / BITS_PER_LONG + 1];
-static atomic_t nr_free_contexts;
+static unsigned long stale_map[NR_CPUS][LAST_CONTEXT / BITS_PER_LONG + 1];
static struct mm_struct *context_mm[LAST_CONTEXT+1];
-static void steal_context(void);
+static spinlock_t context_lock = SPIN_LOCK_UNLOCKED;
/* Steal a context from a task that has one at the moment.
- * This is only
[PATCH 2/10] powerpc/mm: Split mmu_context handling v3
This splits the mmu_context handling between 32-bit hash based processors,
64-bit hash based processors and everybody else. This is preliminary work
for adding SMP support for BookE processors.
Signed-off-by: Benjamin Herrenschmidt
---
v2. address various comments for Josh and Stephen
v3. properly removes the old mmu_context_32.c and mmu_context_64.c
arch/powerpc/include/asm/mmu_context.h | 260 +++
arch/powerpc/kernel/asm-offsets.c|1
arch/powerpc/kernel/head_32.S| 12 +
arch/powerpc/kernel/ppc_ksyms.c |3
arch/powerpc/kernel/swsusp.c |2
arch/powerpc/mm/Makefile |7
arch/powerpc/mm/mmu_context_32.c | 84
arch/powerpc/mm/mmu_context_64.c | 70 ---
arch/powerpc/mm/mmu_context_hash32.c | 103 ++
arch/powerpc/mm/mmu_context_hash64.c | 78
arch/powerpc/mm/mmu_context_nohash.c | 162
arch/powerpc/platforms/Kconfig.cputype | 10 -
arch/powerpc/platforms/powermac/cpufreq_32.c |2
drivers/macintosh/via-pmu.c |4
14 files changed, 407 insertions(+), 391 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/mmu_context.h 2008-12-08
15:40:33.0 +1100
+++ linux-work/arch/powerpc/include/asm/mmu_context.h 2008-12-17
12:31:28.0 +1100
@@ -2,240 +2,26 @@
#define __ASM_POWERPC_MMU_CONTEXT_H
#ifdef __KERNEL__
+#include
+#include
+#include
+#include
#include
#include
#include
-
-#ifndef CONFIG_PPC64
-#include
-#include
-
-/*
- * On 32-bit PowerPC 6xx/7xx/7xxx CPUs, we use a set of 16 VSIDs
- * (virtual segment identifiers) for each context. Although the
- * hardware supports 24-bit VSIDs, and thus >1 million contexts,
- * we only use 32,768 of them. That is ample, since there can be
- * at most around 30,000 tasks in the system anyway, and it means
- * that we can use a bitmap to indicate which contexts are in use.
- * Using a bitmap means that we entirely avoid all of the problems
- * that we used to have when the context number overflowed,
- * particularly on SMP systems.
- * -- paulus.
- */
-
-/*
- * This function defines the mapping from contexts to VSIDs (virtual
- * segment IDs). We use a skew on both the context and the high 4 bits
- * of the 32-bit virtual address (the "effective segment ID") in order
- * to spread out the entries in the MMU hash table. Note, if this
- * function is changed then arch/ppc/mm/hashtable.S will have to be
- * changed to correspond.
- */
-#define CTX_TO_VSID(ctx, va) (((ctx) * (897 * 16) + ((va) >> 28) * 0x111) \
-& 0xff)
-
-/*
- The MPC8xx has only 16 contexts. We rotate through them on each
- task switch. A better way would be to keep track of tasks that
- own contexts, and implement an LRU usage. That way very active
- tasks don't always have to pay the TLB reload overhead. The
- kernel pages are mapped shared, so the kernel can run on behalf
- of any task that makes a kernel entry. Shared does not mean they
- are not protected, just that the ASID comparison is not performed.
--- Dan
-
- The IBM4xx has 256 contexts, so we can just rotate through these
- as a way of "switching" contexts. If the TID of the TLB is zero,
- the PID/TID comparison is disabled, so we can use a TID of zero
- to represent all kernel pages as shared among all contexts.
- -- Dan
- */
-
-static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct
*tsk)
-{
-}
-
-#ifdef CONFIG_8xx
-#define NO_CONTEXT 16
-#define LAST_CONTEXT 15
-#define FIRST_CONTEXT 0
-
-#elif defined(CONFIG_4xx)
-#define NO_CONTEXT 256
-#define LAST_CONTEXT 255
-#define FIRST_CONTEXT 1
-
-#elif defined(CONFIG_E200) || defined(CONFIG_E500)
-#define NO_CONTEXT 256
-#define LAST_CONTEXT 255
-#define FIRST_CONTEXT 1
-
-#else
-
-/* PPC 6xx, 7xx CPUs */
-#define NO_CONTEXT ((unsigned long) -1)
-#define LAST_CONTEXT 32767
-#define FIRST_CONTEXT 1
-#endif
-
-/*
- * Set the current MMU context.
- * On 32-bit PowerPCs (other than the 8xx embedded chips), this is done by
- * loading up the segment registers for the user part of the address space.
- *
- * Since the PGD is immediately available, it is much faster to simply
- * pass this along as a second parameter, which is required for 8xx and
- * can be used for debugging on all processors (if you happen to have
- * an Abatron).
- */
-extern void set_context(unsigned long contextid, pgd_t *pgd);
-
-/*
- * Bitmap of contexts in use.
- * The size of this bitmap is LAST_CONTEXT + 1 bits.
- */
-extern unsigned long context_map[];
-
-/*
- * This caches the next context number that we expect to be free.
- * Its use is an optimization only, we can't rely on this context
- * numbe
[PATCH 1/10] powerpc/4xx: Extended DCR support v2
This adds supports to the "extended" DCR addressing via
the indirect mfdcrx/mtdcrx instructions supported by some
4xx cores (440H6 and later)
I enabled the feature for now only on AMCC 460 chips
Signed-off-by: Benjamin Herrenschmidt
---
This variant uses "440x6" instead of "440H6". I made no other
changes to the code as I think the codegen is the less bad I've
had so far and I rely on Josh further work on cleaning up the
type of 440core selection at Kconfig time so the feature are
properly reflected in the POSSIBLE and ALWAYS masks based on
the core selection. That way, if only one core type is selected
the feature test should resolve at compile time.
arch/powerpc/include/asm/cputable.h |7 ++-
arch/powerpc/include/asm/dcr-native.h | 63 +++---
arch/powerpc/kernel/cputable.c|4 +-
arch/powerpc/sysdev/dcr-low.S |8 +++-
4 files changed, 65 insertions(+), 17 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/cputable.h 2008-12-17
12:28:23.0 +1100
+++ linux-work/arch/powerpc/include/asm/cputable.h 2008-12-17
12:30:52.0 +1100
@@ -164,6 +164,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_NEED_PAIRED_STWCX ASM_CONST(0x0400)
#define CPU_FTR_LWSYNC ASM_CONST(0x0800)
#define CPU_FTR_NOEXECUTE ASM_CONST(0x1000)
+#define CPU_FTR_INDEXED_DCRASM_CONST(0x2000)
/*
* Add the 64-bit processor unique features in the top half of the word;
@@ -369,6 +370,8 @@ extern const char *powerpc_base_platform
#define CPU_FTRS_8XX (CPU_FTR_USE_TB)
#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN |
CPU_FTR_NOEXECUTE)
#define CPU_FTRS_44X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN |
CPU_FTR_NOEXECUTE)
+#define CPU_FTRS_440x6 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN |
CPU_FTR_NOEXECUTE | \
+ CPU_FTR_INDEXED_DCR)
#define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \
CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE)
@@ -455,7 +458,7 @@ enum {
CPU_FTRS_40X |
#endif
#ifdef CONFIG_44x
- CPU_FTRS_44X |
+ CPU_FTRS_44X | CPU_FTRS_440x6 |
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 |
@@ -495,7 +498,7 @@ enum {
CPU_FTRS_40X &
#endif
#ifdef CONFIG_44x
- CPU_FTRS_44X &
+ CPU_FTRS_44X & CPU_FTRS_440x6 &
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 &
Index: linux-work/arch/powerpc/include/asm/dcr-native.h
===
--- linux-work.orig/arch/powerpc/include/asm/dcr-native.h 2008-09-29
14:21:37.0 +1000
+++ linux-work/arch/powerpc/include/asm/dcr-native.h2008-12-17
12:30:52.0 +1100
@@ -23,6 +23,7 @@
#ifndef __ASSEMBLY__
#include
+#include
typedef struct {
unsigned int base;
@@ -39,23 +40,45 @@ static inline bool dcr_map_ok_native(dcr
#define dcr_read_native(host, dcr_n) mfdcr(dcr_n + host.base)
#define dcr_write_native(host, dcr_n, value) mtdcr(dcr_n + host.base, value)
-/* Device Control Registers */
-void __mtdcr(int reg, unsigned int val);
-unsigned int __mfdcr(int reg);
+/* Table based DCR accessors */
+extern void __mtdcr(unsigned int reg, unsigned int val);
+extern unsigned int __mfdcr(unsigned int reg);
+
+/* mfdcrx/mtdcrx instruction based accessors. We hand code
+ * the opcodes in order not to depend on newer binutils
+ */
+static inline unsigned int mfdcrx(unsigned int reg)
+{
+ unsigned int ret;
+ asm volatile(".long 0x7c000206 | (%0 << 21) | (%1 << 16)"
+: "=r" (ret) : "r" (reg));
+ return ret;
+}
+
+static inline void mtdcrx(unsigned int reg, unsigned int val)
+{
+ asm volatile(".long 0x7c000306 | (%0 << 21) | (%1 << 16)"
+: : "r" (val), "r" (reg));
+}
+
#define mfdcr(rn) \
({unsigned int rval;\
- if (__builtin_constant_p(rn)) \
+ if (__builtin_constant_p(rn) && rn < 1024) \
asm volatile("mfdcr %0," __stringify(rn)\
: "=r" (rval)); \
+ else if (likely(cpu_has_feature(CPU_FTR_INDEXED_DCR))) \
+ rval = mfdcrx(rn); \
else\
rval = __mfdcr(rn); \
rval;})
#define mtdcr(rn, v) \
do { \
- if (__builtin_constant_p(rn)) \
+ if (__builtin_constant_p(rn) && rn < 1024) \
asm volatile("mtdcr " __stringify(rn) ",%0" \
[PATCH 0/10] powerpc: Preliminary work to enable SMP BookE (v3)
This series of patches is aimed at supporting SMP on non-hash based processors. It consists of a rework of the MMU context management and TLB management, clearly splitting hash32, hash64 and nohash in both cases, adding SMP safe context handling and some basic SMP TLB management. There is room for improvements, such as implementing lazy TLB flushing on processors without invalidate-by-PID support HW, some better IPI mechanism, lock less fast path in the MMU context switch, etc... but it should basically work. This version addresses the issues raised about some of the patches in the previous batch, removes the ones that were already merged in -next and and rebases the remaining ones when needed. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] powerpc: ftrace updates to previous patch series
Steven Rostedt writes: > Sorry, I rebased to edit the change log where I mispelled Paul's name. So, what commits should I be pulling into powerpc.git, or what patches should I be committing, for dynamic ftrace on powerpc? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc/fsl-booke: declare tlbcam_index for use in c file
KVM on E500 platform currently utilize TLB1 entries without bothering host,
that is using unused TLB1 entries.
So, KVM needs to read tlbcam_index to know exactly
which TLB1 entry is unused by host.
Signed-off-by: Liu Yu
---
[v2]
Remove num_tlbcam_entries declare and read from SPRN_TLB1CFG in KVM instead.
arch/powerpc/include/asm/mmu-fsl-booke.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-fsl-booke.h
b/arch/powerpc/include/asm/mmu-fsl-booke.h
index 925d93c..c86af6c 100644
--- a/arch/powerpc/include/asm/mmu-fsl-booke.h
+++ b/arch/powerpc/include/asm/mmu-fsl-booke.h
@@ -73,6 +73,8 @@
#ifndef __ASSEMBLY__
+extern unsigned int tlbcam_index;
+
typedef struct {
unsigned long id;
unsigned long vdso_base;
--
1.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add PPC/4xx "ibm,sdram-4xx-ddr2" EDAC MC Driver
On 12/18/08 11:13 AM, Grant Erickson wrote: > On 12/18/08 9:56 AM, Josh Boyer wrote: >> So, I am not an expert at the EDAC subsystem. Just looking at the >> number of functions that get call from this interrupt handler, I'm >> wondering if a significant amount of time could be spent here. With >> all the message building and such, it seems like it could be error >> prone. > > The message building functions are really best-effort, straight-through, so > there should be little room if any for error-proneness. Though, snprintf > contained therein is fairly costly as functions go. > >> Do you have an idea of the duration of one of these events? Could >> this schedule a work queue to handle it outside of the hard IRQ >> context? > > I'll take some measurements for the worst case message length time. I > certainly thought about a work queue; however, my gut feeling was that it > wasn't warranted. > > Stay tuned for measurement data. In general, correctable and uncorrectable ECC errors in and of themselves should be rare events. So, by extension, the generation of these ECC error messages should be rare as well. When one of these CE or UE ECC events occurs, the time required to build the driver-unique log message is as shown below for a run of ~300 forced CEs at at a processor frequency of 400 MHz: Ticks Time / us Minimum 4150 10.38 Maximum 9075 22.69 Mean8024 20.06 Median 8297 20.74 Mode8869 22.17 Std. Dev.8642.16 Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
On Thu, 2008-12-18 at 22:01 +0300, Anton Vorontsov wrote: > On Thu, Dec 18, 2008 at 12:51:29PM -0600, Kumar Gala wrote: > >> I saw somewhat similar behaviour on 83xx target, the cause was > >> that my .config file contained bogus UDBG_RTAS_CONSOLE=y symbol > >> (or was it PPC_EARLY_DEBUG_RTAS_PANEL=y? Or HVC_UDBG=y? I don't > >> quite remember). > >> > >> Obviously, on 83xx we don't have RTAS or HVC stuff, but kernel > >> didn't oops or hang completely, it was busy with executing various > >> delays in those drivers and then just continued to load. > > > > Why are these drivers even doing anything on 83xx? Seems like they need > > something to bind against or some detection of "HW". > > Early console/UDBG is known to cause problems if enabled on > inappropriate hardware. They start working very early, so it's hard > for them to do the hw detection (no device tree yet, I presume). Yes that's the whole point, it's _EARLY_ debug, there's even a big fat warning in the Kconfig. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] fork_init: fix division by zero
On Thu, 18 Dec 2008 10:47:50 +0300
Yuri Tikhonov wrote:
> Hello Paul,
>
> On Friday 12 December 2008 03:48, Paul Mackerras wrote:
> > Andrew Morton writes:
> >
> > > > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > > > max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > > > +#else
> > > > + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
> > > > +#endif
> > >
> > > The expression you've chosen here can be quite inacccurate, because
> > > ((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number. The way to
> > > preserve accuracy is
> >
> > The assumption is that THREAD_SIZE is a power of 2, as is PAGE_SIZE.
> >
> > I think Yuri should be increasing THREAD_SIZE for the larger page
> > sizes he's implementing, because we have on-stack arrays whose size
> > depends on the page size. I suspect that having THREAD_SIZE less than
> > 1/8 of PAGE_SIZE risks stack overflows, and the better fix is for Yuri
> > to make sure THREAD_SIZE is at least 1/8 of PAGE_SIZE. (In fact, more
> > may be needed - someone should work out what fraction is actually
> > needed.)
>
> Right, thanks for pointing this. I guess, I was just lucky since didn't run
> into
> problems with stack overflows. So, I agree that we should increase the
> THREAD_SIZE in case of 256KB pages up to 1/8 of PAGE_SIZE, that is up
> to 32KB.
>
> There is one more warning from the common code when I use 256KB pages:
>
>CC mm/shmem.o
> mm/shmem.c: In function 'shmem_truncate_range':
> mm/shmem.c:613: warning: division by zero
> mm/shmem.c:619: warning: division by zero
> mm/shmem.c:644: warning: division by zero
> mm/shmem.c: In function 'shmem_unuse_inode':
> mm/shmem.c:873: warning: division by zero
>
> The problem here is that ENTRIES_PER_PAGEPAGE becomes 0x1..
> when PAGE_SIZE is 256K.
>
> How about the following fix ?
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 0ed0752..99d7c91 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -57,7 +57,7 @@
> #include
>
> #define ENTRIES_PER_PAGE (PAGE_CACHE_SIZE/sizeof(unsigned long))
> -#define ENTRIES_PER_PAGEPAGE (ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
> +#define ENTRIES_PER_PAGEPAGE ((unsigned long
> long)ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
> #define BLOCKS_PER_PAGE (PAGE_CACHE_SIZE/512)
>
> #define SHMEM_MAX_INDEX (SHMEM_NR_DIRECT + (ENTRIES_PER_PAGEPAGE/2) *
> (ENTRIES_PER_PAGE+1))
> @@ -95,7 +95,7 @@ static unsigned long shmem_default_max_inodes(void)
> }
> #endif
>
> -static int shmem_getpage(struct inode *inode, unsigned long idx,
> +static int shmem_getpage(struct inode *inode, unsigned long long idx,
>struct page **pagep, enum sgp_type sgp, int *type);
>
> static inline struct page *shmem_dir_alloc(gfp_t gfp_mask)
> @@ -533,7 +533,7 @@ static void shmem_truncate_range(struct inode *inode,
> loff_t start, loff_t end)
> int punch_hole;
> spinlock_t *needs_lock;
> spinlock_t *punch_lock;
> - unsigned long upper_limit;
> + unsigned long long upper_limit;
>
> inode->i_ctime = inode->i_mtime = CURRENT_TIME;
> idx = (start + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
> @@ -1175,7 +1175,7 @@ static inline struct mempolicy *shmem_get_sbmpol(struct
> shmem_sb_info *sbinfo)
> * vm. If we swap it in we mark it dirty since we also free the swap
> * entry since a page cannot live in both the swap and page cache
> */
> -static int shmem_getpage(struct inode *inode, unsigned long idx,
> +static int shmem_getpage(struct inode *inode, unsigned long long idx,
> struct page **pagep, enum sgp_type sgp, int *type)
> {
> struct address_space *mapping = inode->i_mapping;
>
Looks sane. But to apply this I'd prefer a changelog, a signoff and a
grunt from Hugh.
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
Patch v3, based on review from Josh Boyer and Stefan Roese, simplifies
the interrupt specification because both the SEC and DED interrupts
are mapped to the same interrupt parent.
Patch v4 corrects a typo: 'interrupt-map' should be 'interrupts'.
Patch v5 corrects a copy-and-paste error, Haleakala is a 405exr.
arch/powerpc/boot/dts/haleakala.dts |5 -
arch/powerpc/boot/dts/kilauea.dts |5 -
arch/powerpc/boot/dts/makalu.dts|5 -
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..9384da6 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405exr";
+ compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupts = <0x5 0x4 /* ECC DED Error */
+ 0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..280 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupts = <0x5 0x4 /* ECC DED Error */
+ 0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..b2e0bf6 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,9 +90,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupts = <0x5 0x4 /* ECC DED Error */
+ 0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
--
1.6.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
Patch v3, based on review from Josh Boyer and Stefan Roese, simplifies
the interrupt specification because both the SEC and DED interrupts
are mapped to the same interrupt parent.
Patch v4 corrects a typo: 'interrupt-map' should be 'interrupts'.
arch/powerpc/boot/dts/haleakala.dts |5 -
arch/powerpc/boot/dts/kilauea.dts |5 -
arch/powerpc/boot/dts/makalu.dts|5 -
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..9384da6 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405exr";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupts = <0x5 0x4 /* ECC DED Error */
+ 0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..280 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupts = <0x5 0x4 /* ECC DED Error */
+ 0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..b2e0bf6 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,9 +90,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupts = <0x5 0x4 /* ECC DED Error */
+ 0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
--
1.6.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Add reboot notifier to Collaborative Memory Manager
When running Active Memory Sharing, pages can get marked as
"loaned" with the hypervisor by the CMM driver. This state gets
cleared by the system firmware when rebooting the partition.
When using kexec to boot a new kernel, this state never gets
cleared and the hypervisor and CMM driver can get out of sync
with respect to the number of pages currently marked "loaned".
Fix this by adding a reboot notifier to the CMM driver to deflate
the balloon and mark all pages as active.
Signed-off-by: Brian King
---
arch/powerpc/platforms/pseries/cmm.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff -puN arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_reboot_notifier
arch/powerpc/platforms/pseries/cmm.c
--- linux-2.6/arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_reboot_notifier
2008-12-17 09:59:00.0 -0600
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/cmm.c 2008-12-17
09:59:00.0 -0600
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -384,6 +385,26 @@ static void cmm_unregister_sysfs(struct
}
/**
+ * cmm_reboot_notifier - Make sure pages are not still marked as "loaned"
+ *
+ **/
+static int cmm_reboot_notifier(struct notifier_block *nb,
+ unsigned long action, void *unused)
+{
+ if (action == SYS_RESTART) {
+ if (cmm_thread_ptr)
+ kthread_stop(cmm_thread_ptr);
+ cmm_thread_ptr = NULL;
+ cmm_free_pages(loaned_pages);
+ }
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block cmm_reboot_nb = {
+ .notifier_call = cmm_reboot_notifier,
+};
+
+/**
* cmm_init - Module initialization
*
* Return value:
@@ -399,9 +420,12 @@ static int cmm_init(void)
if ((rc = register_oom_notifier(&cmm_oom_nb)) < 0)
return rc;
- if ((rc = cmm_sysfs_register(&cmm_sysdev)))
+ if ((rc = register_reboot_notifier(&cmm_reboot_nb)))
goto out_oom_notifier;
+ if ((rc = cmm_sysfs_register(&cmm_sysdev)))
+ goto out_reboot_notifier;
+
if (cmm_disabled)
return rc;
@@ -415,6 +439,8 @@ static int cmm_init(void)
out_unregister_sysfs:
cmm_unregister_sysfs(&cmm_sysdev);
+out_reboot_notifier:
+ unregister_reboot_notifier(&cmm_reboot_nb);
out_oom_notifier:
unregister_oom_notifier(&cmm_oom_nb);
return rc;
@@ -431,6 +457,7 @@ static void cmm_exit(void)
if (cmm_thread_ptr)
kthread_stop(cmm_thread_ptr);
unregister_oom_notifier(&cmm_oom_nb);
+ unregister_reboot_notifier(&cmm_reboot_nb);
cmm_free_pages(loaned_pages);
cmm_unregister_sysfs(&cmm_sysdev);
}
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Disable Collaborative Memory Manager for kdump
When running Active Memory Sharing, the Collaborative Memory Manager (CMM) may mark some pages as "loaned" with the hypervisor. Periodically, the CMM will query the hypervisor for a loan request, which is a single signed value. When kexec'ing into a kdump kernel, the CMM driver in the kdump kernel is not aware of the pages the previous kernel had marked as "loaned", so the hypervisor and the CMM driver are out of sync. This results in the CMM driver getting a negative loan request, which can then get treated as a large unsigned value and can cause kdump to hang due to the CMM driver inflating too large. Since there really is no clean way for the CMM driver in the kdump kernel to clean this up, simply disable CMM in the kdump kernel. This fixes hangs we were seeing doing kdump with AMS. Signed-off-by: Brian King --- arch/powerpc/platforms/pseries/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_no_kdump arch/powerpc/platforms/pseries/Kconfig --- linux-2.6/arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_no_kdump 2008-12-17 09:52:54.0 -0600 +++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/Kconfig2008-12-17 09:52:54.0 -0600 @@ -54,7 +54,7 @@ config PPC_SMLPAR config CMM tristate "Collaborative memory management" - depends on PPC_SMLPAR + depends on PPC_SMLPAR && !CRASH_DUMP default y help Select this option, if you want to enable the kernel interface _ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
Dear Felix Radensky, In message <21070179.p...@talk.nabble.com> you wrote: > > I'm experiencing a long (around 20 sec) delay from the moment > u-boot-1.3.4 passes control to linux and until the first kernel message > appears on console. This happens on custom board, I don't have access > to Canyonlands to test how it behaves. I did not modify anything in kernel > code to make it boot on custom board, just removed PCIX and PCIE0 nodes > from DTS. Try using a recent version of U-Boot as a first step (v2009.01-rc1). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Der Horizont vieler Menschen ist ein Kreis mit Radius Null -- und das nennen sie ihren Standpunkt. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
Patch v3, based on review from Josh Boyer and Stefan Roese, simplifies
the interrupt specification because both the SEC and DED interrupts
are mapped to the same interrupt parent.
arch/powerpc/boot/dts/haleakala.dts |5 +-
arch/powerpc/boot/dts/kilauea.dts |5 +-
arch/powerpc/boot/dts/makalu.dts|5 +-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..09522f3 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405exr";
+ compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupt-map = <0x5 0x4/* ECC DED Error */
+0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..68c88e2 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupt-map = <0x5 0x4/* ECC DED Error */
+0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..537d21f 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,9 +90,11 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ interrupt-parent = <&UIC2>;
+ interrupt-map = <0x5 0x4/* ECC DED Error */
+0x6 0x4>; /* ECC SEC Error */
};
MAL0: mcmal {
--
1.6.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add PPC/4xx "ibm,sdram-4xx-ddr2" EDAC MC Driver
On 12/18/08 9:56 AM, Josh Boyer wrote:
> On Wed, Dec 17, 2008 at 05:42:21PM -0800, Grant Erickson wrote:
>> This adds support for an EDAC memory controller adaptation driver for
>> the "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC
>> 405EX[r].
>>
>> Signed-off-by: Grant Erickson
>> ---
>>
>> drivers/edac/Kconfig|9 +
>> drivers/edac/Makefile |2 +-
>> drivers/edac/ppc4xx_edac.c | 1332
>> +++
>> drivers/edac/ppc4xx_edac.h | 179 +
>> 4 files changed, 1521 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
>> new file mode 100644
>> index 000..5caadc6
>> --- /dev/null
>> +++ b/drivers/edac/ppc4xx_edac.c
>> @@ -0,0 +1,1332 @@
>> [ ... ]
>> +/*
>> + * This file implements a driver for monitoring and handling events
>> + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM
>> + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX.
>> + *
>> + * As realized in the 405EX[r], this controller features:
>> + *
>> [ ... ]
>> + *
>> + * As realized in the 440SP and 440SPe, this controller changes/adds:
>> + *
>> [ ... ]
>> + *
>> + * As realized in the 460EX and 460GT, this controller changes/adds:
>> + *
>> [ ... ]
>> + *
>> + * At present, this driver has ONLY been tested against the controller
>> + * realization in the 405EX[r] on the AMCC Kilauea and Haleakala
>> + * boards (256 MiB w/o ECC memory soldered onto the board) and a
>> + * proprietary board based on those designs (128 MiB ECC memory, also
>> + * soldered onto the board).
>> + *
>> + * Dynamic feature detection and handling needs to be added for the
>> + * other realizations of this controller listed above.
>
> Then I think you should omit anything about 440SP and 460 until it works.
I'd like to include as many breadcrumbs as possible--in the form of
comments, so that in days, weeks, months or years when I or someone else
come along to implement support for said controller realizations, there's
some information to get started in the right direction.
>> +#define PPC4XX_EDAC_MODULE_REVISION " v1.0.0 " __DATE__
>
> Do you really want __DATE__ there? It's sort of meaningless.
I'd agree; however, this seems to be the prevailing convention for this
driver:
% grep '__DATE__' *
amd76x_edac.c:#define AMD76X_REVISION " Ver: 2.0.2 " __DATE__
e752x_edac.c:#define E752X_REVISION " Ver: 2.0.2 " __DATE__
e7xxx_edac.c:#defineE7XXX_REVISION " Ver: 2.0.2 " __DATE__
edac_module.c:#define EDAC_VERSION "Ver: 2.1.0 " __DATE__
i5000_edac.c:#define I5000_REVISION" Ver: 2.0.12 " __DATE__
i82860_edac.c:#define I82860_REVISION " Ver: 2.0.2 " __DATE__
i82875p_edac.c:#define I82875P_REVISION " Ver: 2.0.2 " __DATE__
i82975x_edac.c:#define I82975X_REVISION " Ver: 1.0.0 " __DATE__
mpc85xx_edac.h:#define MPC85XX_REVISION " Ver: 2.0.0 " __DATE__
mv64x60_edac.h:#define MV64x60_REVISION " Ver: 2.0.0 " __DATE__
r82600_edac.c:#define R82600_REVISION " Ver: 2.0.2 " __DATE__
When in Rome or do the right thing?
>> +/*
>> + * Convenience macros to support indirect DCR read and write access to
>> + * the SDRAM controller registers.
>> + *
>> + * TODO: If in the future the indirect address and data windows for
>> + * this controller are not the same across realizations, the windows
>> + * will have to be read from the device tree and these mnemonic
>> + * accessors will have to become programmatic in a manner similar to
>> + * the existing dcr_{map,unmap,read,write} functions.
>> + */
>> +#define mfsdram(reg) mfdcri(SDRAM0, SDRAM_ ## reg)
>> +#define mtsdram(reg, value) mtdcri(SDRAM0, SDRAM_ ## reg, value)
>
> I have no general problems with using this, but others might want you to
> use dcr_read and dcr_write. They get the DCR offsets from the device
> tree. It would be a cleaner way to handle that.
I covered this thread at
.
Provided you're OK with this as-is, I'll leave it as-is.
I'd prefer more perspective across a broader set of IDCR address/data window
usage cases before I proposed a dcri_read/dcri_write implementation.
>> +/*
>> + * PPC4xx SDRAM memory controller private instance data
>> + */
>> +struct ppc4xx_edac_pdata {
>> + struct {
>> + int sec; /* Single-bit correctable error IRQ assigned */
>> + int ded; /* Double-bit detectable error IRQ assigned */
>> + } irqs;
>> +};
>
> Is the sub-structure for irqs really needed? This could just be
>
> struct ppc4xx_edac_irqs {
> int sec;
> int ded;
> };
Were I to implement feature flags and other things to further parameterize
the driver to handle the aforementioned controller realizations, I'd have
defined this structure as:
struct ppc4xx_edac_pdata {
u32 features;
unsigned int banks;
size_t width;
struct {
int sec;/* Single-bit correctable error IRQ assig
Re: Long boot delay on 460EX with 2.6.28-rc8
On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote: > >Hi, > >I'm experiencing a long (around 20 sec) delay from the moment >u-boot-1.3.4 passes control to linux and until the first kernel message >appears on console. This happens on custom board, I don't have access >to Canyonlands to test how it behaves. I did not modify anything in kernel >code to make it boot on custom board, just removed PCIX and PCIE0 nodes >from DTS. > >Has anyone experienced similar behavior with 460EX ? Any hints what can >cause this ? I booted on a canyonlands this morning (after having removed the brown paper bag that preventing me from booting it yesterday). I saw no delay. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
On Thu, Dec 18, 2008 at 12:51:29PM -0600, Kumar Gala wrote: > > On Dec 18, 2008, at 10:02 AM, Anton Vorontsov wrote: > >> On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote: >>> >>> Hi, >>> >>> I'm experiencing a long (around 20 sec) delay from the moment >>> u-boot-1.3.4 passes control to linux and until the first kernel >>> message >>> appears on console. >> >> I saw somewhat similar behaviour on 83xx target, the cause was >> that my .config file contained bogus UDBG_RTAS_CONSOLE=y symbol >> (or was it PPC_EARLY_DEBUG_RTAS_PANEL=y? Or HVC_UDBG=y? I don't >> quite remember). >> >> Obviously, on 83xx we don't have RTAS or HVC stuff, but kernel >> didn't oops or hang completely, it was busy with executing various >> delays in those drivers and then just continued to load. > > Why are these drivers even doing anything on 83xx? Seems like they need > something to bind against or some detection of "HW". Early console/UDBG is known to cause problems if enabled on inappropriate hardware. They start working very early, so it's hard for them to do the hw detection (no device tree yet, I presume). -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
On Dec 18, 2008, at 10:02 AM, Anton Vorontsov wrote: On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote: Hi, I'm experiencing a long (around 20 sec) delay from the moment u-boot-1.3.4 passes control to linux and until the first kernel message appears on console. I saw somewhat similar behaviour on 83xx target, the cause was that my .config file contained bogus UDBG_RTAS_CONSOLE=y symbol (or was it PPC_EARLY_DEBUG_RTAS_PANEL=y? Or HVC_UDBG=y? I don't quite remember). Obviously, on 83xx we don't have RTAS or HVC stuff, but kernel didn't oops or hang completely, it was busy with executing various delays in those drivers and then just continued to load. Why are these drivers even doing anything on 83xx? Seems like they need something to bind against or some detection of "HW". - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] Few patches for galak/powerpc.git next
On Dec 18, 2008, at 10:36 AM, Anton Vorontsov wrote: Kumar, Timur, Much thanks for the reviews and comments, here is an updated patch set. Changes: - BCSR GPIO bindings were split into a separate patch. - simple_gpiochip_init() return value changed to void (the function prints errors by itself, and we don't check its return value anyway). p.s. +- reg : Should contain the address and the lenght of the GPIO bank + register; spelling - length semicolon at add of register can be dropped. Umm.. the semicolon denotes the end of the list item. Anyhow, I see that periods are used more widely, so I replaced semicolons with periods. all applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On Thu, Dec 18, 2008 at 10:04:48AM -0800, Grant Erickson wrote:
>On 12/18/08 9:56 AM, Josh Boyer wrote:
>> On Thu, Dec 18, 2008 at 09:04:23AM +0100, Stefan Roese wrote:
>>> On Thursday 18 December 2008, Grant Erickson wrote:
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts index 513bc43..64880ab 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,14 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405exr";
+ compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&SDRAM0>;
+ interrupts = <0x0 0x1>;
+ interrupt-map = >>> + /* ECCSEC Error */ 0x1 &UIC2 0x6 0x4>;
+ interrupt-map-mask = <0x>;
>>>
>>> When all interrupts are mapped the same parent, this should do as well:
>>>
>>> interrupt-parent = <&UIC2>;
>>> interrupts = <0x5 0x4 /* ECCDED Error */
>>> 0x6 0x4>; /* ECCSEC Error */
>>>
>>> Other than this:
>>>
>>> Acked-by: Stefan Roese
>>
>> Yeah, I agree. Adding an interrupt map when it's not needed is
>> just complexity that doesn't need to be there.
>
>Stefan and Josh:
>
>From a programmatic perspective, does the above still allow the code to
>index virtual interrupt indices 0 and 1 rather than 5 and 6 when calling
>irq_of_parse_and_map()?
Yes. The index parameter to irq_of_parse_and_map is just an index into
the interrupts property. So index 0 will use the first set of numbers
that matches the required #interrupt-cells. In this case it's two, one
for the hardware irq number and one for the level/edge/polarity settings.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] OpenFirmware support for the spi_mpc83xx driver
On Fri, Dec 05, 2008 at 11:09:36PM +0300, Anton Vorontsov wrote: > Hi all, > > The patch series are used to support SPI via the OF SPI subsystem > (driver/of/of_spi.c). Now the driver is able to manage its own > chip selects, and doesn't need any auxiliary support from the > board files or fsl_soc constructors. > > The series also contains PowerPC portions of the MMC SPI support. > > Since the series touches spi and powerpc trees, I think it would > be most convenient to pass it via one of these trees. The patches > doesn't touch any SPI functionality, only some probe routines, so > I believe powerpc.git is the best candidate... > > The other reason for powerpc tree is that the patches depends on > other patches as found in paulus/powerpc.git + of_gpio_count() > as found here: > http://ozlabs.org/pipermail/linuxppc-dev/2008-December/065917.html > > David, if you're OK with the patches, may I ask you to sign off on > the ones that touch drivers/spi so that we could pass it via Kumar's > powerpc.git? David, I'm sorry for bothering you, but have you had a chance to look into this patch set? Thanks, > The queue: > > [1/7] powerpc: Implement get_brgfreq() and get_baudrate() stubs > [2/7] spi_mpc83xx: Fix sparse warnings > [3/7] spi_mpc83xx: Rework chip selects handling > [4/7] spi_mpc83xx: Add OF platform driver bindings > [5/7] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb boards > [6/7] powerpc: Add mmc-spi-slot bindings > [7/7] powerpc/83xx: Add mmc-spi support via the device tree for MPC8323E-RDB -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/6] ucc_geth: Cleanup repetitive ucc_geth_memclean() calls
No need to call ucc_geth_memclean() so many times, just check for
errors in ucc_geth_open(), and call ucc_geth_stop() in case of errors.
The ucc_geth_stop() may be called anytime and will do the right thing.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 31 +--
1 files changed, 1 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 1ba2855..70208c6 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2420,7 +2420,6 @@ static int ucc_struct_init(struct ucc_geth_private *ugeth)
if (ucc_fast_init(uf_info, &ugeth->uccf)) {
if (netif_msg_probe(ugeth))
ugeth_err("%s: Failed to init uccf.", __func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
@@ -2476,7 +2475,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
if (netif_msg_ifup(ugeth))
ugeth_err("%s: Bad number of Rx threads value.",
__func__);
- ucc_geth_memclean(ugeth);
return -EINVAL;
break;
}
@@ -2501,7 +2499,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
if (netif_msg_ifup(ugeth))
ugeth_err("%s: Bad number of Tx threads value.",
__func__);
- ucc_geth_memclean(ugeth);
return -EINVAL;
break;
}
@@ -2555,7 +2552,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
if (netif_msg_ifup(ugeth))
ugeth_err("%s: IPGIFG initialization parameter too
large.",
__func__);
- ucc_geth_memclean(ugeth);
return ret_val;
}
@@ -2573,7 +2569,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
if (netif_msg_ifup(ugeth))
ugeth_err("%s: Half Duplex initialization parameter too
large.",
__func__);
- ucc_geth_memclean(ugeth);
return ret_val;
}
@@ -2628,7 +2623,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
ugeth_err
("%s: Can not allocate memory for Tx bd
rings.",
__func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
/* Zero unused end of bd ring, according to spec */
@@ -2664,7 +2658,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
ugeth_err
("%s: Can not allocate memory for Rx bd
rings.",
__func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
}
@@ -2680,7 +2673,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
if (netif_msg_ifup(ugeth))
ugeth_err("%s: Could not allocate tx_skbuff",
__func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
@@ -2712,7 +2704,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
if (netif_msg_ifup(ugeth))
ugeth_err("%s: Could not allocate rx_skbuff",
__func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
@@ -2746,7 +2737,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
ugeth_err
("%s: Can not allocate DPRAM memory for
p_tx_glbl_pram.",
__func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
ugeth->p_tx_glbl_pram =
@@ -2769,7 +2759,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
ugeth_err
("%s: Can not allocate DPRAM memory for
p_thread_data_tx.",
__func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
@@ -2799,7 +2788,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
ugeth_err
("%s: Can not allocate DPRAM memory for
p_send_q_mem_reg.",
__func__);
- ucc_geth_memclean(ugeth);
return -ENOMEM;
}
@@ -2843,7 +2831,6 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
ugeth_err
("%s: Can not
[PATCH 5/6] ucc_geth: Fix IO memory (un)mapping code
The driver doesn't check ioremap() return value, and doesn't free the
remapped memory.
This patch fixes it.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 70208c6..20c065c 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2218,7 +2218,10 @@ static void ucc_geth_memclean(struct ucc_geth_private
*ugeth)
while (!list_empty(&ugeth->ind_hash_q))
put_enet_addr_container(ENET_ADDR_CONT_ENTRY
(dequeue(&ugeth->ind_hash_q)));
-
+ if (ugeth->ug_regs) {
+ iounmap(ugeth->ug_regs);
+ ugeth->ug_regs = NULL;
+ }
}
static void ucc_geth_set_multi(struct net_device *dev)
@@ -2423,7 +2426,12 @@ static int ucc_struct_init(struct ucc_geth_private
*ugeth)
return -ENOMEM;
}
- ugeth->ug_regs = (struct ucc_geth __iomem *) ioremap(uf_info->regs,
sizeof(struct ucc_geth));
+ ugeth->ug_regs = ioremap(uf_info->regs, sizeof(*ugeth->ug_regs));
+ if (!ugeth->ug_regs) {
+ if (netif_msg_probe(ugeth))
+ ugeth_err("%s: Failed to ioremap regs.", __func__);
+ return -ENOMEM;
+ }
return 0;
}
@@ -3691,7 +3699,7 @@ static int ucc_geth_open(struct net_device *dev)
if (err) {
if (netif_msg_ifup(ugeth))
ugeth_err("%s: Cannot configure internal struct,
aborting.", dev->name);
- return err;
+ goto out_err_stop;
}
napi_enable(&ugeth->napi);
@@ -3754,6 +3762,7 @@ static int ucc_geth_open(struct net_device *dev)
out_err:
napi_disable(&ugeth->napi);
+out_err_stop:
ucc_geth_stop(ugeth);
return err;
}
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/6] ucc_geth: Remove UGETH_FILTERING dead code
The code appears to be dead: nobody call these functions, plus build
breaks when UGETH_FILTERING is enabled:
ucc_geth.c:1848: warning: 'struct enet_addr' declared inside parameter list
ucc_geth.c:1848: warning: its scope is only this definition or declaration,
which is probably not what you want
ucc_geth.c: In function 'ugeth_82xx_filtering_get_match_addr_in_hash':
ucc_geth.c:1856: error: dereferencing pointer to incomplete type
ucc_geth.c:1874: error: dereferencing pointer to incomplete type
ucc_geth.c:1877: warning: return from incompatible pointer type
ucc_geth.c: At top level:
ucc_geth.c:1885: warning: 'struct enet_addr' declared inside parameter list
ucc_geth.c: In function 'ugeth_82xx_filtering_add_addr_in_hash':
ucc_geth.c:1894: error: dereferencing pointer to incomplete type
ucc_geth.c:1909: warning: passing argument 2 of
'ugeth_82xx_filtering_get_match_addr_in_hash' from incompatible pointer type
ucc_geth.c:1909: warning: assignment from incompatible pointer type
ucc_geth.c:1918: error: dereferencing pointer to incomplete type
ucc_geth.c: At top level:
ucc_geth.c:1928: warning: 'struct enet_addr' declared inside parameter list
ucc_geth.c: In function 'ugeth_82xx_filtering_clear_addr_in_hash':
ucc_geth.c:1947: warning: passing argument 2 of
'ugeth_82xx_filtering_get_match_addr_in_hash' from incompatible pointer type
ucc_geth.c:1947: warning: assignment from incompatible pointer type
ucc_geth.c:1954: error: dereferencing pointer to incomplete type
ucc_geth.c: At top level:
ucc_geth.c:2060: warning: 'struct enet_addr' declared inside parameter list
ucc_geth.c: In function 'ugeth_82xx_filtering_add_addr_in_paddr':
ucc_geth.c:2064: error: dereferencing pointer to incomplete type
ucc_geth.c:2073: error: dereferencing pointer to incomplete type
ucc_geth.c:2075: warning: passing argument 2 of 'hw_add_addr_in_paddr' from
incompatible pointer type
make[2]: *** [ucc_geth.o] Error 1
The code is there since the driver was merged, and nobody seem to be
interested in fixing or actually using it. If we ever want the
filtering support, we can always revert the patch and fix it, but so
far it just draws reader's attention.
Signed-off-by: Anton Vorontsov
---
drivers/net/Kconfig|4 -
drivers/net/ucc_geth.c | 262
2 files changed, 0 insertions(+), 266 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 231eeaf..88b684e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2276,10 +2276,6 @@ config UGETH_MAGIC_PACKET
bool "Magic Packet detection support"
depends on UCC_GETH
-config UGETH_FILTERING
- bool "Mac address filtering support"
- depends on UCC_GETH
-
config UGETH_TX_ON_DEMAND
bool "Transmit on Demand support"
depends on UCC_GETH
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 20c065c..6c2d074 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -188,17 +188,6 @@ static void mem_disp(u8 *addr, int size)
}
#endif /* DEBUG */
-#ifdef CONFIG_UGETH_FILTERING
-static void enqueue(struct list_head *node, struct list_head *lh)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&ugeth_lock, flags);
- list_add_tail(node, lh);
- spin_unlock_irqrestore(&ugeth_lock, flags);
-}
-#endif /* CONFIG_UGETH_FILTERING */
-
static struct list_head *dequeue(struct list_head *lh)
{
unsigned long flags;
@@ -391,23 +380,6 @@ static int dump_init_enet_entries(struct ucc_geth_private
*ugeth,
}
#endif
-#ifdef CONFIG_UGETH_FILTERING
-static struct enet_addr_container *get_enet_addr_container(void)
-{
- struct enet_addr_container *enet_addr_cont;
-
- /* allocate memory */
- enet_addr_cont = kmalloc(sizeof(struct enet_addr_container),
GFP_KERNEL);
- if (!enet_addr_cont) {
- ugeth_err("%s: No memory for enet_addr_container object.",
- __func__);
- return NULL;
- }
-
- return enet_addr_cont;
-}
-#endif /* CONFIG_UGETH_FILTERING */
-
static void put_enet_addr_container(struct enet_addr_container *enet_addr_cont)
{
kfree(enet_addr_cont);
@@ -420,28 +392,6 @@ static void set_mac_addr(__be16 __iomem *reg, u8 *mac)
out_be16(®[2], ((u16)mac[1] << 8) | mac[0]);
}
-#ifdef CONFIG_UGETH_FILTERING
-static int hw_add_addr_in_paddr(struct ucc_geth_private *ugeth,
-u8 *p_enet_addr, u8 paddr_num)
-{
- struct ucc_geth_82xx_address_filtering_pram *p_82xx_addr_filt;
-
- if (!(paddr_num < NUM_OF_PADDRS)) {
- ugeth_warn("%s: Illegal paddr_num.", __func__);
- return -EINVAL;
- }
-
- p_82xx_addr_filt =
- (struct ucc_geth_82xx_address_filtering_pram *)
ugeth->p_rx_glbl_pram->
- addressfiltering;
-
- /* Ethernet frames are defined in Little Endian mode,*/
- /* therefore to insert the address we reverse the bytes. */
-
[PATCH 2/6] ucc_geth: Fix TX watchdog timeout handling
The timeout handling code is currently broken in several ways:
- It calls stop() (which frees all the memory and IRQ), and then
calls startup() (which won't re-request IRQ, neither it will
re-init the Fast UCC structure).
- It calls these routines from the softirq context, which is wrong,
since stop() calls free_irq() (which might sleep) and startup()
allocates things with GFP_KERNEL.
- It won't soft-reset the PHY. We need the PHY reset for at least
MPC8360E-MDS boards with Marvell 88E PHY, the PHY won't recover
from timeouts w/o the reset.
So the patch fixes these problems by implementing the workqueue for the
timeout handling, and there we fully re-open the device via close() and
open() calls. The close/open paths do the right things, and I can see
that the driver actually survive the timeouts.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 37 +
drivers/net/ucc_geth.h |1 +
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 79e6d3d..98a7bd4 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3355,13 +3355,17 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
return 0;
}
-/* ucc_geth_timeout gets called when a packet has not been
- * transmitted after a set amount of time.
- * For now, assume that clearing out all the structures, and
- * starting over will fix the problem. */
-static void ucc_geth_timeout(struct net_device *dev)
+static int ucc_geth_close(struct net_device *dev);
+static int ucc_geth_open(struct net_device *dev);
+
+/* Reopen device. This will reset the MAC and PHY. */
+static void ucc_geth_timeout_work(struct work_struct *work)
{
- struct ucc_geth_private *ugeth = netdev_priv(dev);
+ struct ucc_geth_private *ugeth;
+ struct net_device *dev;
+
+ ugeth = container_of(work, struct ucc_geth_private, timeout_work);
+ dev = ugeth->dev;
ugeth_vdbg("%s: IN", __func__);
@@ -3370,13 +3374,29 @@ static void ucc_geth_timeout(struct net_device *dev)
ugeth_dump_regs(ugeth);
if (dev->flags & IFF_UP) {
- ucc_geth_stop(ugeth);
- ucc_geth_startup(ugeth);
+ /*
+* Must reset MAC *and* PHY. This is done by reopening
+* the device.
+*/
+ ucc_geth_close(dev);
+ ucc_geth_open(dev);
}
netif_tx_schedule_all(dev);
}
+/*
+ * ucc_geth_timeout gets called when a packet has not been
+ * transmitted after a set amount of time.
+ */
+static void ucc_geth_timeout(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+
+ netif_carrier_off(dev);
+ schedule_work(&ugeth->timeout_work);
+}
+
/* This is called by the kernel when a frame is ready for transmission. */
/* It is pointed to by the dev->hard_start_xmit function pointer */
static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -4029,6 +4049,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
dev->hard_start_xmit = ucc_geth_start_xmit;
dev->tx_timeout = ucc_geth_timeout;
dev->watchdog_timeo = TX_TIMEOUT;
+ INIT_WORK(&ugeth->timeout_work, ucc_geth_timeout_work);
netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, UCC_GETH_DEV_WEIGHT);
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = ucc_netpoll;
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index abc0e22..d74d2f7 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1186,6 +1186,7 @@ struct ucc_geth_private {
struct ucc_fast_private *uccf;
struct net_device *dev;
struct napi_struct napi;
+ struct work_struct timeout_work;
struct ucc_geth __iomem *ug_regs;
struct ucc_geth_init_pram *p_init_enet_param_shadow;
struct ucc_geth_exf_global_pram __iomem *p_exf_glbl_param;
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/6] ucc_geth: Fix IRQ freeing code in ucc_geth_open()
open() routine calls stop() in case of errors, the function will try
to free the requested IRQ. But we don't know if it was actually
requested, so the code might issue bogus free_irq(0, dev) call.
Fix this by rearranging the code so that now request_irq() is the last
call in the open() routine, and move free_irq() into the close().
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 98a7bd4..1ba2855 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2300,8 +2300,6 @@ static void ucc_geth_stop(struct ucc_geth_private *ugeth)
tempval &= ~(MACCFG1_ENABLE_RX | MACCFG1_ENABLE_TX);
out_be32(&ug_regs->maccfg1, tempval);
- free_irq(ugeth->ug_info->uf_info.irq, ugeth->dev);
-
ucc_geth_memclean(ugeth);
}
@@ -3761,21 +3759,20 @@ static int ucc_geth_open(struct net_device *dev)
phy_start(ugeth->phydev);
- err =
- request_irq(ugeth->ug_info->uf_info.irq, ucc_geth_irq_handler, 0,
- "UCC Geth", dev);
+ err = ugeth_enable(ugeth, COMM_DIR_RX_AND_TX);
if (err) {
if (netif_msg_ifup(ugeth))
- ugeth_err("%s: Cannot get IRQ for net device,
aborting.",
- dev->name);
+ ugeth_err("%s: Cannot enable net device, aborting.",
dev->name);
ucc_geth_stop(ugeth);
goto out_err;
}
- err = ugeth_enable(ugeth, COMM_DIR_RX_AND_TX);
+ err = request_irq(ugeth->ug_info->uf_info.irq, ucc_geth_irq_handler,
+ 0, "UCC Geth", dev);
if (err) {
if (netif_msg_ifup(ugeth))
- ugeth_err("%s: Cannot enable net device, aborting.",
dev->name);
+ ugeth_err("%s: Cannot get IRQ for net device,
aborting.",
+ dev->name);
ucc_geth_stop(ugeth);
goto out_err;
}
@@ -3801,6 +3798,8 @@ static int ucc_geth_close(struct net_device *dev)
ucc_geth_stop(ugeth);
+ free_irq(ugeth->ug_info->uf_info.irq, ugeth->dev);
+
phy_disconnect(ugeth->phydev);
ugeth->phydev = NULL;
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/6] ucc_geth: Fix endless loop in stop_{tx,rx} routines
Currently the routines wait for the various bits w/o an assumption that
bits may never get set. When timeouts happen I see that these bits never
get set and so the routines hang the kernel.
With this patch we'll wait the graceful stop for 100 ms, and then will
simply exit. There is nothing* we can do about that, but it's OK since
we'll do full reset later.
* Well, actually, there is also not-graceful variant for the TX stop,
but specs says that we never should use it.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index c87747b..79e6d3d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1647,6 +1647,7 @@ static int ugeth_graceful_stop_tx(struct ucc_geth_private
*ugeth)
struct ucc_fast_private *uccf;
u32 cecr_subblock;
u32 temp;
+ int i = 10;
uccf = ugeth->uccf;
@@ -1664,8 +1665,9 @@ static int ugeth_graceful_stop_tx(struct ucc_geth_private
*ugeth)
/* Wait for command to complete */
do {
+ msleep(10);
temp = in_be32(uccf->p_ucce);
- } while (!(temp & UCCE_GRA));
+ } while (!(temp & UCCE_GRA) && --i);
uccf->stopped_tx = 1;
@@ -1677,6 +1679,7 @@ static int ugeth_graceful_stop_rx(struct ucc_geth_private
* ugeth)
struct ucc_fast_private *uccf;
u32 cecr_subblock;
u8 temp;
+ int i = 10;
uccf = ugeth->uccf;
@@ -1694,9 +1697,9 @@ static int ugeth_graceful_stop_rx(struct ucc_geth_private
* ugeth)
ucc_num);
qe_issue_cmd(QE_GRACEFUL_STOP_RX, cecr_subblock,
QE_CR_PROTOCOL_ETHERNET, 0);
-
+ msleep(10);
temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
- } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX));
+ } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX) && --i);
uccf->stopped_rx = 1;
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On 12/18/08 9:56 AM, Josh Boyer wrote:
> On Thu, Dec 18, 2008 at 09:04:23AM +0100, Stefan Roese wrote:
>> On Thursday 18 December 2008, Grant Erickson wrote:
>>> diff --git a/arch/powerpc/boot/dts/haleakala.dts
>>> b/arch/powerpc/boot/dts/haleakala.dts index 513bc43..64880ab 100644
>>> --- a/arch/powerpc/boot/dts/haleakala.dts
>>> +++ b/arch/powerpc/boot/dts/haleakala.dts
>>> @@ -89,8 +89,14 @@
>>> clock-frequency = <0>; /* Filled in by U-Boot */
>>>
>>> SDRAM0: memory-controller {
>>> - compatible = "ibm,sdram-405exr";
>>> + compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
>>> dcr-reg = <0x010 0x002>;
>>> + #interrupt-cells = <1>;
>>> + interrupt-parent = <&SDRAM0>;
>>> + interrupts = <0x0 0x1>;
>>> + interrupt-map = >> + /* ECCSEC Error */ 0x1 &UIC2 0x6 0x4>;
>>> + interrupt-map-mask = <0x>;
>>
>> When all interrupts are mapped the same parent, this should do as well:
>>
>> interrupt-parent = <&UIC2>;
>> interrupts = <0x5 0x4 /* ECCDED Error */
>> 0x6 0x4>; /* ECCSEC Error */
>>
>> Other than this:
>>
>> Acked-by: Stefan Roese
>
> Yeah, I agree. Adding an interrupt map when it's not needed is
> just complexity that doesn't need to be there.
Stefan and Josh:
>From a programmatic perspective, does the above still allow the code to
index virtual interrupt indices 0 and 1 rather than 5 and 6 when calling
irq_of_parse_and_map()?
Regards,
Grant
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On Thu, Dec 18, 2008 at 09:04:23AM +0100, Stefan Roese wrote:
>On Thursday 18 December 2008, Grant Erickson wrote:
>> Added additional information for type and compatibility strings and
>> interrupt information to the SDRAM0 memory-controller device tree
>> nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
>> with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
>>
>> Signed-off-by: Grant Erickson
>> ---
>> As support in the associated EDAC adapter driver is added over time,
>> similar changes will/should be made to the DTS files for boards
>> leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
>> including the 440SP, 440SPe, 460EX, 460GT and 460SX.
>>
>> Patch v2, based on review from David Gibson, removes the 'device_type'
>> field because it is only used for legacy OpenFirmware method
>> interfaces and no such compatibility is warranted here. In addition,
>> removed address- and size-cells as this node has no children.
>>
>> arch/powerpc/boot/dts/haleakala.dts |8 +-
>> arch/powerpc/boot/dts/kilauea.dts |8 +-
>> arch/powerpc/boot/dts/makalu.dts|8 +-
>> 3 files changed, 21 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/boot/dts/haleakala.dts
>> b/arch/powerpc/boot/dts/haleakala.dts index 513bc43..64880ab 100644
>> --- a/arch/powerpc/boot/dts/haleakala.dts
>> +++ b/arch/powerpc/boot/dts/haleakala.dts
>> @@ -89,8 +89,14 @@
>> clock-frequency = <0>; /* Filled in by U-Boot */
>>
>> SDRAM0: memory-controller {
>> -compatible = "ibm,sdram-405exr";
>> +compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
>> dcr-reg = <0x010 0x002>;
>> +#interrupt-cells = <1>;
>> +interrupt-parent = <&SDRAM0>;
>> +interrupts = <0x0 0x1>;
>> +interrupt-map = > + /* ECCSEC Error */ 0x1 &UIC2 0x6 0x4>;
>> +interrupt-map-mask = <0x>;
>
>When all interrupts are mapped the same parent, this should do as well:
>
> interrupt-parent = <&UIC2>;
> interrupts = <0x5 0x4 /* ECCDED Error */
> 0x6 0x4>; /* ECCSEC Error */
>
>Other than this:
>
>Acked-by: Stefan Roese
Yeah, I agree. Adding an interrupt map when it's not needed is
just complexity that doesn't need to be there.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add PPC/4xx "ibm,sdram-4xx-ddr2" EDAC MC Driver
On Wed, Dec 17, 2008 at 05:42:21PM -0800, Grant Erickson wrote: >This adds support for an EDAC memory controller adaptation driver for >the "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC >405EX[r]. > >Signed-off-by: Grant Erickson >--- >At present, this driver has been developed and tested against the >controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and >Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and >a proprietary board based on those designs (128 MiB ECC memory, also >soldered onto the board). > >In the future, dynamic feature detection and handling needs to be >added for the other realizations of this controller found in the >440SP, 440SPe, 460EX, 460GT and 460SX. > >Eventually, this driver will likely be evolved and adapted to the >above variant realizations of this controller as well as broken apart >to handle the other known ECC-capable controllers prevalent in other >PPC4xx processors: > > - IBM SDRAM (405GP, 405CR and 405EP) "ibm,sdram-4xx" > - IBM DDR1 (440GP, 440GX, 440EP and 440GR) "ibm,sdram-4xx-ddr" > - Denali DDR1/DDR2 (440EPX and 440GRX) "denali,sdram-4xx-ddr2" > >Patch v2 removes the 'type' field from the of_device_id match >structure to reflect the corresponding removal of the 'device_type' >field from the device tree node. > > drivers/edac/Kconfig|9 + > drivers/edac/Makefile |2 +- > drivers/edac/ppc4xx_edac.c | 1332 +++ > drivers/edac/ppc4xx_edac.h | 179 + > 4 files changed, 1521 insertions(+), 1 deletions(-) > >diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig >index e0dbd38..ae950d7 100644 >--- a/drivers/edac/Kconfig >+++ b/drivers/edac/Kconfig >@@ -167,4 +167,13 @@ config EDAC_CELL > Cell Broadband Engine internal memory controller > on platform without a hypervisor > >+config EDAC_PPC4XX >+ tristate "PPC4xx IBM DDR2 Memory Controller" >+ depends on EDAC_MM_EDAC && 4xx >+ help >+This enables support for EDAC on the ECC memory used >+with the IBM DDR2 memory controller found in various >+PowerPC 4xx embedded processors such as the 405EX[r], >+440SP, 440SPe, 460EX, 460GT and 460SX. >+ > endif # EDAC >diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile >index 62c2d9b..de8d4c1 100644 >--- a/drivers/edac/Makefile >+++ b/drivers/edac/Makefile >@@ -33,4 +33,4 @@ obj-$(CONFIG_EDAC_PASEMI)+= pasemi_edac.o > obj-$(CONFIG_EDAC_MPC85XX)+= mpc85xx_edac.o > obj-$(CONFIG_EDAC_MV64X60)+= mv64x60_edac.o > obj-$(CONFIG_EDAC_CELL) += cell_edac.o >- >+obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o >diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c >new file mode 100644 >index 000..5caadc6 >--- /dev/null >+++ b/drivers/edac/ppc4xx_edac.c >@@ -0,0 +1,1332 @@ >+/* >+ * Copyright (c) 2008 Nuovation System Designs, LLC >+ * Grant Erickson >+ * >+ * 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; version 2 of the >+ * License. >+ * >+ */ >+ >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+ >+#include >+ >+#include "edac_core.h" >+#include "ppc4xx_edac.h" >+ >+/* >+ * This file implements a driver for monitoring and handling events >+ * associated with the IMB DDR2 ECC controller found in the AMCC/IBM >+ * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. >+ * >+ * As realized in the 405EX[r], this controller features: >+ * >+ * - Support for registered- and non-registered DDR1 and DDR2 memory. >+ * - 32-bit or 16-bit memory interface with optional ECC. >+ * >+ * o ECC support includes: >+ * >+ * - 4-bit SEC/DED >+ * - Aligned-nibble error detect >+ * - Bypass mode >+ * >+ * - Two (2) memory banks/ranks. >+ * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per >+ * bank/rank in 16-bit mode. >+ * >+ * As realized in the 440SP and 440SPe, this controller changes/adds: >+ * >+ * - 64-bit or 32-bit memory interface with optional ECC. >+ * >+ * o ECC support includes: >+ * >+ * - 8-bit SEC/DED >+ * - Aligned-nibble error detect >+ * - Bypass mode >+ * >+ * - Up to 4 GiB per bank/rank in 64-bit mode and up to 2 GiB >+ * per bank/rank in 32-bit mode. >+ * >+ * As realized in the 460EX and 460GT, this controller changes/adds: >+ * >+ * - 64-bit or 32-bit memory interface with optional ECC. >+ * >+ * o ECC support includes: >+ * >+ * - 8-bit SEC/DED >+ * - Aligned-nibble error detect >+ * - Bypass mode >+ * >+ * - Four (4) memory banks/ranks. >+ * - Up to 16 GiB per bank/rank in 64-bit mode and up to 8 GiB >+ * per bank/rank in 32-bit mode. >+ * >+ * At present, this driver has ONLY been tested against the
Re: gianfar tries to free an irq from interrupt context
On Thu, Dec 18, 2008 at 06:38:26PM +0100, M B wrote: > Hi, > > I'm having Problems with the gianfar Ethernet. eth1 is working fine, > but eth0 is making trouble. It's making trouble in u-boot as well, so > it could as well be a hardware problem. > First of all eth0 receives some frame errors (frame: in ifconfig), but > eth1 doesn't. > eth1 performs well under a ping flood, but eth0 produces the following > WARN_ON() after some time. > I'm using linux-2.6.26 ARCH ppc on a MPC8347 with 2 different 100MB PHYs. This patch should fix the issue: commit ab9399059bb85a94758f42fb25607e440e926cc6 Author: Sebastian Siewior Date: Tue Aug 19 21:12:45 2008 +0200 net: don't grab a mutex within a timer context in gianfar http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab9399059bb85a94758f42fb25607e440e926cc6 > Is my Board just triggering this error or responsible for it? The MAC could not send the packet within specified timeout value, it might be normal, or not. This depends. But the WARN_ON() you observe is a bug. > Regards > > Markus > > [ cut here ] > Badness at kernel/irq/manage.c:441 > NIP: c003e9c0 LR: c014e5b4 CTR: c014e7f0 > REGS: c029bcd0 TRAP: 0700 Tainted: GW (2.6.26) > MSR: 00021032 CR: 4428 XER: > TASK = c027f7f8[0] 'swapper' THREAD: c029a000 > GPR00: 0001 c029bd80 c027f7f8 0022 cfca1080 c013e298 c02f2cd8 > GPR08: cfca13e0 c029a000 02000100 fe024000 38c35770 0404f000 > GPR16: ffbf c02f002c c0282344 00200200 c0303be8 c0303de8 > GPR24: c0303fe8 c03041e8 c029a034 c029bde8 cfca1080 9032 0022 cfca13e0 > NIP [c003e9c0] free_irq+0x2c/0x18c > LR [c014e5b4] stop_gfar+0x70/0x11c > Call Trace: > [c029bd80] [0102] 0x102 (unreliable) > [c029bda0] [c014e5b4] stop_gfar+0x70/0x11c > [c029bdc0] [c014e820] gfar_timeout+0x30/0x60 > [c029bdd0] [c01a4770] dev_watchdog+0xac/0x160 > [c029bde0] [c0021a18] run_timer_softirq+0x17c/0x220 > [c029be30] [c001cd84] __do_softirq+0x70/0xd0 > [c029be60] [c0008ff8] do_softirq+0x40/0x58 > [c029be70] [c001ca08] irq_exit+0x3c/0x5c > [c029be80] [c0005790] timer_interrupt+0x204/0x234 > [c029bec0] [c00042b4] ret_from_except+0x0/0x14 > [c029bf80] [c000bdcc] cpu_idle+0xdc/0xec > [c029bfa0] [c02057b4] rest_init+0x7c/0x90 > [c029bfc0] [c029d914] start_kernel+0x2b8/0x2cc > [c029bff0] [32c0] 0x32c0 > Instruction dump: > 4e800020 7c0802a6 9421ffe0 bf810010 54290024 90010024 7c7e1b78 7c9c2378 > 8009000c 5400012e 7cd0 54000ffe <0f00> 2b83007f 419d0144 1c030038 > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v1] Add support for getting device platform data to I2C device
On Thu, Dec 18, 2008 at 11:20:03AM -0600, Scott Wood wrote: > Anton Vorontsov wrote: >> On Thu, Dec 18, 2008 at 10:14:11AM +0800, Mingkai Hu wrote: >>> There is no standard way of getting device platform data from >>> dts file to the I2C device when it's probed. This patch adds >>> a function pointer to the of_modalias_table to get such bindings >>> properties into device's platform data. >> >> Unfortunately this approach leads to inability to make the bindings >> modular. > > True, but I think it's fine for now while a better mechanism is worked > out -- especially for things that are mainly used in embedded situations > where modular builds aren't as necessary. Exactly, this matters for non-embedded case. Why would I want totally unneeded I2C bindings built-in into my iBook kernel? ;-) >> And the solution that everybody seem to agree with (SPI driver example): >> http://lkml.org/lkml/2008/10/30/393 > > Hmm, that doesn't seem to allow for any binding mechanism other than > internal and OF Yeah, not without hacks (though, we can do some sort of chained pdata handlers, thus we can allow other bindings mechanisms). But so far we don't have anything other than OF and "board files"/raw bindings (I can't actually imagine any other option). Both approaches have their cons, sure. The difference is: for the $subject approach we'll see the cons immediately, while in my approach the cons are theoretical. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
gianfar tries to free an irq from interrupt context
Hi, I'm having Problems with the gianfar Ethernet. eth1 is working fine, but eth0 is making trouble. It's making trouble in u-boot as well, so it could as well be a hardware problem. First of all eth0 receives some frame errors (frame: in ifconfig), but eth1 doesn't. eth1 performs well under a ping flood, but eth0 produces the following WARN_ON() after some time. I'm using linux-2.6.26 ARCH ppc on a MPC8347 with 2 different 100MB PHYs. Is my Board just triggering this error or responsible for it? Regards Markus [ cut here ] Badness at kernel/irq/manage.c:441 NIP: c003e9c0 LR: c014e5b4 CTR: c014e7f0 REGS: c029bcd0 TRAP: 0700 Tainted: GW (2.6.26) MSR: 00021032 CR: 4428 XER: TASK = c027f7f8[0] 'swapper' THREAD: c029a000 GPR00: 0001 c029bd80 c027f7f8 0022 cfca1080 c013e298 c02f2cd8 GPR08: cfca13e0 c029a000 02000100 fe024000 38c35770 0404f000 GPR16: ffbf c02f002c c0282344 00200200 c0303be8 c0303de8 GPR24: c0303fe8 c03041e8 c029a034 c029bde8 cfca1080 9032 0022 cfca13e0 NIP [c003e9c0] free_irq+0x2c/0x18c LR [c014e5b4] stop_gfar+0x70/0x11c Call Trace: [c029bd80] [0102] 0x102 (unreliable) [c029bda0] [c014e5b4] stop_gfar+0x70/0x11c [c029bdc0] [c014e820] gfar_timeout+0x30/0x60 [c029bdd0] [c01a4770] dev_watchdog+0xac/0x160 [c029bde0] [c0021a18] run_timer_softirq+0x17c/0x220 [c029be30] [c001cd84] __do_softirq+0x70/0xd0 [c029be60] [c0008ff8] do_softirq+0x40/0x58 [c029be70] [c001ca08] irq_exit+0x3c/0x5c [c029be80] [c0005790] timer_interrupt+0x204/0x234 [c029bec0] [c00042b4] ret_from_except+0x0/0x14 [c029bf80] [c000bdcc] cpu_idle+0xdc/0xec [c029bfa0] [c02057b4] rest_init+0x7c/0x90 [c029bfc0] [c029d914] start_kernel+0x2b8/0x2cc [c029bff0] [32c0] 0x32c0 Instruction dump: 4e800020 7c0802a6 9421ffe0 bf810010 54290024 90010024 7c7e1b78 7c9c2378 8009000c 5400012e 7cd0 54000ffe <0f00> 2b83007f 419d0144 1c030038 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v1] Add support for getting device platform data to I2C device
Anton Vorontsov wrote: On Thu, Dec 18, 2008 at 10:14:11AM +0800, Mingkai Hu wrote: There is no standard way of getting device platform data from dts file to the I2C device when it's probed. This patch adds a function pointer to the of_modalias_table to get such bindings properties into device's platform data. Unfortunately this approach leads to inability to make the bindings modular. True, but I think it's fine for now while a better mechanism is worked out -- especially for things that are mainly used in embedded situations where modular builds aren't as necessary. And the solution that everybody seem to agree with (SPI driver example): http://lkml.org/lkml/2008/10/30/393 Hmm, that doesn't seem to allow for any binding mechanism other than internal and OF, and it seems like it could be done more straightforwardly by having the modalias point to the OF wrapper, which then instantiates the core driver. But the above approach has the distinct advantage of having already been implemented. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v1] Add support for getting device platform data to I2C device
On Thu, Dec 18, 2008 at 10:14:11AM +0800, Mingkai Hu wrote: > There is no standard way of getting device platform data from > dts file to the I2C device when it's probed. This patch adds > a function pointer to the of_modalias_table to get such bindings > properties into device's platform data. Unfortunately this approach leads to inability to make the bindings modular. Note that distributions compile kernels with allmodconfig*, so the kernel builds with all modules, but _all_ these bindings will be kernel's built-ins. Given that these bindings are needed for every not-so-trivial I2C (or SPI) driver, the approach doesn't seem to scale good enough. You can find more discussion on this matter in this huge thread: http://lkml.org/lkml/2008/10/16/248 And the solution that everybody seem to agree with (SPI driver example): http://lkml.org/lkml/2008/10/30/393 * Well, this is not quite true, but they're very close to allmodconfig. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] powerpc/83xx: Add USB Host support for MPC8360E-RDK boards
Simply add the usb node to support USB host on the MPC8360E-RDK
boards.
Currently U-Boot doesn't fill the clock-frequency property for
timer nodes, so for now we have to fill it manually.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index decadf3..37b7895 100644
--- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -218,8 +218,23 @@
reg = <0x440 0x40>;
interrupts = <12 13 14 15>;
interrupt-parent = <&qeic>;
- /* filled by u-boot */
- clock-frequency = <0>;
+ clock-frequency = <1>;
+ };
+
+ u...@6c0 {
+ compatible = "fsl,mpc8360-qe-usb",
+"fsl,mpc8323-qe-usb";
+ reg = <0x6c0 0x40 0x8b00 0x100>;
+ interrupts = <11>;
+ interrupt-parent = <&qeic>;
+ fsl,fullspeed-clock = "clk21";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&qe_pio_e 20 0 /* SPEED */
+&qe_pio_e 21 1 /* POWER */>;
};
s...@4c0 {
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] powerpc/83xx: Add USB Host/Gadget support for MPC8360E-MDS boards
- Update the device tree per QE USB bindings;
- Add timer (FSL GTM) node;
- Add gpio-controller node for BCSR13 bank (GPIOs on that bank
are used to control the USB transceiver);
- Set up other BCSR registers;
- Configure the QE Par IO.
The work is loosely based on Li Yang's patch[1], which was used
to support peripheral mode only.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061357.html
The s-o-b line of the original patch preserved here.
Signed-off-by: Li Yang
Signed-off-by: Anton Vorontsov
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 43 -
arch/powerpc/platforms/83xx/mpc836x_mds.c | 75 +
2 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 14534d0..6e34f17 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -69,8 +69,18 @@
};
b...@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "fsl,mpc8360mds-bcsr";
reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: gpio-control...@d {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
};
};
@@ -195,10 +205,21 @@
};
par...@1400 {
+ #address-cells = <1>;
+ #size-cells = <1>;
reg = <0x1400 0x100>;
+ ranges = <0 0x1400 0x100>;
device_type = "par_io";
num-ports = <7>;
+ qe_pio_b: gpio-control...@18 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+"fsl,mpc8323-qe-pario-bank";
+ reg = <0x18 0x18>;
+ gpio-controller;
+ };
+
pio1: ucc_...@01 {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -282,6 +303,15 @@
};
};
+ ti...@440 {
+ compatible = "fsl,mpc8360-qe-gtm",
+"fsl,qe-gtm", "fsl,gtm";
+ reg = <0x440 0x40>;
+ clock-frequency = <13200>;
+ interrupts = <12 13 14 15>;
+ interrupt-parent = <&qeic>;
+ };
+
s...@4c0 {
cell-index = <0>;
compatible = "fsl,spi";
@@ -301,11 +331,20 @@
};
u...@6c0 {
- compatible = "qe_udc";
+ compatible = "fsl,mpc8360-qe-usb",
+"fsl,mpc8323-qe-usb";
reg = <0x6c0 0x40 0x8b00 0x100>;
interrupts = <11>;
interrupt-parent = <&qeic>;
- mode = "slave";
+ fsl,fullspeed-clock = "clk21";
+ fsl,lowspeed-clock = "brg9";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&bcsr135 0 /* SPEED */
+&bcsr134 1>; /* POWER */
};
enet0: u...@2000 {
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index c0a09c3..09e9d6f 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -93,6 +94,16 @@ static void __init mpc836x_mds_setup_arch(void)
for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
par_io_of_config(np);
+#ifdef CONFIG_QE_USB
+ /* Must fixup Par IO before QE GPIO chips are registered. */
+ par_io_config_pin(1, 2, 1, 0, 3, 0); /* USBOE */
+ par_io_config_pin(1, 3, 1, 0, 3, 0); /* USBTP */
+ par_io_config_pin(1, 8, 1, 0, 1, 0); /* USBTN */
+ par_io_config_pin(1, 10, 2, 0, 3, 0); /* USBRXD */
+ par_io_config_pin(1, 9, 2, 1, 3, 0); /* USBRP */
[PATCH 2/4] powerpc: Implement GPIO driver for simple memory-mapped banks
The driver supports very simple GPIO controllers, that is, when a
controller provides just a 'data' register. Such controllers may be
found in various BCSRs (Board's FPGAs used to control board's
switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
So far we support only 1-byte GPIO banks. Support for other widths may
be implemented when/if needed.
p.s.
To avoid "made up" compatible entries (like compatible = "simple-gpio"),
boards must call simple_gpiochip_init() to pass the compatible string.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/platforms/Kconfig| 11 +++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/simple_gpio.c | 155 +
arch/powerpc/sysdev/simple_gpio.h | 12 +++
4 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/simple_gpio.c
create mode 100644 arch/powerpc/sysdev/simple_gpio.h
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 47e956c..47fe2be 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -312,4 +312,15 @@ config MPC8xxx_GPIO
Say Y here if you're going to use hardware that connects to the
MPC831x/834x/837x/8572/8610 GPIOs.
+config SIMPLE_GPIO
+ bool "Support for simple, memory-mapped GPIO controllers"
+ depends on PPC
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here to support simple, memory-mapped GPIO controllers.
+ These are usually BCSRs used to control board's switches, LEDs,
+ chip-selects, Ethernet/USB PHY's power and various other small
+ on-board peripherals.
+
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5afce11..b33b28a 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
+obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
diff --git a/arch/powerpc/sysdev/simple_gpio.c
b/arch/powerpc/sysdev/simple_gpio.c
new file mode 100644
index 000..43c4569
--- /dev/null
+++ b/arch/powerpc/sysdev/simple_gpio.c
@@ -0,0 +1,155 @@
+/*
+ * Simple Memory-Mapped GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "simple_gpio.h"
+
+struct u8_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u8 data;
+};
+
+static struct u8_gpio_chip *to_u8_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct u8_gpio_chip, mm_gc);
+}
+
+static u8 u8_pin2mask(unsigned int pin)
+{
+ return 1 << (8 - 1 - pin);
+}
+
+static int u8_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return in_8(mm_gc->regs) & u8_pin2mask(gpio);
+}
+
+static void u8_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct u8_gpio_chip *u8_gc = to_u8_gpio_chip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&u8_gc->lock, flags);
+
+ if (val)
+ u8_gc->data |= u8_pin2mask(gpio);
+ else
+ u8_gc->data &= ~u8_pin2mask(gpio);
+
+ out_8(mm_gc->regs, u8_gc->data);
+
+ spin_unlock_irqrestore(&u8_gc->lock, flags);
+}
+
+static int u8_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ return 0;
+}
+
+static int u8_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ u8_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+static void u8_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct u8_gpio_chip *u8_gc = to_u8_gpio_chip(mm_gc);
+
+ u8_gc->data = in_8(mm_gc->regs);
+}
+
+static int __init u8_simple_gpiochip_add(struct device_node *np)
+{
+ int ret;
+ struct u8_gpio_chip *u8_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ u8_gc = kzalloc(sizeof(*u8_gc), GFP_KERNEL);
+ if (!u8_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&u8_gc->lock);
+
+ mm_gc = &u8_gc->mm_gc;
+ of_gc = &mm_g
[PATCH 1/4] powerpc: Add device tree bindings for BCSR GPIO banks
The patch adds bindings for BCSR GPIO banks, the bindings are used to
describe particular BCSR registers that act as simple GPIO controllers.
These GPIO banks might control power switches, SPI chip-selects, LEDs,
etc.
While at it, also fix "length" spelling error in the PIXIS FPGA
bindings.
Signed-off-by: Anton Vorontsov
---
Documentation/powerpc/dts-bindings/fsl/board.txt | 32 +-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt
b/Documentation/powerpc/dts-bindings/fsl/board.txt
index 81a917e..6c974d2 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt
@@ -18,7 +18,7 @@ This is the memory-mapped registers for on board FPGA.
Required properities:
- compatible : should be "fsl,fpga-pixis".
-- reg : should contain the address and the lenght of the FPPGA register
+- reg : should contain the address and the length of the FPPGA register
set.
Example (MPC8610HPCD):
@@ -27,3 +27,33 @@ Example (MPC8610HPCD):
compatible = "fsl,fpga-pixis";
reg = <0xe800 32>;
};
+
+* Freescale BCSR GPIO banks
+
+Some BCSR registers act as simple GPIO controllers, each such
+register can be represented by the gpio-controller node.
+
+Required properities:
+- compatible : Should be "fsl,-bcsr-gpio".
+- reg : Should contain the address and the length of the GPIO bank
+ register.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional paramters (currently unused).
+- gpio-controller : Marks the port as GPIO controller.
+
+Example:
+
+ b...@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8360mds-bcsr";
+ reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: gpio-control...@d {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
+ };
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] Few patches for galak/powerpc.git next
Kumar, Timur, Much thanks for the reviews and comments, here is an updated patch set. Changes: - BCSR GPIO bindings were split into a separate patch. - simple_gpiochip_init() return value changed to void (the function prints errors by itself, and we don't check its return value anyway). p.s. >> +- reg : Should contain the address and the lenght of the GPIO bank >> + register; > > spelling - length > semicolon at add of register can be dropped. Umm.. the semicolon denotes the end of the list item. Anyhow, I see that periods are used more widely, so I replaced semicolons with periods. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote: > > Hi, > > I'm experiencing a long (around 20 sec) delay from the moment > u-boot-1.3.4 passes control to linux and until the first kernel message > appears on console. I saw somewhat similar behaviour on 83xx target, the cause was that my .config file contained bogus UDBG_RTAS_CONSOLE=y symbol (or was it PPC_EARLY_DEBUG_RTAS_PANEL=y? Or HVC_UDBG=y? I don't quite remember). Obviously, on 83xx we don't have RTAS or HVC stuff, but kernel didn't oops or hang completely, it was busy with executing various delays in those drivers and then just continued to load. OTOH, it might be that the kernel just calibrates the delay loop for too long, and you actually don't have any early messages support enabled so you don't see what the kernel does at the moment. You could provide dmesg and .config file to make things clearer, so at least somebody with 460EX boards could try to reproduce the result. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull bjdoo ks' i2c-fixes
Ben Dooks schrieb: > Ok, but this isn't really a fix, so I'll look at putting it into my > i2c-next tree, not i2c-fixes. That's OK for me. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull bjdoo ks' i2c-fixes
On Wed, Dec 17, 2008 at 12:55:06PM +0100, Jochen Friedrich wrote: > Hi Ben, > > > Mike Ditto (1): > > i2c-cpm: Detect and report NAK right away instead of timing out > > Could you also have a look at http://patchwork.ozlabs.org/patch/7452/ ? > (Discussion at http://patchwork.ozlabs.org/patch// ) > > IIRC, Kumar prefers to push this via your tree. Ok, but this isn't really a fix, so I'll look at putting it into my i2c-next tree, not i2c-fixes. -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Long boot delay on 460EX with 2.6.28-rc8
Hi, I'm experiencing a long (around 20 sec) delay from the moment u-boot-1.3.4 passes control to linux and until the first kernel message appears on console. This happens on custom board, I don't have access to Canyonlands to test how it behaves. I did not modify anything in kernel code to make it boot on custom board, just removed PCIX and PCIE0 nodes from DTS. Has anyone experienced similar behavior with 460EX ? Any hints what can cause this ? Thanks a lot. Felix. -- View this message in context: http://www.nabble.com/Long-boot-delay-on-460EX-with-2.6.28-rc8-tp21070179p21070179.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FHCI driver adaptation for CPM2
Hi Remi, On Wednesday 17 December 2008 21:27:49 Remi Lefevre wrote: > >> Also 40% seems quite a lot, even at 1000Hz interruptions, an idea how > >> much does the CRC computation contribute in this CPU hogging ? > > > > I haven't measured that, but probably not much. The biggest CPU time > > eater isn't the SOF generation interrupt but the USB packet handling > > code. The CPM2 USB host controller is really too low-level to be usable > > (except maybe for specific applications). Comparing the OHCI/UHCI/EHCI > > and FHCI controllers is akin to bit like comparing a full 16550 UART > > with a software bit-bang implementation. You can get around with it, it > > might work for your specific application, but you shouldn't try a full > > speed 115200bds communication while computing a CPU-hungry physical > > simulation. > > That's what I was afraid of. I now understand clearly why you didn't expect > that much better performance with CPM3 in a past message > (http://ozlabs.org/pipermail/linuxppc-embedded/2008-May/030508.html). > Still, as you said, it can have some use for specific applications. > > Do you remember the throughput you were able to reach with this cpu > overhead ? I'm sorry I don't. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On Thursday 18 December 2008, Grant Erickson wrote:
> Added additional information for type and compatibility strings and
> interrupt information to the SDRAM0 memory-controller device tree
> nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
> with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
>
> Signed-off-by: Grant Erickson
> ---
> As support in the associated EDAC adapter driver is added over time,
> similar changes will/should be made to the DTS files for boards
> leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
> including the 440SP, 440SPe, 460EX, 460GT and 460SX.
>
> Patch v2, based on review from David Gibson, removes the 'device_type'
> field because it is only used for legacy OpenFirmware method
> interfaces and no such compatibility is warranted here. In addition,
> removed address- and size-cells as this node has no children.
>
> arch/powerpc/boot/dts/haleakala.dts |8 +-
> arch/powerpc/boot/dts/kilauea.dts |8 +-
> arch/powerpc/boot/dts/makalu.dts|8 +-
> 3 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/haleakala.dts
> b/arch/powerpc/boot/dts/haleakala.dts index 513bc43..64880ab 100644
> --- a/arch/powerpc/boot/dts/haleakala.dts
> +++ b/arch/powerpc/boot/dts/haleakala.dts
> @@ -89,8 +89,14 @@
> clock-frequency = <0>; /* Filled in by U-Boot */
>
> SDRAM0: memory-controller {
> - compatible = "ibm,sdram-405exr";
> + compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
> dcr-reg = <0x010 0x002>;
> + #interrupt-cells = <1>;
> + interrupt-parent = <&SDRAM0>;
> + interrupts = <0x0 0x1>;
> + interrupt-map = + /* ECCSEC Error */ 0x1 &UIC2 0x6 0x4>;
> + interrupt-map-mask = <0x>;
When all interrupts are mapped the same parent, this should do as well:
interrupt-parent = <&UIC2>;
interrupts = <0x5 0x4 /* ECCDED Error */
0x6 0x4>; /* ECCSEC Error */
Other than this:
Acked-by: Stefan Roese
Thanks.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
