[PATCH] powerpc: rtas_flash cannot be a module
When trying to flash a machine via the update_flash command, I received the following error: Restarting system. FLASH: kernel bug...flash list header addr above 4GB The code in question has a comment that the flash list should be in the kernel data and therefore under 4GB: /* NOTE: the first block list is a global var with no data * blocks in the kernel data segment. We do this because * we want to ensure this block_list addr is under 4GB. */ Unfortunately the Kconfig option is marked tristate which means the variable may not be in the kernel data and could be above 4GB. Change RTAS_FLASH to a bool. If we are worried about kernel footprint we could move the problem variables out of the module and export them. Signed-off-by: Anton Blanchard an...@samba.org --- Index: linux-2.6/arch/powerpc/platforms/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/Kconfig 2010-06-09 15:44:53.635955260 +1000 +++ linux-2.6/arch/powerpc/platforms/Kconfig2010-06-09 15:45:00.503453428 +1000 @@ -97,7 +97,7 @@ config RTAS_PROC default y config RTAS_FLASH - tristate Firmware flash interface + bool Firmware flash interface depends on PPC64 RTAS_PROC config MMIO_NVRAM Index: linux-2.6/arch/powerpc/configs/ppc64_defconfig === --- linux-2.6.orig/arch/powerpc/configs/ppc64_defconfig 2010-06-09 15:46:25.394704486 +1000 +++ linux-2.6/arch/powerpc/configs/ppc64_defconfig 2010-06-09 15:46:37.083454943 +1000 @@ -264,7 +264,7 @@ CONFIG_U3_DART=y CONFIG_PPC_RTAS=y CONFIG_RTAS_ERROR_LOGGING=y CONFIG_RTAS_PROC=y -CONFIG_RTAS_FLASH=m +CONFIG_RTAS_FLASH=y CONFIG_PPC_PMI=m CONFIG_MMIO_NVRAM=y CONFIG_MPIC_U3_HT_IRQS=y Index: linux-2.6/arch/powerpc/configs/pseries_defconfig === --- linux-2.6.orig/arch/powerpc/configs/pseries_defconfig 2010-06-09 15:46:25.364703092 +1000 +++ linux-2.6/arch/powerpc/configs/pseries_defconfig2010-06-09 15:46:31.723454300 +1000 @@ -213,7 +213,7 @@ CONFIG_PPC_I8259=y CONFIG_PPC_RTAS=y CONFIG_RTAS_ERROR_LOGGING=y CONFIG_RTAS_PROC=y -CONFIG_RTAS_FLASH=m +CONFIG_RTAS_FLASH=y # CONFIG_MMIO_NVRAM is not set CONFIG_IBMVIO=y CONFIG_IBMEBUS=y ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc5200 ac97 gpio reset
Dear Jon Smirl, In message aanlktimis90kr5uqhdbq02osd94dn08soitm51ylr...@mail.gmail.com you wrote: Would making a change in uboot be a better solution? Eric, can you verify if changing uboot also fixes the problem? To me it seems better if the driver itself does what needs to be done instead of relying on specific settings that may or may not be done in U-Boot. Keep in mind that drivers may be loaded as modules, and that we even see cases where the same port serves multiple purposes by loading different driver modules (yes, this is not exactly a clever idea, but hardware designers come up with such solutions). 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 The typical page layout program is nothing more than an electronic light table for cutting and pasting documents. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/12] treewide: Remove unnecessary kmalloc casts
On Mon Jun 07 2010 at around 23:53:18 EST, Joe Perches wrote: Trivial cleanups arch/cris: Remove unnecessary kmalloc casts arch/powerpc: Remove unnecessary kmalloc casts arch/x86/kernel/tlb_uv.c: Remove unnecessary kmalloc casts drivers/gpu/drm: Remove unnecessary kmalloc casts drivers/isdn/capi/capidrv.c: Remove unnecessary kmalloc casts drivers/media: Remove unnecesary kmalloc casts drivers/message/i2o/i20_config.c: Remove unnecessary kmalloc casts drivers/parisc/iosapic.c: Remove unnecessary kzalloc cast drivers/s390: Remove unnecessary kmalloc casts drivers/serial/icom.c: Remove unnecessary kmalloc casts drivers/usb/storage/isd200.c: Remove unnecessary kmalloc casts fs/ufs/util.c: Remove unnecessary kmalloc casts Joe, Thanks for doing cleanups. However, in this case you are removing casts that, while not necessary for C, are indeed there for a reason. Specifically, they are of the form type *p; code p = (type *)kmalloc(sizeof(type), ...); For example, from the powerpc patch: goto out; } - tmp_part = (struct nvram_partition *) - kmalloc(sizeof(struct nvram_partition), GFP_KERNEL); + tmp_part = kmalloc(sizeof(struct nvram_partition), GFP_KERNEL); err = -ENOMEM; The reason they casts are present is to guard against someone changing the type of p at the top of the function and not changing the type at the kmalloc. This was discussed some years ago, possibly around the time kcalloc got its underflow detection. Should we create a kmalloc wrapper that enforces this type saftey? While we have added static analysis tools that can check these things, and we have slab redzoning options, they tend to be run in batch by someone else or in response to debugging a problem. There may have been discussion of doing the above vs p = kmalloc(sizeof(*p), ...); I don't remember if it was programmer preference or issues when p is an array type. I am not subscribed so I don't have the full list that you sent these to, and I know some maintainers have already taken some of the series the last time you posted; could you please augment the CC list. thanks, milton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/12] treewide: Remove unnecessary kmalloc casts
On Wed, 2010-06-09 at 02:20 -0500, Milton Miller wrote: On Mon Jun 07 2010 at around 23:53:18 EST, Joe Perches wrote: Trivial cleanups The reason they casts are present is to guard against someone changing the type of p at the top of the function and not changing the type at the kmalloc. That'd be true for most all of the kernel mallocs. I know some maintainers have already taken some of the series the last time you posted; could you please augment the CC list. I did not send to trivial any of kmalloc cast removal patches that were acked. The patches in this series were not acked, so I think no CC list needs augmentation. Original: http://lkml.org/lkml/2010/5/31/471 Newest: http://lkml.org/lkml/2010/6/7/428 cheers, Joe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: enabled asymmetric SMT scheduling on POWER7
On Tue, 2010-06-08 at 14:57 +1000, Michael Neuling wrote:
The POWER7 core has dynamic SMT mode switching which is controlled by
the hypervisor. There are 3 SMT modes:
SMT1 uses thread 0
SMT2 uses threads 0 1
SMT4 uses threads 0, 1, 2 3
When in any particular SMT mode, all threads have the same performance
as each other (ie. at any moment in time, all threads perform the same).
The SMT mode switching works such that when linux has threads 2 3 idle
and 0 1 active, it will cede (H_CEDE hypercall) threads 2 and 3 in the
idle loop and the hypervisor will automatically switch to SMT2 for that
core (independent of other cores). The opposite is not true, so if
threads 0 1 are idle and 2 3 are active, we will stay in SMT4 mode.
Similarly if thread 0 is active and threads 1, 2 3 are idle, we'll go
into SMT1 mode.
If we can get the core into a lower SMT mode (SMT1 is best), the threads
will perform better (since they share less core resources). Hence when
we have idle threads, we want them to be the higher ones.
This adds a feature bit for asymmetric packing to powerpc and then
enables it on POWER7.
Signed-off-by: Michael Neuling mi...@neuling.org
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/cputable.h |3 ++-
arch/powerpc/kernel/process.c |9 +
2 files changed, 11 insertions(+), 1 deletion(-)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAO LONG_ASM_CONST(0x0020)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080)
+#define CPU_FTR_ASYM_SMT LONG_ASM_CONST(0x0100)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT)
#define CPU_FTRS_CELL(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
Index: linux-2.6-ozlabs/arch/powerpc/kernel/process.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/process.c
@@ -1265,3 +1265,12 @@ unsigned long randomize_et_dyn(unsigned
return ret;
}
+
+int arch_sd_sibiling_asym_packing(void)
+{
+ if (cpu_has_feature(CPU_FTR_ASYM_SMT)){
+ printk_once(KERN_INFO Enabling Asymmetric SMT scheduling\n);
+ return SD_ASYM_PACKING;
+ }
+ return 0;
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/5] Removing dead code
Hi all! As part of the VAMOS[0] research project at the University of Erlangen we are looking at multiple integrity errors in linux' configuration system. I've been running a check on the arch/powerpc sourcetree for config Items not defined in Kconfig and found5 such chases. Sourcecode blocks depending on these Items are not reachable from a vanilla kernel -- dead code. I've seen such dead blocks made on purpose e.g. while integrating new features into the kernel but generally they're just useless. Each of the patches in this patchset removes on such dead config Item, I'd be glad if you consider applying them. I've been doing deeper analysis of such issues before and can do so again but I'm not so sure they were fastly usefull. However I've done a testbuild on ppc with allmodconfig so it should at least build. Please keep me informed of this patch getting confirmed / merged so we can keep track of it. Regards Christoph Egger [0] http://vamos1.informatik.uni-erlangen.de/ Christoph Egger (5): Removing dead BOOK3E_MMU_TLB_STATS Removing dead CONFIG_HIGHPTE Removing dead CONFIG_SMP_750 Removing dead CONFIG_SERIAL_TEXT_DEBUG Removing dead CONFIG_PPC47x arch/powerpc/include/asm/exception-64e.h | 38 -- arch/powerpc/kernel/head_40x.S | 19 --- arch/powerpc/mm/44x_mmu.c|4 --- arch/powerpc/mm/pgtable_32.c |4 --- arch/powerpc/mm/tlb_hash32.c |4 --- arch/powerpc/mm/tlb_low_64e.S|9 --- 6 files changed, 0 insertions(+), 78 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/12] treewide: Remove unnecessary kmalloc casts
Hi Milton, On Wed, Jun 9, 2010 at 10:20 AM, Milton Miller milt...@bga.com wrote: However, in this case you are removing casts that, while not necessary for C, are indeed there for a reason. Specifically, they are of the form type *p; code p = (type *)kmalloc(sizeof(type), ...); For example, from the powerpc patch: goto out; } - tmp_part = (struct nvram_partition *) - kmalloc(sizeof(struct nvram_partition), GFP_KERNEL); + tmp_part = kmalloc(sizeof(struct nvram_partition), GFP_KERNEL); err = -ENOMEM; The reason they casts are present is to guard against someone changing the type of p at the top of the function and not changing the type at the kmalloc. If you're worried about that... [snip] There may have been discussion of doing the above vs p = kmalloc(sizeof(*p), ...); ...it's better to use this form. There's actually a mention of this in Chapter 14: Allocating memory of Documentation/CodingStyle. The guard is not really a guard as someone can still change the sizeof part to something else and the cast from void * will silently ignore it. Pekka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/5] Removing dead CONFIG_SERIAL_TEXT_DEBUG
CONFIG_SERIAL_TEXT_DEBUG doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger sicce...@cs.fau.de --- arch/powerpc/kernel/head_40x.S | 19 --- 1 files changed, 0 insertions(+), 19 deletions(-) diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S index a90625f..1a10e4d 100644 --- a/arch/powerpc/kernel/head_40x.S +++ b/arch/powerpc/kernel/head_40x.S @@ -939,25 +939,6 @@ initial_mmu: tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ -#if defined(CONFIG_SERIAL_TEXT_DEBUG) defined(SERIAL_DEBUG_IO_BASE) - - /* Load a TLB entry for the UART, so that ppc4xx_progress() can use -* the UARTs nice and early. We use a 4k real==virtual mapping. */ - - lis r3,serial_debug_io_b...@h - ori r3,r3,serial_debug_io_b...@l - mr r4,r3 - clrrwi r4,r4,12 - ori r4,r4,(TLB_WR|TLB_I|TLB_M|TLB_G) - - clrrwi r3,r3,12 - ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_4K)) - - li r0,0/* TLB slot 0 */ - tlbwe r4,r0,TLB_DATA - tlbwe r3,r0,TLB_TAG -#endif /* CONFIG_SERIAL_DEBUG_TEXT SERIAL_DEBUG_IO_BASE */ - isync /* Establish the exception vector base -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/5] Removing dead CONFIG_PPC47x
CONFIG_PPC47x doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger sicce...@cs.fau.de --- arch/powerpc/mm/44x_mmu.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c index d8c6efb..f70da7e 100644 --- a/arch/powerpc/mm/44x_mmu.c +++ b/arch/powerpc/mm/44x_mmu.c @@ -76,11 +76,7 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys) tlbwe %1,%3,%5\n tlbwe %0,%3,%6\n : -#ifdef CONFIG_PPC47x - : r (PPC47x_TLB2_S_RWX), -#else : r (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G), -#endif r (phys), r (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M), r (entry), -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/5] Removing dead CONFIG_HIGHPTE
CONFIG_HIGHPTE doesn't exist in Kconfig, therefore removing all
references for it from the source code.
Signed-off-by: Christoph Egger sicce...@cs.fau.de
---
arch/powerpc/mm/pgtable_32.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 9fc02dc..34347b2 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -115,11 +115,7 @@ pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned
long address)
{
struct page *ptepage;
-#ifdef CONFIG_HIGHPTE
- gfp_t flags = GFP_KERNEL | __GFP_HIGHMEM | __GFP_REPEAT | __GFP_ZERO;
-#else
gfp_t flags = GFP_KERNEL | __GFP_REPEAT | __GFP_ZERO;
-#endif
ptepage = alloc_pages(flags, 0);
if (!ptepage)
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/5] Removing dead BOOK3E_MMU_TLB_STATS
BOOK3E_MMU_TLB_STATS doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger sicce...@cs.fau.de --- arch/powerpc/include/asm/exception-64e.h | 38 -- arch/powerpc/mm/tlb_low_64e.S|9 --- 2 files changed, 0 insertions(+), 47 deletions(-) diff --git a/arch/powerpc/include/asm/exception-64e.h b/arch/powerpc/include/asm/exception-64e.h index 6d53f31..db74814 100644 --- a/arch/powerpc/include/asm/exception-64e.h +++ b/arch/powerpc/include/asm/exception-64e.h @@ -65,14 +65,7 @@ #define EX_TLB_MMUCR0 (12 * 8) /* Level 0 */ #define EX_TLB_MAS1(12 * 8) /* Level 0 */ #define EX_TLB_MAS2(13 * 8) /* Level 0 */ -#ifdef CONFIG_BOOK3E_MMU_TLB_STATS -#define EX_TLB_R8 (14 * 8) -#define EX_TLB_R9 (15 * 8) -#define EX_TLB_LR (16 * 8) -#define EX_TLB_SIZE(17 * 8) -#else #define EX_TLB_SIZE(14 * 8) -#endif #defineSTART_EXCEPTION(label) \ .globl exc_##label##_book3e;\ @@ -157,36 +150,6 @@ exc_##label##_book3e: addir11,r13,PACA_EXTLB; \ TLB_MISS_RESTORE(r11) -#ifdef CONFIG_BOOK3E_MMU_TLB_STATS -#define TLB_MISS_PROLOG_STATS \ - mflrr10;\ - std r8,EX_TLB_R8(r12); \ - std r9,EX_TLB_R9(r12); \ - std r10,EX_TLB_LR(r12); -#define TLB_MISS_RESTORE_STATS \ - ld r16,EX_TLB_LR(r12); \ - ld r9,EX_TLB_R9(r12); \ - ld r8,EX_TLB_R8(r12); \ - mtlrr16; -#define TLB_MISS_STATS_D(name) \ - addir9,r13,MMSTAT_DSTATS+name; \ - bl .tlb_stat_inc; -#define TLB_MISS_STATS_I(name) \ - addir9,r13,MMSTAT_ISTATS+name; \ - bl .tlb_stat_inc; -#define TLB_MISS_STATS_X(name) \ - ld r8,PACA_EXTLB+EX_TLB_ESR(r13); \ - cmpdi cr2,r8,-1; \ - beq cr2,61f;\ - addir9,r13,MMSTAT_DSTATS+name; \ - b 62f;\ -61:addir9,r13,MMSTAT_ISTATS+name; \ -62:bl .tlb_stat_inc; -#define TLB_MISS_STATS_SAVE_INFO \ - std r14,EX_TLB_ESR(r12);/* save ESR */ \ - - -#else #define TLB_MISS_PROLOG_STATS #define TLB_MISS_RESTORE_STATS #define TLB_MISS_STATS_D(name) @@ -194,7 +157,6 @@ exc_##label##_book3e: #define TLB_MISS_STATS_X(name) #define TLB_MISS_STATS_Y(name) #define TLB_MISS_STATS_SAVE_INFO -#endif #define SET_IVOR(vector_number, vector_offset) \ li r3,vector_off...@l; \ diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S index 8b04c54..4d7d059 100644 --- a/arch/powerpc/mm/tlb_low_64e.S +++ b/arch/powerpc/mm/tlb_low_64e.S @@ -758,12 +758,3 @@ tlb_load_linear_fault: 1: TLB_MISS_EPILOG_ERROR_SPECIAL b exc_instruction_storage_book3e - -#ifdef CONFIG_BOOK3E_MMU_TLB_STATS -.tlb_stat_inc: -1: ldarx r8,0,r9 - addir8,r8,1 - stdcx. r8,0,r9 - bne-1b - blr -#endif -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] Removing dead CONFIG_SMP_750
CONFIG_SMP_750 doesn't exist in Kconfig, therefore removing all
references for it from the source code.
Signed-off-by: Christoph Egger sicce...@cs.fau.de
---
arch/powerpc/mm/tlb_hash32.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/tlb_hash32.c b/arch/powerpc/mm/tlb_hash32.c
index 8aaa8b7..925fecb 100644
--- a/arch/powerpc/mm/tlb_hash32.c
+++ b/arch/powerpc/mm/tlb_hash32.c
@@ -94,11 +94,7 @@ void tlb_flush(struct mmu_gather *tlb)
* the cache operations on the bus. Hence we need to use an IPI
* to get the other CPU(s) to invalidate their TLBs.
*/
-#ifdef CONFIG_SMP_750
-#define FINISH_FLUSH smp_send_tlb_invalidate(0)
-#else
#define FINISH_FLUSH do { } while (0)
-#endif
static void flush_range(struct mm_struct *mm, unsigned long start,
unsigned long end)
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 0/5] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXIII
Hi All, Please find a new version of the patchset that implement hardware breakpoint interfaces for the PowerPC BookIII S processor. The changes are few and as described below. Changelog - ver XXIII (Version XXII: 20100528063924.ga8...@in.ibm.com) - Detection of extraneous breakpoint exceptions is now done using a boolean flag in 'struct arch_hw_breakpoint'. - A dangling put_cpu() (remnant from previous patch versions) in arch_unregister_hw_breakpoint() is now removed. Kindly let me know your comments. Thanks, K.Prasad Changelog - ver XXII (Version XXI: linuxppc-dev ref:20100525091314.ga29...@in.ibm.com) - Extraneous breakpoint exceptions are now properly handled; causative instruction will be single-stepped and debug register values restored. - Restoration of breakpoints during signal handling through thread_change_pc() had defects which are now fixed. - Breakpoints are flushed through flush_ptrace_hw_breakpoint() call in both flush_thread() and prepare_to_copy() functions. 'ptrace_bps[]' and 'last_hit_ubp' members are now promptly cleaned-up. - Single-step exception is now conditionally emulated upon hitting alignment_exception. - Rebased to commit 31f46717997a83bdf6db0dd04810c0a329eb3148 of linux-2.6 tree. Changelog - ver XXI (Version XX: linuxppc-dev ref:20100524103136.ga8...@in.ibm.com) - Decision to emulate an instruction is now based on whether the causative instruction is in user_mode() or not. - Breakpoints don't have to be cleared during sigreturn. A 'double-hit' on hw_breakpoint_handler() is harmless for non-ptrace instructions. - Minor changes to aid code brevity. Changelog - ver XX (Version XIX: linuxppc-dev ref: 20100524040137.ga20...@in.ibm.com) - Non task-bound breakpoints will only be emulated. Breakpoint will be unregistered with a warning if emulation fails. Changelog - ver XIX (Version XVIII: linuxppc-dev ref: 20100512033055.ga6...@in.ibm.com) - Increased coverage of breakpoints during concurrent alignment_exception and signal handling (which previously had 'blind-spots'). - Support for kernel-thread breakpoints and kernel-space breakpoints inside the context of a user-space process. - Patches re-based to commit f4b87dee923342505e1ddba8d34ce9de33e75050, thereby necessitating minor changes to arch_validate_hwbkpt_settings(). Changelog - ver XVIII (Version XVII: linuxppc-dev ref: 20100414034340.ga6...@in.ibm.com) - Slight code restructuring for brevity and coding-style corrections. - emulate_single_step() now notifies DIE_SSTEP to registered handlers; causes single_step_dabr_instruction() to be invoked after alignment_exception. - hw-breakpoint restoration variables are cleaned-up before unregistration through arch_unregister_hw_breakpoint(). - SIGTRAP is no longer generated for non-ptrace user-space breakpoints. Changelog - ver XVII (Version XVI: linuxppc-dev ref: 20100330095809.ga14...@in.ibm.com) - CONFIG_HAVE_HW_BREAKPOINT is now used to define the scope of the new code (in lieu of CONFIG_PPC_BOOK3S_64). - CONFIG_HAVE_HW_BREAKPOINT is now dependant upon CONFIG_PERF_EVENTS and CONFIG_PPC_BOOK3S_64 (to overcome build failures under certain configs). - Included a target in arch/powerpc/lib/Makefile to build sstep.o when HAVE_HW_BREAKPOINT. - Added a dummy definition for hw_breakpoint_disable() when !HAVE_HW_BREAKPOINT. - Tested builds under defconfigs for ppc64, cell and g5 (found no patch induced failures). Changelog - ver XVI (Version XV: linuxppc-dev ref: 20100323140639.ga21...@in.ibm.com) - Used a new config option CONFIG_PPC_BOOK3S_64 (in lieu of CONFIG_PPC64/CPU_FTR_HAS_DABR) to limit the scope of the new code. - Disabled breakpoints before kexec of the machine using hw_breakpoint_disable(). - Minor optimisation in exception-64s.S to check for data breakpoint exceptions in DSISR finally (after check for other causes) + changes in code comments and representation of DSISR_DABRMATCH constant. - Rebased to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6. Changelog - ver XV (Version XIV: linuxppc-dev ref: 20100308181232.ga3...@in.ibm.com) - Additional patch to disable interrupts during data breakpoint exception handling. - Moved HBP_NUM definition to cputable.h under a new CPU_FTR definition (CPU_FTR_HAS_DABR). - Filtering of extraneous exceptions (due to accesses outside symbol length) is by-passed for ptrace requests. - Removed flush_ptrace_hw_breakpoint() from __switch_to() due to incorrect coding placement. - Changes to code comments as per community reviews for previous version. - Minor coding-style changes in hw_breakpoint.c as per review comments. - Re-based to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6 Changelog - ver XIV (Version XIII: linuxppc-dev ref:
[Patch 1/5] Allow arch-specific cleanup before breakpoint unregistration
Certain architectures (such as PowerPC Book III S) have a need to cleanup
data-structures before the breakpoint is unregistered. This patch introduces
an arch-specific hook in release_bp_slot() along with a weak definition in
the form of a stub funciton.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
Acked-by: Frederic Weisbecker fweis...@gmail.com
---
kernel/hw_breakpoint.c | 12
1 file changed, 12 insertions(+)
Index: linux-2.6.ppc64_test/kernel/hw_breakpoint.c
===
--- linux-2.6.ppc64_test.orig/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/kernel/hw_breakpoint.c
@@ -242,6 +242,17 @@ toggle_bp_slot(struct perf_event *bp, bo
}
/*
+ * Function to perform processor-specific cleanup during unregistration
+ */
+__weak void arch_unregister_hw_breakpoint(struct perf_event *bp)
+{
+ /*
+* A weak stub function here for those archs that don't define
+* it inside arch/.../kernel/hw_breakpoint.c
+*/
+}
+
+/*
* Contraints to check before allowing this new breakpoint counter:
*
* == Non-pinned counter == (Considered as pinned for now)
@@ -339,6 +350,7 @@ void release_bp_slot(struct perf_event *
{
mutex_lock(nr_bp_mutex);
+ arch_unregister_hw_breakpoint(bp);
__release_bp_slot(bp);
mutex_unlock(nr_bp_mutex);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 2/5] PPC64-HWBKPT: Implement hw-breakpoints for PowerPC BookIII S
Implement perf-events based hw-breakpoint interfaces for PowerPC Book III S
processors. These interfaces help arbitrate requests from various users and
schedules them as appropriate.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/cputable.h |4
arch/powerpc/include/asm/hw_breakpoint.h | 73 +++
arch/powerpc/include/asm/processor.h |8
arch/powerpc/kernel/Makefile |1
arch/powerpc/kernel/hw_breakpoint.c | 320 +++
arch/powerpc/kernel/machine_kexec_64.c |3
arch/powerpc/kernel/process.c| 14 +
arch/powerpc/kernel/ptrace.c | 64 ++
arch/powerpc/lib/Makefile|1
10 files changed, 489 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,73 @@
+/*
+ * PowerPC BookIII S hardware breakpoint definitions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2010, IBM Corporation.
+ * Author: K.Prasad pra...@linux.vnet.ibm.com
+ *
+ */
+
+#ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
+#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target data symbol */
+ int type;
+ unsigned long address;
+};
+
+#include linux/kdebug.h
+#include asm/reg.h
+#include asm/system.h
+
+static inline int hw_breakpoint_slots(int type)
+{
+ return HBP_NUM;
+}
+struct perf_event;
+struct pmu;
+struct perf_sample_data;
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
+
+extern int arch_bp_generic_fields(int type, int *gen_bp_type);
+extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk);
+
+extern struct pmu perf_ops_bp;
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
+static inline void hw_breakpoint_disable(void) { }
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* __KERNEL__ */
+#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,320 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers. Derived from
+ * arch/x86/kernel/hw_breakpoint.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2010 IBM Corporation
+ * Author: K.Prasad pra...@linux.vnet.ibm.com
+ *
+ */
+
+#include linux/hw_breakpoint.h
+#include linux/notifier.h
+#include linux/kprobes.h
+#include linux/percpu.h
+#include linux/kernel.h
+#include linux/module.h
[Patch 3/5] PPC64-HWBKPT: Handle concurrent alignment interrupts
An alignment interrupt may intervene between a DSI/hw-breakpoint exception
and the single-step exception. Enable the alignment interrupt (through
modifications to emulate_single_step()) to notify the single-step exception
handler for proper restoration of hw-breakpoints.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/kernel/traps.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/traps.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
@@ -602,7 +602,7 @@ void RunModeException(struct pt_regs *re
void __kprobes single_step_exception(struct pt_regs *regs)
{
- regs-msr = ~(MSR_SE | MSR_BE); /* Turn off 'trace' bits */
+ clear_single_step(regs);
if (notify_die(DIE_SSTEP, single_step, regs, 5,
5, SIGTRAP) == NOTIFY_STOP)
@@ -621,10 +621,8 @@ void __kprobes single_step_exception(str
*/
static void emulate_single_step(struct pt_regs *regs)
{
- if (single_stepping(regs)) {
- clear_single_step(regs);
- _exception(SIGTRAP, regs, TRAP_TRACE, 0);
- }
+ if (single_stepping(regs))
+ single_step_exception(regs);
}
static inline int __parse_fpscr(unsigned long fpscr)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 4/5] PPC64-HWBKPT: Enable hw-breakpoints while handling intervening signals
A signal delivered between a hw_breakpoint_handler() and the
single_step_dabr_instruction() will not have the breakpoint active during
signal handling (since breakpoint will not be restored through single-stepping
due to absence of MSR_SE bit on the signal frame). Enable breakpoints before
signal delivery.
Restore hw-breakpoints if the user-context is altered in the signal handler.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/hw_breakpoint.h |3 +++
arch/powerpc/kernel/hw_breakpoint.c | 18 ++
arch/powerpc/kernel/signal.c |3 +++
3 files changed, 24 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/hw_breakpoint.h
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -65,9 +65,12 @@ static inline void hw_breakpoint_disable
{
set_dabr(0);
}
+extern void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs);
#else /* CONFIG_HAVE_HW_BREAKPOINT */
static inline void hw_breakpoint_disable(void) { }
+static inline void thread_change_pc(struct task_struct *tsk,
+ struct pt_regs *regs) { }
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* __KERNEL__ */
#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -174,6 +174,24 @@ int arch_validate_hwbkpt_settings(struct
}
/*
+ * Restores the breakpoint on the debug registers.
+ * Invoke this function if it is known that the execution context is about to
+ * change to cause loss of MSR_SE settings.
+ */
+void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs)
+{
+ struct arch_hw_breakpoint *info;
+
+ if (likely(!tsk-thread.last_hit_ubp))
+ return;
+
+ info = counter_arch_bp(tsk-thread.last_hit_ubp);
+ regs-msr = ~MSR_SE;
+ set_dabr(info-address | info-type | DABR_TRANSLATION);
+ tsk-thread.last_hit_ubp = NULL;
+}
+
+/*
* Handle debug exception notifications.
*/
int __kprobes hw_breakpoint_handler(struct die_args *args)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/signal.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/signal.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/signal.c
@@ -11,6 +11,7 @@
#include linux/tracehook.h
#include linux/signal.h
+#include asm/hw_breakpoint.h
#include asm/uaccess.h
#include asm/unistd.h
@@ -149,6 +150,8 @@ static int do_signal_pending(sigset_t *o
if (current-thread.dabr)
set_dabr(current-thread.dabr);
#endif
+ /* Re-enable the breakpoints for the signal stack */
+ thread_change_pc(current, regs);
if (is32) {
if (ka.sa.sa_flags SA_SIGINFO)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 5/5] PPC64-HWBKPT: Discard extraneous interrupt due to accesses outside symbol length
Many a times, the requested breakpoint length can be less than the fixed
breakpoint length i.e. 8 bytes supported by PowerPC BookIII S. This could lead
to extraneous interrupts resulting in false breakpoint notifications. The patch
below detects and discards such interrupts for non-ptrace requests (we don't
want to change ptrace behaviour for fear of breaking compatability).
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/hw_breakpoint.h |1 +
arch/powerpc/kernel/hw_breakpoint.c | 19 ++-
2 files changed, 19 insertions(+), 1 deletion(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -202,6 +202,7 @@ int __kprobes hw_breakpoint_handler(stru
struct pt_regs *regs = args-regs;
int stepped = 1;
struct arch_hw_breakpoint *info;
+ unsigned long dar = regs-dar;
/* Disable breakpoints during exception handling */
set_dabr(0);
@@ -232,6 +233,21 @@ int __kprobes hw_breakpoint_handler(stru
goto out;
}
+ /*
+* Verify if dar lies within the address range occupied by the symbol
+* being watched to filter extraneous exceptions.
+*/
+ if (!((bp-attr.bp_addr = dar)
+(dar = (bp-attr.bp_addr + bp-attr.bp_len {
+ /*
+* This exception is triggered not because of a memory access
+* on the monitored variable but in the double-word address
+* range in which it is contained. We will consume this
+* exception, considering it as 'noise'.
+*/
+ info-extraneous_interrupt = true;
+ }
+
/* Do not emulate user-space instructions, instead single-step them */
if (user_mode(regs)) {
bp-ctx-task-thread.last_hit_ubp = bp;
@@ -286,7 +302,8 @@ int __kprobes single_step_dabr_instructi
* We shall invoke the user-defined callback function in the single
* stepping handler to confirm to 'trigger-after-execute' semantics
*/
- perf_bp_event(bp, regs);
+ if (!bp_info-extraneous_interrupt)
+ perf_bp_event(bp, regs);
/*
* Do not disable MSR_SE if the process was already in
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/hw_breakpoint.h
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -27,6 +27,7 @@
#ifdef CONFIG_HAVE_HW_BREAKPOINT
struct arch_hw_breakpoint {
+ boolextraneous_interrupt;
u8 len; /* length of the target data symbol */
int type;
unsigned long address;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/5] Removing dead CONFIG_SERIAL_TEXT_DEBUG
On Wed, Jun 09, 2010 at 12:00:46PM +0200, Christoph Egger wrote: CONFIG_SERIAL_TEXT_DEBUG doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger sicce...@cs.fau.de It would be better to conver this to work with CONFIG_PPC_EARLY_DEBUG and CONFIG_PPC_EARLY_DEBUG_40x. I'd rather just leave this for now until we can get it switched over. josh --- arch/powerpc/kernel/head_40x.S | 19 --- 1 files changed, 0 insertions(+), 19 deletions(-) diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S index a90625f..1a10e4d 100644 --- a/arch/powerpc/kernel/head_40x.S +++ b/arch/powerpc/kernel/head_40x.S @@ -939,25 +939,6 @@ initial_mmu: tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ -#if defined(CONFIG_SERIAL_TEXT_DEBUG) defined(SERIAL_DEBUG_IO_BASE) - - /* Load a TLB entry for the UART, so that ppc4xx_progress() can use - * the UARTs nice and early. We use a 4k real==virtual mapping. */ - - lis r3,serial_debug_io_b...@h - ori r3,r3,serial_debug_io_b...@l - mr r4,r3 - clrrwi r4,r4,12 - ori r4,r4,(TLB_WR|TLB_I|TLB_M|TLB_G) - - clrrwi r3,r3,12 - ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_4K)) - - li r0,0/* TLB slot 0 */ - tlbwe r4,r0,TLB_DATA - tlbwe r3,r0,TLB_TAG -#endif /* CONFIG_SERIAL_DEBUG_TEXT SERIAL_DEBUG_IO_BASE */ - isync /* Establish the exception vector base -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 0/5] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXII
On Mon, Jun 07, 2010 at 09:25:59PM +1000, Paul Mackerras wrote: On Mon, Jun 07, 2010 at 12:33:51PM +0530, K.Prasad wrote: Given that 'ptrace_bps' is used only for ptrace originated breakpoints and that we return early i.e. before detecting extraneous interrupts in hw_breakpoint_handler() (as shown above) they shouldn't overlap each other. The following comment in hw_breakpoint_handler() explains the same. /* * To prevent invocation of perf_event_bp(), we shall overload * thread.ptrace_bps[] pointer (unused for non-ptrace * exceptions) to flag an extraneous interrupt which must be * skipped. */ My point is that while we are using ptrace_bps[0] to mark a non-ptrace breakpoint that we're single-stepping, some other process could be ptracing this process and could get into ptrace_set_debugreg() and would think that the process already has a ptrace breakpoint and call modify_user_hw_breakpoint() when it should be calling register_user_hw_breakpoint(). Or this process could die and so we call flush_ptrace_hw_breakpoint() and it incorrectly thinks we have a ptrace breakpoint. If there is a reason why we can be quite sure that while we are using current-thread.ptrace_bps[0] in this way, ptrace_set_debugreg() can never get called with this task as the ptracee, and nor can flush_ptrace_hw_breakpoint() get called on this task, then maybe it's safe. But it's not at all obviously safe. So I'd very much rather we just use an extra flag somewhere, that isn't used elsewhere for anything else, so we can convince ourselves that it is all correct without having to look at lots of different pieces of code. There are 3 bytes of padding in struct arch_hw_breakpoint; couldn't we use one of them as a not really hit flag? Paul. ___ I get your reasoning now; ptrace_bps[] re-use will cause failures under these circumstances. I've sent a new version of the patchset which adds a new flag in 'struct arch_hw_breakpoint' (I was always thinking of 'struct thread_struct' before and was scared to introduce another new member in it, thereby leading me to incorrectly optimise using ptrace_bps) to flag extraneous_interrupt (Given that it's your idea I've added your signed-off too). Kindly let me know your comments, if any. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset.
On Tue, Jun 08, 2010 at 12:46:02PM -0400, Eric Millbrandt wrote:
+ switch (psc_dma-id) {
+ case 0:
+ gpio_mux = MPC52xx_GPIO_PSC1_MASK; break;
+ case 1:
+ gpio_mux = MPC52xx_GPIO_PSC2_MASK; break;
Please don't place the break on the same line as the statement, it's
not good for legibility.
+ dev_err(psc_dma-dev, cold reset\n);
You shouldn't be logging this as an error, doing a cold reset is
perfectly normal.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc5200 ac97 gpio reset
On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote: In message aanlktimis90kr5uqhdbq02osd94dn08soitm51ylr...@mail.gmail.com you wrote: Would making a change in uboot be a better solution? Eric, can you verify if changing uboot also fixes the problem? To me it seems better if the driver itself does what needs to be done instead of relying on specific settings that may or may not be done in U-Boot. Keep in mind that drivers may be loaded as modules, and that we even see cases where the same port serves multiple purposes by loading different driver modules (yes, this is not exactly a clever idea, but hardware designers come up with such solutions). I do tend to agree that having the driver be able to cope with things is a bit more robust - it's not terribly discoverable for users and people are often justifiably nervous about updating their bootloader. It might, however, be sensible to make the GPIO based reset be optional based on having the OF data for the GPIOs. That way existing DTs will work without changes and systems that can use the reset implementation in the controller will be able to do so. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5b/5] Removing dead CONFIG_PPC47x
CONFIG_PPC47x should actually be spelled CONFIG_PPC_47x as reported by Andreas Schwab. Signed-off-by: Christoph Egger sicce...@cs.fau.de --- arch/powerpc/mm/44x_mmu.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c index d8c6efb..f70da7e 100644 --- a/arch/powerpc/mm/44x_mmu.c +++ b/arch/powerpc/mm/44x_mmu.c @@ -76,11 +76,11 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys) tlbwe %1,%3,%5\n tlbwe %0,%3,%6\n : -#ifdef CONFIG_PPC47x +#ifdef CONFIG_PPC_47x : r (PPC47x_TLB2_S_RWX), #else : r (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G), #endif r (phys), r (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M), r (entry), -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix integer constant warning
On Tue, 2010-06-08 at 14:12 +0100, David Howells wrote: Steve Best sfb...@us.ibm.com wrote: -#define KERNELBASE (0xc000) +#define KERNELBASE (0xc000ULL) Is this the right fix? The code producing the warning is subtracting 0xc000 from a 32-bit number: agree this fix needs more work, and can be dropped. Paul has another patch that removes this file, since it is no longer used. I assume we'll go with that patch. naca = ntohl(*((u_int32_t*) inbuf[0x0C])) - KERNELBASE; which seems distinctly odd. David -Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5b/5] Removing dead CONFIG_PPC47x
On Wed, Jun 09, 2010 at 01:02:39PM +0200, Christoph Egger wrote: CONFIG_PPC47x should actually be spelled CONFIG_PPC_47x as reported by Andreas Schwab. Signed-off-by: Christoph Egger sicce...@cs.fau.de Thanks, I'll pull this one in and get it merged. josh --- arch/powerpc/mm/44x_mmu.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c index d8c6efb..f70da7e 100644 --- a/arch/powerpc/mm/44x_mmu.c +++ b/arch/powerpc/mm/44x_mmu.c @@ -76,11 +76,11 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys) tlbwe %1,%3,%5\n tlbwe %0,%3,%6\n : -#ifdef CONFIG_PPC47x +#ifdef CONFIG_PPC_47x : r (PPC47x_TLB2_S_RWX), #else : r (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G), #endif r (phys), r (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M), r (entry), -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'merge' branch of 4xx tree
Hi Ben, Two small fixes that should go into 2.6.35. Please pull them and shuffle along to Linus. I know Linus is leaving for a while at the end of this week, so if you want me to ask him to pull directly just let me know. josh The following changes since commit c2cdf6aba0dfcfb54be646ab630c1bccd180e890: Benjamin Herrenschmidt (1): powerpc/macio: Fix probing of macio devices by using the right of match table are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge Christoph Egger (1): powerpc/47x: Correct typo in ifdef guard for 47x Stefan Roese (1): powerpc/44x: Fix UART2/3 interrupt assignment in PPC460EX/GT dts files arch/powerpc/boot/dts/canyonlands.dts |4 ++-- arch/powerpc/boot/dts/glacier.dts |4 ++-- arch/powerpc/mm/44x_mmu.c |2 +- 3 files changed, 5 insertions(+), 5 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc5200 ac97 gpio reset
On Wed, Jun 9, 2010 at 2:13 AM, Wolfgang Denk w...@denx.de wrote: Dear Jon Smirl, In message aanlktimis90kr5uqhdbq02osd94dn08soitm51ylr...@mail.gmail.com you wrote: Would making a change in uboot be a better solution? Eric, can you verify if changing uboot also fixes the problem? To me it seems better if the driver itself does what needs to be done instead of relying on specific settings that may or may not be done in U-Boot. Keep in mind that drivers may be loaded as modules, and that we even see cases where the same port serves multiple purposes by loading different driver modules (yes, this is not exactly a clever idea, but hardware designers come up with such solutions). Someone with a scope can verify this, but my understanding of what happens is that uboot by default puts the pins into GPIO mode. Linux boots and reprograms the pins into AC97 mode. When the pins are reprogrammed it generates glitches on the reset line. About half of the time these glitches put the attached codec into test mode. Once the chip is in test mode it won't respond to normal commands. Does the opposite happen? What if uboot has the pins in AC97 mode and Linux reprograms them into GPIO mode. Will it also put the chip into test mode? The piece of information I've been missing is an understanding of what is making the glitches that trigger test mode. Another strategy would be to leave reset as is. If the chip is unresponsive send it the commands to get it out of test mode. That could be made part of the reset logic in the Linux driver. 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 The typical page layout program is nothing more than an electronic light table for cutting and pasting documents. -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] Removing dead CONFIG_SMP_750
On Wed, Jun 09, 2010 at 12:00:21PM +0200, Christoph Egger wrote:
CONFIG_SMP_750 doesn't exist in Kconfig, therefore removing all
references for it from the source code.
Yeah, we don't support SMP on 750 at the moment. This code was carried over
from the arch/ppc days, and that code was present pre-git. I think we can
drop it, but I'll leave that up to Ben. Maybe he has crazy plans for a 750 SMP
board.
josh
Signed-off-by: Christoph Egger sicce...@cs.fau.de
---
arch/powerpc/mm/tlb_hash32.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/tlb_hash32.c b/arch/powerpc/mm/tlb_hash32.c
index 8aaa8b7..925fecb 100644
--- a/arch/powerpc/mm/tlb_hash32.c
+++ b/arch/powerpc/mm/tlb_hash32.c
@@ -94,11 +94,7 @@ void tlb_flush(struct mmu_gather *tlb)
* the cache operations on the bus. Hence we need to use an IPI
* to get the other CPU(s) to invalidate their TLBs.
*/
-#ifdef CONFIG_SMP_750
-#define FINISH_FLUSH smp_send_tlb_invalidate(0)
-#else
#define FINISH_FLUSH do { } while (0)
-#endif
static void flush_range(struct mm_struct *mm, unsigned long start,
unsigned long end)
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/2] mpc5200 ac97 gpio reset
-Original Message- From: Jon Smirl [mailto:jonsm...@gmail.com] Sent: Wednesday, June 09, 2010 08:22 To: Wolfgang Denk Cc: Eric Millbrandt; Mark Brown; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 0/2] mpc5200 ac97 gpio reset On Wed, Jun 9, 2010 at 2:13 AM, Wolfgang Denk w...@denx.de wrote: Dear Jon Smirl, In message AANLkTimIs90kR5uqhdBQ02oSd94dn08sOITm51Ylrl4- @mail.gmail.com you wrote: Would making a change in uboot be a better solution? Eric, can you verify if changing uboot also fixes the problem? To me it seems better if the driver itself does what needs to be done instead of relying on specific settings that may or may not be done in U-Boot. Keep in mind that drivers may be loaded as modules, and that we even see cases where the same port serves multiple purposes by loading different driver modules (yes, this is not exactly a clever idea, but hardware designers come up with such solutions). Someone with a scope can verify this, but my understanding of what happens is that uboot by default puts the pins into GPIO mode. Linux boots and reprograms the pins into AC97 mode. When the pins are reprogrammed it generates glitches on the reset line. About half of the time these glitches put the attached codec into test mode. Once the chip is in test mode it won't respond to normal commands. Most of the pins on the 5200 default to gpio when the chip comes out of reset. U-Boot then sets the pin muxing by writing to the port configuration register. This value is defined as CONFIG_SYS_GPS_PORT_CONFIG in the U-Boot board header file. The implementation of ac97 gives the codec control of the bus clock. This means that the codec is usually be clocking BITCLK when the 5200 pulls the reset line low, which is the cause of the problem. Freescale should have handled this on the silicon by having the ac97 cold reset function pull the SYNC and SDATAOUT lines low during cold reset, but instead they just documented the problem. From the MPC5200B user manual: Some AC97 devices goes to a test mode, if the Sync line is high during the Res line is low (reset phase). To avoid this behavior the Sync line must be also forced to zero during the reset phase. To do that, the pin muxing should switch to GPIO mode and the GPIO control register should be used to control the output lines. Another strategy would be to leave reset as is. If the chip is unresponsive send it the commands to get it out of test mode. That could be made part of the reset logic in the Linux driver. This is what we used to do when we were using the out-of-tree ac97 driver from Sylvain Munaut. We would generate a cold reset/warm reset sequence in U-Boot. We modified the Linux ac97 driver so that the cold reset functions was a no-op. It did avoid the problem, but it caused other problems. Sometimes it is necessary to cold reset the codec in Linux to resync the ac97 bus. 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 The typical page layout program is nothing more than an electronic light table for cutting and pasting documents. -- Jon Smirl jonsm...@gmail.com Eric Millbrandt -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/2] mpc5200 ac97 gpio reset
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Wednesday, June 09, 2010 06:31 To: Wolfgang Denk Cc: Jon Smirl; Eric Millbrandt; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 0/2] mpc5200 ac97 gpio reset --snip-- It might, however, be sensible to make the GPIO based reset be optional based on having the OF data for the GPIOs. That way existing DTs will work without changes and systems that can use the reset implementation in the controller will be able to do so. This is a reasonable request. I will respin the patch to do this. Eric Millbrandt This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc5200 ac97 gpio reset
On Wed, Jun 09, 2010 at 10:21:40AM -0400, Eric Millbrandt wrote: [Please fix your MUA to word wrap paragraphs to within 80 characters, I've reflowed the text below.] From the MPC5200B user manual: Some AC97 devices goes to a test mode, if the Sync line is high during the Res line is low (reset phase). To avoid this behavior the Sync line must be also forced to zero during the reset phase. To do that, the pin muxing should switch to GPIO mode and the GPIO control register should be used to control the output lines. Please include this quote in the changelog for the patch, if this a documented workaround from the vendor that's a very different thing to something that you've found happens to work on your systems (which is more what your changelog sounded like). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
CPM UART on MPC8270
Hi All,
I'm attempting to get an SCC port on an MPC8270 working with Linux. I'm
not overly familiar with the CPM and am having a bit of trouble.
Linux is booting natively on the 8270. I have access to the 8270 via a
set of PCI windows from a second core (includes one setup over the main
memory and one over the IMMR) and SMC1 is up and working with a console.
The SCCs seem to be detected correctly at boot:
f011a80.serial: ttyCPM0 at MMIO 0xc3014a80 (irq = 16) is a CPM UART
f011a00.serial: ttyCPM1 at MMIO 0xc3018a00 (irq = 40) is a CPM UART
f011a20.serial: ttyCPM2 at MMIO 0xc3020a20 (irq = 41) is a CPM UART
f011a40.serial: ttyCPM3 at MMIO 0xc3028a40 (irq = 42) is a CPM UART
With the DTS reading:
smc1: ser...@11a80 {
device_type = serial;
compatible = fsl,mpc8270-smc-uart,
fsl,cpm2-smc-uart;
reg = 0x11a80 0x20 0x87fc 2;
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0x1d00;
};
scc1: ser...@11a00 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a00 0x20 0x8000 0x100;
interrupts = 40 8;
interrupt-parent = PIC;
fsl,cpm-brg = 3;
fsl,cpm-command = 0x80;
};
scc2: ser...@11a20 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a20 0x20 0x8100 0x100;
interrupts = 41 8;
interrupt-parent = PIC;
fsl,cpm-brg = 6;
fsl,cpm-command = 0x4a0;
};
scc3: ser...@11a40 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a40 0x20 0x8200 0x100;
interrupts = 42 8;
interrupt-parent = PIC;
fsl,cpm-brg = 1;
fsl,cpm-command = 0x8c0;
};
I believe that I have the pins setup correctly and the BRGs connected
correctly in the setup_arch function.
At the moment I have SCC3 wired out. If I attempt to echo data out of
the SCC (echo Hello /dev/ttyCPM3) I get the prompt sits waiting.
Rebooting and turning on the debug yields the following output on the
console (but nothing out of the SCC port):
CPM uart[3]:startup
Interrupt attached
CPM uart[3]:set_termios
CPM uart[3]:start tx
CPM uart[3]:stop tx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:stop rx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:shutdown
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
...
It seemed to be waiting for ready bit of the Transmit Buffer Descriptor
to be cleared (which it never seems to be), prodding this bit through
the pci window did cause the process to continue, no data out but I did
get back to the prompt on the console.
I'm sure I'm just missing something really basic - can anyone enlighten me?
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748| Barbirolli Square, Manchester,
E martyn.we...@ge.com| M2 3AB VAT:GB 927559189
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
can you give me some advice to test dTSEC
Hi experts can you give me some advice to test dTSEC Lei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc5200 ac97 gpio reset
On Wed, Jun 9, 2010 at 10:32 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Jun 09, 2010 at 10:21:40AM -0400, Eric Millbrandt wrote: [Please fix your MUA to word wrap paragraphs to within 80 characters, I've reflowed the text below.] From the MPC5200B user manual: Some AC97 devices goes to a test mode, if the Sync line is high during the Res line is low (reset phase). To avoid this behavior the Sync line must be also forced to zero during the reset phase. To do that, the pin muxing should switch to GPIO mode and the GPIO control register should be used to control the output lines. Please include this quote in the changelog for the patch, if this a documented workaround from the vendor that's a very different thing to something that you've found happens to work on your systems (which is more what your changelog sounded like). Mark, is there a way to ask the chip if it is in test mode? We need to be sure that's whats happening and it isn't some other glitch. -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[tip:irq/urgent] genirq: Deal with desc-set_type() changing desc-chip
Commit-ID: 4673247562e39a17e09440fa1400819522ccd446 Gitweb: http://git.kernel.org/tip/4673247562e39a17e09440fa1400819522ccd446 Author: Thomas Gleixner t...@linutronix.de AuthorDate: Mon, 7 Jun 2010 17:53:51 +0200 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Wed, 9 Jun 2010 17:05:08 +0200 genirq: Deal with desc-set_type() changing desc-chip The set_type() function can change the chip implementation when the trigger mode changes. That might result in using an non-initialized irq chip when called from __setup_irq() or when called via set_irq_type() on an already enabled irq. The set_irq_type() function should not be called on an enabled irq, but because we forgot to put a check into it, we have a bunch of users which grew the habit of doing that and it never blew up as the function is serialized via desc-lock against all users of desc-chip and they never hit the non-initialized irq chip issue. The easy fix for the __setup_irq() issue would be to move the irq_chip_set_defaults(desc-chip) call after the trigger setting to make sure that a chip change is covered. But as we have already users, which do the type setting after request_irq(), the safe fix for now is to call irq_chip_set_defaults() from __irq_set_trigger() when desc-set_type() changed the irq chip. It needs a deeper analysis whether we should refuse to change the chip on an already enabled irq, but that'd be a large scale change to fix all the existing users. So that's neither stable nor 2.6.35 material. Reported-by: Esben Haabendal e...@doredevelopment.dk Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: linuxppc-dev linuxppc-...@ozlabs.org Cc: sta...@kernel.org --- kernel/irq/manage.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 3164ba7..e149748 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -456,6 +456,9 @@ int __irq_set_trigger(struct irq_desc *desc, unsigned int irq, /* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */ desc-status = ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK); desc-status |= flags; + + if (chip != desc-chip) + irq_chip_set_defaults(desc-chip); } return ret; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc5200 ac97 gpio reset
On Wed, Jun 09, 2010 at 10:41:23AM -0400, Jon Smirl wrote: On Wed, Jun 9, 2010 at 10:32 AM, Mark Brown Please include this quote in the changelog for the patch, if this a documented workaround from the vendor that's a very different thing to something that you've found happens to work on your systems (which is more what your changelog sounded like). Mark, is there a way to ask the chip if it is in test mode? We need to be sure that's whats happening and it isn't some other glitch. I'd need to work with the hardware teams to obtain this information, but I can confirm that having SYNC high while doing a reset is not supported and so fixing the driver to not do that is a good idea independantly of what it actually does to the chip. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CPM UART on MPC8270
I couldn't get the echo /dev/xxx to work. I had to write a small app
that opened the device and write and read characters for testing.
Start there and you may find it is actually working.
JB
On Wed, Jun 9, 2010 at 8:37 AM, Martyn Welch martyn.we...@ge.com wrote:
Hi All,
I'm attempting to get an SCC port on an MPC8270 working with Linux. I'm
not overly familiar with the CPM and am having a bit of trouble.
Linux is booting natively on the 8270. I have access to the 8270 via a
set of PCI windows from a second core (includes one setup over the main
memory and one over the IMMR) and SMC1 is up and working with a console.
The SCCs seem to be detected correctly at boot:
f011a80.serial: ttyCPM0 at MMIO 0xc3014a80 (irq = 16) is a CPM UART
f011a00.serial: ttyCPM1 at MMIO 0xc3018a00 (irq = 40) is a CPM UART
f011a20.serial: ttyCPM2 at MMIO 0xc3020a20 (irq = 41) is a CPM UART
f011a40.serial: ttyCPM3 at MMIO 0xc3028a40 (irq = 42) is a CPM UART
With the DTS reading:
smc1: ser...@11a80 {
device_type = serial;
compatible = fsl,mpc8270-smc-uart,
fsl,cpm2-smc-uart;
reg = 0x11a80 0x20 0x87fc 2;
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0x1d00;
};
scc1: ser...@11a00 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a00 0x20 0x8000 0x100;
interrupts = 40 8;
interrupt-parent = PIC;
fsl,cpm-brg = 3;
fsl,cpm-command = 0x80;
};
scc2: ser...@11a20 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a20 0x20 0x8100 0x100;
interrupts = 41 8;
interrupt-parent = PIC;
fsl,cpm-brg = 6;
fsl,cpm-command = 0x4a0;
};
scc3: ser...@11a40 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a40 0x20 0x8200 0x100;
interrupts = 42 8;
interrupt-parent = PIC;
fsl,cpm-brg = 1;
fsl,cpm-command = 0x8c0;
};
I believe that I have the pins setup correctly and the BRGs connected
correctly in the setup_arch function.
At the moment I have SCC3 wired out. If I attempt to echo data out of
the SCC (echo Hello /dev/ttyCPM3) I get the prompt sits waiting.
Rebooting and turning on the debug yields the following output on the
console (but nothing out of the SCC port):
CPM uart[3]:startup
Interrupt attached
CPM uart[3]:set_termios
CPM uart[3]:start tx
CPM uart[3]:stop tx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:stop rx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:shutdown
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
...
It seemed to be waiting for ready bit of the Transmit Buffer Descriptor
to be cleared (which it never seems to be), prodding this bit through
the pci window did cause the process to continue, no data out but I did
get back to the prompt on the console.
I'm sure I'm just missing something really basic - can anyone enlighten me?
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square,
Manchester,
E martyn.we...@ge.com | M2 3AB VAT:GB 927559189
___
Linuxppc-dev mailing
Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
Albert Cahalan [acaha...@gmail.com] wrote:
| On Tue, Jun 1, 2010 at 9:38 PM, Sukadev Bhattiprolu
| suka...@linux.vnet.ibm.com wrote:
| | Come on, seriously, you know it's ia64 and hppa that
| | have issues. Maybe the nommu ports also have issues.
| |
| | The only portable way to specify the stack is base and offset,
| | with flags or magic values for share and kernel managed.
|
| Ah, ok, we have not yet ported to IA64 and I see now where the #ifdef
| comes in.
|
| But are you saying that we should force x86 and other architectures to
| specify base and offset for eclone() even though they currently specify
| just the stack pointer to clone() ?
|
| Even for x86, it's an easier API. Callers would be specifying
| two numbers they already have: the argument and return value
| for malloc. Currently the numbers must be added together,
| destroying information, except on hppa (must not add size)
| and ia64 (must use what I'm proposing already).
I agree its easier and would avoid #ifdefs in the applications.
Peter, Arnd, Roland - do you have any concerns with requiring all
architectures to specify the stack to eclone() as [base, offset]
To recap, currently we have
struct clone_args {
u64 clone_flags_high;
/*
* Architectures can use child_stack for either the stack pointer or
* the base of of stack. If child_stack is used as the stack pointer,
* child_stack_size must be 0. Otherwise child_stack_size must be
* set to size of allocated stack.
*/
u64 child_stack;
u64 child_stack_size;
u64 parent_tid_ptr;
u64 child_tid_ptr;
u32 nr_pids;
u32 reserved0;
};
sys_eclone(u32 flags_low, struct clone_args * __user cargs, int cargs_size,
pid_t * __user pids)
Most architecutres would specify the stack pointer in -child_stack and
ignore the -child_stack_size.
IA64 specifies the *stack-base* in -child_stack and the stack size in
-child_stack_size.
Albert and Randy point out that this would require #ifdefs in the
application code that intends to be portable across say IA64 and x86.
Can we instead have all architectures specify [base, size] ?
Thanks
Sukadev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
On 06/09/2010 11:14 AM, Sukadev Bhattiprolu wrote: | | Even for x86, it's an easier API. Callers would be specifying | two numbers they already have: the argument and return value | for malloc. Currently the numbers must be added together, | destroying information, except on hppa (must not add size) | and ia64 (must use what I'm proposing already). I agree its easier and would avoid #ifdefs in the applications. Peter, Arnd, Roland - do you have any concerns with requiring all architectures to specify the stack to eclone() as [base, offset] Makes sense to me. There might be advantages to be able to track the size of the stack allocation even for other architectures, too. -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] gianfar: Revive the driver for eTSEC devices (disable timestamping)
Since commit cc772ab7cdcaa24d1fae332d92a1602788644f7a (gianfar: Add hardware RX timestamping support), the driver no longer works on at least MPC8313ERDB and MPC8568EMDS boards (and possibly much more boards as well). That's how MPC8313 Reference Manual describes RCTRL_TS_ENABLE bit: Timestamp incoming packets as padding bytes. PAL field is set to 8 if the PAL field is programmed to less than 8. Must be set to zero if TMR_CTRL[TE]=0. I see that the commit above sets this bit, but it doesn't handle TMR_CTRL. Manfred probably had this bit set by the firmware for his boards. But obviously this isn't true for all boards in the wild. Also, I recall that Freescale BSPs were explicitly disabling the timestamping because of a performance drop. For now, the best way to deal with this is just disable the timestamping, and later we can discuss proper device tree bindings and implement enabling this feature via some property. Signed-off-by: Anton Vorontsov avoront...@mvista.com --- drivers/net/gianfar.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 1830f31..46c69cd 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -747,8 +747,7 @@ static int gfar_of_init(struct of_device *ofdev, struct net_device **pdev) FSL_GIANFAR_DEV_HAS_CSUM | FSL_GIANFAR_DEV_HAS_VLAN | FSL_GIANFAR_DEV_HAS_MAGIC_PACKET | - FSL_GIANFAR_DEV_HAS_EXTENDED_HASH | - FSL_GIANFAR_DEV_HAS_TIMER; + FSL_GIANFAR_DEV_HAS_EXTENDED_HASH; ctype = of_get_property(np, phy-connection-type, NULL); -- 1.7.0.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BUG: scheduling while atomic: swapper/0/0x00000002
Hello! I get the following during boot on a 16 CPU Power box. Thoughts? (/proc/config attached) Thanx, Paul UDP hash table entries: 2048 (order: 6, 262144 bytes) UDP-Lite hash table entries: 2048 (order: 6, 262144 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Trying to unpack rootfs image as initramfs... Freeing initrd memory: 2455k freed BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 audit: initializing netlink socket (disabled) type=2000 audit(1276043741.388:1): initialized BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.35-rc2-autokern1 # Wed Jun 9 00:29:21 2010 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S_64=y # CONFIG_PPC_BOOK3E_64 is not set CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_PPC_HAVE_PMU_SUPPORT=y CONFIG_PPC_PERF_CTRS=y CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_IRQ_PER_CPU=y CONFIG_NR_IRQS=512 CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set
Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
Peter, Arnd, Roland - do you have any concerns with requiring all architectures to specify the stack to eclone() as [base, offset] I can't see why that would be a problem. It's consistent with the sigaltstack interface we already have. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BUG: scheduling while atomic: swapper/0/0x00000002
On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote: Hello! I get the following during boot on a 16 CPU Power box. Thoughts? (/proc/config attached) Wow... looks like the preempt count of the idle task got busted or something ... how reproduceable ? Something like a record of previous interrupts might be useful.. Cheers, Ben. Thanx, Paul UDP hash table entries: 2048 (order: 6, 262144 bytes) UDP-Lite hash table entries: 2048 (order: 6, 262144 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Trying to unpack rootfs image as initramfs... Freeing initrd memory: 2455k freed BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 audit: initializing netlink socket (disabled) type=2000 audit(1276043741.388:1): initialized BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Revive the driver for eTSEC devices (disable timestamping)
From: Anton Vorontsov avoront...@mvista.com Date: Wed, 9 Jun 2010 23:32:19 +0400 Since commit cc772ab7cdcaa24d1fae332d92a1602788644f7a (gianfar: Add hardware RX timestamping support), the driver no longer works on at least MPC8313ERDB and MPC8568EMDS boards (and possibly much more boards as well). That's how MPC8313 Reference Manual describes RCTRL_TS_ENABLE bit: Timestamp incoming packets as padding bytes. PAL field is set to 8 if the PAL field is programmed to less than 8. Must be set to zero if TMR_CTRL[TE]=0. I see that the commit above sets this bit, but it doesn't handle TMR_CTRL. Manfred probably had this bit set by the firmware for his boards. But obviously this isn't true for all boards in the wild. Also, I recall that Freescale BSPs were explicitly disabling the timestamping because of a performance drop. For now, the best way to deal with this is just disable the timestamping, and later we can discuss proper device tree bindings and implement enabling this feature via some property. Signed-off-by: Anton Vorontsov avoront...@mvista.com Agreed, applied, thanks Anton. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CPM UART on MPC8270
Although I haven't used scc port as uart, I think your smc1 part in your dts
file maybe is wrong.
ser...@11a82 { ...
reg = 0x11a80 0x20 0x87fc 2;
should be:
reg = 0x11a80 0x20 XXX 40;
XXX is the value which is set at 0x87fc in your bootloader.
I just got this mistake a few days ago.
- Original Message -
From: Martyn Welch martyn.we...@ge.com
To: linuxppc-dev list linuxppc-...@ozlabs.org
Sent: Wednesday, June 09, 2010 10:37 PM
Subject: CPM UART on MPC8270
Hi All,
I'm attempting to get an SCC port on an MPC8270 working with Linux. I'm
not overly familiar with the CPM and am having a bit of trouble.
Linux is booting natively on the 8270. I have access to the 8270 via a
set of PCI windows from a second core (includes one setup over the main
memory and one over the IMMR) and SMC1 is up and working with a console.
The SCCs seem to be detected correctly at boot:
f011a80.serial: ttyCPM0 at MMIO 0xc3014a80 (irq = 16) is a CPM UART
f011a00.serial: ttyCPM1 at MMIO 0xc3018a00 (irq = 40) is a CPM UART
f011a20.serial: ttyCPM2 at MMIO 0xc3020a20 (irq = 41) is a CPM UART
f011a40.serial: ttyCPM3 at MMIO 0xc3028a40 (irq = 42) is a CPM UART
With the DTS reading:
smc1: ser...@11a80 {
device_type = serial;
compatible = fsl,mpc8270-smc-uart,
fsl,cpm2-smc-uart;
reg = 0x11a80 0x20 0x87fc 2;
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0x1d00;
};
scc1: ser...@11a00 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a00 0x20 0x8000 0x100;
interrupts = 40 8;
interrupt-parent = PIC;
fsl,cpm-brg = 3;
fsl,cpm-command = 0x80;
};
scc2: ser...@11a20 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a20 0x20 0x8100 0x100;
interrupts = 41 8;
interrupt-parent = PIC;
fsl,cpm-brg = 6;
fsl,cpm-command = 0x4a0;
};
scc3: ser...@11a40 {
device_type = serial;
compatible = fsl,mpc8270-scc-uart,
fsl,cpm2-scc-uart;
reg = 0x11a40 0x20 0x8200 0x100;
interrupts = 42 8;
interrupt-parent = PIC;
fsl,cpm-brg = 1;
fsl,cpm-command = 0x8c0;
};
I believe that I have the pins setup correctly and the BRGs connected
correctly in the setup_arch function.
At the moment I have SCC3 wired out. If I attempt to echo data out of
the SCC (echo Hello /dev/ttyCPM3) I get the prompt sits waiting.
Rebooting and turning on the debug yields the following output on the
console (but nothing out of the SCC port):
CPM uart[3]:startup
Interrupt attached
CPM uart[3]:set_termios
CPM uart[3]:start tx
CPM uart[3]:stop tx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:stop rx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:shutdown
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
...
It seemed to be waiting for ready bit of the Transmit Buffer Descriptor
to be cleared (which it never seems to be), prodding this bit through
the pci window did cause the process to continue, no data out but I did
get back to the prompt on the console.
I'm sure I'm just missing something really basic - can anyone enlighten me?
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at
Re: BUG: scheduling while atomic: swapper/0/0x00000002
On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote: Hello! I get the following during boot on a 16 CPU Power box. Thoughts? (/proc/config attached) Wow... looks like the preempt count of the idle task got busted or something ... how reproduceable ? Something like a record of previous interrupts might be useful.. I have seen it only once, but it did get my attention. I will try running it again this evening when/if kernel-ml8 is free again. 2.6.35-rc2, I should have mentioned. Thanx, Paul Cheers, Ben. Thanx, Paul UDP hash table entries: 2048 (order: 6, 262144 bytes) UDP-Lite hash table entries: 2048 (order: 6, 262144 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Trying to unpack rootfs image as initramfs... Freeing initrd memory: 2455k freed BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 audit: initializing netlink socket (disabled) type=2000 audit(1276043741.388:1): initialized BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: Call Trace: [c0008e1afc20] [c0011990] .show_stack+0x70/0x184 (unreliable) [c0008e1afcd0] [c005cb60] .__schedule_bug+0xac/0xd0 [c0008e1afd70] [c05f0c34] .schedule+0xc0/0x894 [c0008e1afe40] [c00142d0] .cpu_idle+0x1f8/0x20c [c0008e1afed0] [c0600b08] .start_secondary+0x3bc/0x3fc [c0008e1aff90] [c0008264] .start_secondary_prolog+0x10/0x14 BUG: scheduling while atomic: swapper/0/0x0002 no locks held by swapper/0. Modules linked in: ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 0/5] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXII
On Wed, Jun 09, 2010 at 04:02:23PM +0530, K.Prasad wrote: (Given that it's your idea I've added your signed-off too). Actually, you should never add someone else's signed-off-by unless they specifically ask you to. The signed-off-by lines are supposed to show the path that the patch took to get into the tree, so in general only the original author(s) and the maintainers who passed the patch along should add signed-off-by lines. It would only be a maintainer who would add someone else's signed-off-by, and then only if someone who needs to sign off on the patch had forgotten and then asked the maintainer to correct their mistake. In this case the appropriate way to give credit would be just a sentence in the patch description; no formal tag is needed. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/5] Generalize OF gpio support code
This series makes all gpio drivers usable from the OF support apis by automatically registering a default OF translator when the of_node pointer is assigned. These patches are heavily based on the work that Anton did earlier, but I didn't add the notifiers infrastructure and the OF data now lives directly inside the core gpio_chip structure so that fewer gymnastics are needed to get at it. These patches are currently sitting in the following branch: git://git.secretlab.ca/git/linux-2.6 next-devicetree --- Anton Vorontsov (3): gpiolib: cosmetic improvements for error handling in gpiochip_add() of/gpio: Kill of_gpio_chip and add members directly to gpio_chip of/gpio: add default of_xlate function if device has a node pointer Grant Likely (2): of/gpio: stop using device_node data pointer to find gpio_chip of/device: Add OF style matching helper function arch/microblaze/kernel/reset.c | 12 ++- arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 30 arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 29 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 34 ++--- arch/powerpc/platforms/86xx/gef_gpio.c | 24 +++ arch/powerpc/sysdev/cpm1.c | 10 +-- arch/powerpc/sysdev/cpm_common.c |5 - arch/powerpc/sysdev/mpc8xxx_gpio.c |5 - arch/powerpc/sysdev/ppc4xx_gpio.c |5 - arch/powerpc/sysdev/qe_lib/gpio.c | 31 - arch/powerpc/sysdev/simple_gpio.c |5 - drivers/gpio/gpiolib.c | 55 ++- drivers/gpio/xilinx_gpio.c | 15 ++-- drivers/of/device.c|2 - drivers/of/gpio.c | 86 +++- include/asm-generic/gpio.h | 15 include/linux/of_device.h | 19 + include/linux/of_gpio.h| 35 +++--- 18 files changed, 226 insertions(+), 191 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/5] gpiolib: cosmetic improvements for error handling in gpiochip_add()
From: Anton Vorontsov avoront...@ru.mvista.com Hopefully it makes the code look nicer and makes it easier to extend this function. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Grant Likely grant.lik...@secretlab.ca CC: devicetree-disc...@lists.ozlabs.org CC: linux-ker...@vger.kernel.org --- drivers/gpio/gpiolib.c | 18 -- 1 files changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 3ca3654..713ca0e 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1101,14 +1101,20 @@ int gpiochip_add(struct gpio_chip *chip) unlock: spin_unlock_irqrestore(gpio_lock, flags); - if (status == 0) - status = gpiochip_export(chip); + + if (status) + goto fail; + + status = gpiochip_export(chip); + if (status) + goto fail; + + return 0; fail: /* failures here can mean systems won't boot... */ - if (status) - pr_err(gpiochip_add: gpios %d..%d (%s) failed to register\n, - chip-base, chip-base + chip-ngpio - 1, - chip-label ? : generic); + pr_err(gpiochip_add: gpios %d..%d (%s) failed to register\n, + chip-base, chip-base + chip-ngpio - 1, + chip-label ? : generic); return status; } EXPORT_SYMBOL_GPL(gpiochip_add); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/5] of/gpio: Kill of_gpio_chip and add members directly to gpio_chip
From: Anton Vorontsov avoront...@ru.mvista.com
The OF gpio infrastructure is great for describing GPIO connections within
the device tree. However, using a GPIO binding still requires changes to
the gpio controller just to add an of_gpio structure. In most cases, the
gpio controller doesn't actually need any special support and the simple
OF gpio mapping function is more than sufficient. Additional, the current
scheme of using of_gpio_chip requires a convoluted scheme to maintain
1:1 mappings between of_gpio_chip and gpio_chip instances.
If the struct of_gpio_chip data members were moved into struct gpio_chip,
then it would simplify the processing of OF gpio bindings, and it would
make it trivial to use device tree OF connections on existing gpiolib
controller drivers.
This patch eliminates the of_gpio_chip structure and moves the relevant
fields into struct gpio_chip (conditional on CONFIG_OF_GPIO). This move
simplifies the existing code and prepares for adding automatic device tree
support to existing drivers.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Andrew Morton a...@linux-foundation.org
Cc: Anton Vorontsov avoront...@ru.mvista.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Bill Gatliff b...@billgatliff.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Jean Delvare kh...@linux-fr.org
---
arch/microblaze/kernel/reset.c | 12 +++---
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 32 ---
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 29 +++---
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 15 +++
arch/powerpc/platforms/86xx/gef_gpio.c | 24 ++--
arch/powerpc/sysdev/cpm1.c | 12 ++
arch/powerpc/sysdev/cpm_common.c |6 +--
arch/powerpc/sysdev/mpc8xxx_gpio.c |6 +--
arch/powerpc/sysdev/ppc4xx_gpio.c |6 +--
arch/powerpc/sysdev/qe_lib/gpio.c | 32 +++
arch/powerpc/sysdev/simple_gpio.c |6 +--
drivers/gpio/xilinx_gpio.c | 16 +++-
drivers/of/gpio.c | 50
include/asm-generic/gpio.h | 12 ++
include/linux/of_gpio.h| 29 ++
15 files changed, 129 insertions(+), 158 deletions(-)
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index a1721a3..5476d3c 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -24,8 +24,8 @@ static int of_reset_gpio_handle(void)
int ret; /* variable which stored handle reset gpio pin */
struct device_node *root; /* root node */
struct device_node *gpio; /* gpio node */
- struct of_gpio_chip *of_gc = NULL;
- enum of_gpio_flags flags ;
+ struct gpio_chip *gc;
+ u32 flags;
const void *gpio_spec;
/* find out root node */
@@ -39,19 +39,19 @@ static int of_reset_gpio_handle(void)
goto err0;
}
- of_gc = gpio-data;
- if (!of_gc) {
+ gc = gpio-data;
+ if (!gc) {
pr_debug(%s: gpio controller %s isn't registered\n,
root-full_name, gpio-full_name);
ret = -ENODEV;
goto err1;
}
- ret = of_gc-xlate(of_gc, root, gpio_spec, flags);
+ ret = gc-of_xlate(gc, root, gpio_spec, flags);
if (ret 0)
goto err1;
- ret += of_gc-gc.base;
+ ret += gc-base;
err1:
of_node_put(gpio);
err0:
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index ca5305a..fd0912e 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -152,21 +152,21 @@ static int __devinit mpc52xx_wkup_gpiochip_probe(struct
of_device *ofdev,
{
struct mpc52xx_gpiochip *chip;
struct mpc52xx_gpio_wkup __iomem *regs;
- struct of_gpio_chip *ofchip;
+ struct gpio_chip *gc;
int ret;
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
- ofchip = chip-mmchip.of_gc;
+ gc = chip-mmchip.gc;
- ofchip-gpio_cells = 2;
- ofchip-gc.ngpio= 8;
- ofchip-gc.direction_input = mpc52xx_wkup_gpio_dir_in;
- ofchip-gc.direction_output = mpc52xx_wkup_gpio_dir_out;
- ofchip-gc.get = mpc52xx_wkup_gpio_get;
- ofchip-gc.set = mpc52xx_wkup_gpio_set;
+ gc-of_gpio_n_cells = 2;
+ gc-ngpio= 8;
+ gc-direction_input = mpc52xx_wkup_gpio_dir_in;
+ gc-direction_output = mpc52xx_wkup_gpio_dir_out;
+ gc-get = mpc52xx_wkup_gpio_get;
+ gc-set =
[PATCH v2 4/5] of/gpio: add default of_xlate function if device has a node pointer
From: Anton Vorontsov avoront...@ru.mvista.com Implement generic OF gpio hooks and thus make device-enabled GPIO chips (i.e. the ones that have gpio_chip-dev specified) automatically attach to the OpenFirmware subsystem. Which means that now we can handle I2C and SPI GPIO chips almost* transparently. * Almost because some chips still require platform data, and for these chips OF-glue is still needed, though with this change the glue will be much smaller. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Signed-off-by: Grant Likely grant.lik...@secretlab.ca Cc: David Brownell dbrown...@users.sourceforge.net Cc: Bill Gatliff b...@billgatliff.com Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Jean Delvare kh...@linux-fr.org Cc: Andrew Morton a...@linux-foundation.org CC: linux-ker...@vger.kernel.org CC: devicetree-disc...@lists.ozlabs.org --- arch/powerpc/platforms/52xx/mpc52xx_gpio.c |2 - arch/powerpc/platforms/52xx/mpc52xx_gpt.c |3 -- arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c |2 - arch/powerpc/sysdev/cpm1.c |2 - arch/powerpc/sysdev/cpm_common.c |1 - arch/powerpc/sysdev/mpc8xxx_gpio.c |1 - arch/powerpc/sysdev/ppc4xx_gpio.c |1 - arch/powerpc/sysdev/qe_lib/gpio.c |1 - arch/powerpc/sysdev/simple_gpio.c |1 - drivers/gpio/gpiolib.c |5 drivers/gpio/xilinx_gpio.c |1 - drivers/of/gpio.c | 33 +--- include/linux/of_gpio.h|7 - 13 files changed, 34 insertions(+), 26 deletions(-) diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c index fd0912e..0855e80 100644 --- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c @@ -161,7 +161,6 @@ static int __devinit mpc52xx_wkup_gpiochip_probe(struct of_device *ofdev, gc = chip-mmchip.gc; - gc-of_gpio_n_cells = 2; gc-ngpio= 8; gc-direction_input = mpc52xx_wkup_gpio_dir_in; gc-direction_output = mpc52xx_wkup_gpio_dir_out; @@ -325,7 +324,6 @@ static int __devinit mpc52xx_simple_gpiochip_probe(struct of_device *ofdev, gc = chip-mmchip.gc; - gc-of_gpio_n_cells = 2; gc-ngpio= 32; gc-direction_input = mpc52xx_simple_gpio_dir_in; gc-direction_output = mpc52xx_simple_gpio_dir_out; diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c index 6e82bd2..5d7d607 100644 --- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c @@ -348,10 +348,7 @@ mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node) gpt-gc.get = mpc52xx_gpt_gpio_get; gpt-gc.set = mpc52xx_gpt_gpio_set; gpt-gc.base = -1; - gpt-gc.of_gpio_n_cells = 2; - gpt-gc.of_xlate = of_gpio_simple_xlate; gpt-gc.of_node = node; - of_node_get(node); /* Setup external pin in GPIO mode */ clrsetbits_be32(gpt-regs-mode, MPC52xx_GPT_MODE_MS_MASK, diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c index f0dbace..59b0ed1 100644 --- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c +++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c @@ -90,8 +90,6 @@ static int mcu_gpiochip_add(struct mcu *mcu) gc-base = -1; gc-set = mcu_gpio_set; gc-direction_output = mcu_gpio_dir_out; - gc-of_gpio_n_cells = 2; - gc-of_xlate = of_gpio_simple_xlate; gc-of_node = np; return gpiochip_add(gc); diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c index d5cf7d4..0085212 100644 --- a/arch/powerpc/sysdev/cpm1.c +++ b/arch/powerpc/sysdev/cpm1.c @@ -633,7 +633,6 @@ int cpm1_gpiochip_add16(struct device_node *np) gc = mm_gc-gc; mm_gc-save_regs = cpm1_gpio16_save_regs; - gc-of_gpio_n_cells = 2; gc-ngpio = 16; gc-direction_input = cpm1_gpio16_dir_in; gc-direction_output = cpm1_gpio16_dir_out; @@ -755,7 +754,6 @@ int cpm1_gpiochip_add32(struct device_node *np) gc = mm_gc-gc; mm_gc-save_regs = cpm1_gpio32_save_regs; - gc-of_gpio_n_cells = 2; gc-ngpio = 32; gc-direction_input = cpm1_gpio32_dir_in; gc-direction_output = cpm1_gpio32_dir_out; diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c index 67e9b47..2b69aa0 100644 --- a/arch/powerpc/sysdev/cpm_common.c +++ b/arch/powerpc/sysdev/cpm_common.c @@ -337,7 +337,6 @@ int cpm2_gpiochip_add32(struct device_node *np) gc = mm_gc-gc; mm_gc-save_regs = cpm2_gpio32_save_regs; - gc-of_gpio_n_cells = 2; gc-ngpio = 32;
[PATCH v2 3/5] of/gpio: stop using device_node data pointer to find gpio_chip
Currently the kernel uses the struct device_node.data pointer to resolve
a struct gpio_chip pointer from a device tree node. However, the .data
member doesn't provide any type checking and there aren't any rules
enforced on what it should be used for. There's no guarantee that the
data stored in it actually points to an gpio_chip pointer.
Instead of relying on the .data pointer, this patch modifies the code
to add a lookup function which scans through the registered gpio_chips
and returns the gpio_chip that has a pointer to the specified
device_node.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
CC: Andrew Morton a...@linux-foundation.org
CC: Anton Vorontsov avoront...@ru.mvista.com
CC: Grant Likely grant.lik...@secretlab.ca
CC: David Brownell dbrown...@users.sourceforge.net
CC: Bill Gatliff b...@billgatliff.com
CC: Dmitry Eremin-Solenikov dbarysh...@gmail.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Jean Delvare kh...@linux-fr.org
CC: linux-ker...@vger.kernel.org
CC: devicetree-disc...@lists.ozlabs.org
---
arch/microblaze/kernel/reset.c |2 +-
arch/powerpc/platforms/52xx/mpc52xx_gpt.c |1 +
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 23 ++---
arch/powerpc/sysdev/qe_lib/gpio.c |2 +-
drivers/gpio/gpiolib.c | 32
drivers/of/gpio.c | 15 +--
include/asm-generic/gpio.h |3 ++
include/linux/of_gpio.h|3 ++
8 files changed, 56 insertions(+), 25 deletions(-)
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index 5476d3c..bd8ccab 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -39,7 +39,7 @@ static int of_reset_gpio_handle(void)
goto err0;
}
- gc = gpio-data;
+ gc = of_node_to_gpiochip(gpio);
if (!gc) {
pr_debug(%s: gpio controller %s isn't registered\n,
root-full_name, gpio-full_name);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 3f2ee47..6e82bd2 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -350,6 +350,7 @@ mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *gpt, struct
device_node *node)
gpt-gc.base = -1;
gpt-gc.of_gpio_n_cells = 2;
gpt-gc.of_xlate = of_gpio_simple_xlate;
+ gpt-gc.of_node = node;
of_node_get(node);
/* Setup external pin in GPIO mode */
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index e49f4bd..f0dbace 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -35,7 +35,6 @@
struct mcu {
struct mutex lock;
- struct device_node *np;
struct i2c_client *client;
struct gpio_chip gc;
u8 reg_ctrl;
@@ -79,7 +78,6 @@ static int mcu_gpiochip_add(struct mcu *mcu)
{
struct device_node *np;
struct gpio_chip *gc = mcu-gc;
- int ret;
np = of_find_compatible_node(NULL, NULL, fsl,mcu-mpc8349emitx);
if (!np)
@@ -94,29 +92,14 @@ static int mcu_gpiochip_add(struct mcu *mcu)
gc-direction_output = mcu_gpio_dir_out;
gc-of_gpio_n_cells = 2;
gc-of_xlate = of_gpio_simple_xlate;
+ gc-of_node = np;
- mcu-np = np;
-
- /*
-* We don't want to lose the node, its -data and -full_name...
-* So, if succeeded, we don't put the node here.
-*/
- ret = gpiochip_add(gc);
- if (ret)
- of_node_put(np);
- return ret;
+ return gpiochip_add(gc);
}
static int mcu_gpiochip_remove(struct mcu *mcu)
{
- int ret;
-
- ret = gpiochip_remove(mcu-gc);
- if (ret)
- return ret;
- of_node_put(mcu-np);
-
- return 0;
+ return gpiochip_remove(mcu-gc);
}
static int __devinit mcu_probe(struct i2c_client *client,
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
b/arch/powerpc/sysdev/qe_lib/gpio.c
index 194478c..32e9440 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -167,7 +167,7 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
goto err1;
}
- gc = gpio_np-data;
+ gc = of_node_to_gpiochip(gpio_np);
if (!gc) {
pr_debug(%s: gpio controller %s isn't registered\n,
np-full_name, gpio_np-full_name);
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 713ca0e..73fd328 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1153,6 +1153,38 @@ int gpiochip_remove(struct gpio_chip *chip)
}
EXPORT_SYMBOL_GPL(gpiochip_remove);
+/**
+ * gpiochip_find() - iterator for locating a specific
[PATCH v2 5/5] of/device: Add OF style matching helper function
Add of_driver_match_device() helper function. This function can be used
by bus types to determine if a driver works with a device when using OF
style matching. If CONFIG_OF is unselected, then it is a nop.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
CC: Greg Kroah-Hartman gre...@suse.de
CC: Michal Simek mon...@monstr.eu
CC: Grant Likely grant.lik...@secretlab.ca
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Stephen Rothwell s...@canb.auug.org.au
CC: linux-ker...@vger.kernel.org
CC: microblaze-ucli...@itee.uq.edu.au
CC: linuxppc-...@ozlabs.org
CC: devicetree-disc...@lists.ozlabs.org
---
drivers/of/device.c |2 +-
include/linux/of_device.h | 19 +++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index c2a98f5..5282a20 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -20,7 +20,7 @@
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
- if (!dev-of_node)
+ if ((!matches) || (!dev-of_node))
return NULL;
return of_match_node(matches, dev-of_node);
}
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 238e92e..91d75fb 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -30,6 +30,17 @@
extern const struct of_device_id *of_match_device(
const struct of_device_id *matches, const struct device *dev);
+/**
+ * of_driver_match_device - Tell if a driver's of_match_table matches a device.
+ * @drv: the device_driver structure to test
+ * @dev: the device structure to match against
+ */
+static inline int of_driver_match_device(const struct device *dev,
+const struct device_driver *drv)
+{
+ return of_match_device(drv-of_match_table, dev) != NULL;
+}
+
extern struct of_device *of_dev_get(struct of_device *dev);
extern void of_dev_put(struct of_device *dev);
@@ -48,6 +59,14 @@ extern ssize_t of_device_get_modalias(struct device *dev,
extern int of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
+#else /* CONFIG_OF_DEVICE */
+
+static inline int of_driver_match_device(struct device *dev,
+struct device_driver *drv)
+{
+ return 0;
+}
+
#endif /* CONFIG_OF_DEVICE */
#endif /* _LINUX_OF_DEVICE_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Port Linux to ML510
Hello, I am trying to port Linux to PowerPC on the ML510 Xilinx board. I am using EDK 10.1.3 to build the hardware and also device tree generator and the linux kernel from xilinx git. I followed the tutorial from http://xilinx.wikidot.com/powerpc-linux but I have no output. I have attached my .mhs file and the .dts. Any ideas what may cause this problem because I did the same thing with ML507 and it was working perfectly? Thanks in advance,Kostas _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969 system.mhs Description: Binary data xilinx.dts Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
