Re: MPC8349E's DMA controller like ISA controller but with more feature?
Thank Scott and Timur! Scott Wood wrote: Timur Tabi (CCed) has written an audio driver that does something very similar; he could probably tell you more about how to do that (this is why such discussions should be kept on the mailing list rather than taken to private e-mail). The code in drivers/dma cannot be used to send a buffer of data to a single I/O port. That code is just an elaborate version of memcpy that uses the DMA engine to copy data in the background. Thanks for your explaination! So if I want to transfer a buffer of data from a single I/O port, will not DMA framework also be able ? Have I to write aother driver? If you want to transfer a buffer to a single I/O port, you will need to write your own DMA driver, similar to what I've done in sound/soc/fsl/fsl_dma.c. This is not trivial. You will need to understand the DMA hardware programming model to determine whether you can use direct mode or if you need to create link descriptors. Actually, I don't want write all because there are serveral DMA code at hand. I only want to use a framework instead of re-writing. And I afraid that I can not write code which assure sharing DMA channels. Regards! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: general SPI question (WAS: [PATCH v6] spi: Add PPC4xx SPI driver)
On Thursday 23 April 2009, Arnav Das wrote: i am a newbie Lesson #1: make sure your Subject: lines match the message topic (I did a partial repair) and don't post to the wrong list (e.g. PPC lists for OMAP questions). and am doing a project on beagle board(running omap3530). i am interfacing an adc(ads7886) to the beagleboard via spi. need to know how the spi works Read the ads7886 data sheet, in this case. It uses a subset of SPI ... no input commands, just a 12-bit sample returned each time chipselect pulses. and how a module can access the spi registers of the omap. if someones already made an adc driver can they mail me? Use drivers/spi/omap2_mcspi.c on OMAP3 boards, at least to start with. If you want streaming conversions you may want to use different modes than are currently supported by that driver. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Enable CPU feature sections for inline asm
From: Milton Miller milt...@bga.com powerpc: Enable CPU feature sections for inline asm This adds the ability to do CPU feature sections for inline asm. Signed-off-by: Milton Miller milt...@bga.com Signed-off-by: Michael Neuling mi...@neuling.org --- arch/powerpc/include/asm/feature-fixups.h | 25 - 1 file changed, 20 insertions(+), 5 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/include/asm/feature-fixups.h === --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/feature-fixups.h +++ linux-2.6-ozlabs/arch/powerpc/include/asm/feature-fixups.h @@ -8,8 +8,6 @@ * 2 of the License, or (at your option) any later version. */ -#ifdef __ASSEMBLY__ - /* * Feature section common macros * @@ -23,10 +21,12 @@ /* 64 bits kernel, 32 bits code (ie. vdso32) */ #define FTR_ENTRY_LONG .llong #define FTR_ENTRY_OFFSET .long 0x; .long +#elif defined(CONFIG_PPC64) +#define FTR_ENTRY_LONG .llong +#define FTR_ENTRY_OFFSET .llong #else -/* 64 bit kernel 64 bit code, or 32 bit kernel 32 bit code */ -#define FTR_ENTRY_LONG PPC_LONG -#define FTR_ENTRY_OFFSET PPC_LONG +#define FTR_ENTRY_LONG .long +#define FTR_ENTRY_OFFSET .long #endif #define START_FTR_SECTION(label) label##1: @@ -141,6 +141,21 @@ label##5: \ #define ALT_FW_FTR_SECTION_END_IFCLR(msk) \ ALT_FW_FTR_SECTION_END_NESTED_IFCLR(msk, 97) +#ifndef __ASSEMBLY__ + +#define ASM_FTR_IF_X(string, estring, msk, val)\ + stringify_in_c(BEGIN_FTR_SECTION) \ + string ; \ + stringify_in_c(FTR_SECTION_ELSE)\ + estring ; \ + stringify_in_c(ALT_FTR_SECTION_END((msk), (val))) + +#define ASM_FTR_IFSET(string, estring, msk)\ + ASM_FTR_IF_X(string, estring, (msk), (msk)) + +#define ASM_FTR_IFCLR(string, estring, msk)\ + ASM_FTR_IF_X(string, estring, (msk), 0) + #endif /* __ASSEMBLY__ */ /* LWSYNC feature sections */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] powerpc: tlbie implementation PowerPC 2.06
These patches implement the new PowerPC 2.06 tlbie mnemonics Signed-off-by: Michael Neuling mi...@neuling.org --- It's friday afternoon I'm drinking beer, so odds are that these patches are complete crap. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
From: Milton Miller milt...@bga.com
This adds the PowerPC 2.06 tlbie mnemonics and keeps backwards
compatibilty for CPUs before 2.06.
Only useful for bare metal systems.
Signed-off-by: Milton Miller milt...@bga.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
As they say, better out than in
---
arch/powerpc/include/asm/cputable.h |3 ++-
arch/powerpc/mm/hash_native_64.c| 13 +++--
2 files changed, 13 insertions(+), 3 deletions(-)
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_SAOLONG_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_TLBIE_206 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_TLBIE_206)
#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/mm/hash_native_64.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_native_64.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c
@@ -38,6 +38,9 @@
static DEFINE_SPINLOCK(native_tlbie_lock);
+#define TLBIE(lp,a) \
+ stringify_in_c(.long 0x7c000264 | ((a) 11) | ((lp) 21))
+
static inline void __tlbie(unsigned long va, int psize, int ssize)
{
unsigned int penc;
@@ -49,14 +52,19 @@ static inline void __tlbie(unsigned long
case MMU_PAGE_4K:
va = ~0xffful;
va |= ssize 8;
- asm volatile(tlbie %0,0 : : r (va) : memory);
+ asm volatile(ASM_FTR_IFCLR(tlbie %0,0, TLBIE(%1,%0), %2)
+: : r (va), r(0), i (CPU_FTR_TLBIE_206)
+: memory);
break;
default:
penc = mmu_psize_defs[psize].penc;
va = ~((1ul mmu_psize_defs[psize].shift) - 1);
va |= penc 12;
va |= ssize 8;
- asm volatile(tlbie %0,1 : : r (va) : memory);
+ va |= 1; /* L */
+ asm volatile(ASM_FTR_IFCLR(tlbie %0,1, TLBIE(%1,%0), %2)
+: : r (va), r(0), i (CPU_FTR_TLBIE_206)
+: memory);
break;
}
}
@@ -80,6 +88,7 @@ static inline void __tlbiel(unsigned lon
va = ~((1ul mmu_psize_defs[psize].shift) - 1);
va |= penc 12;
va |= ssize 8;
+ va |= 1; /* L */
asm volatile(.long 0x7c000224 | (%0 11) | (1 21)
: : r(va) : memory);
break;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Next April 24 : BUG: lock held at task exit time!
While booting today's next tree on a powerpc box [ power 6 blade]
observed the following :
khelper used greatest stack depth: 10176 bytes left
=
[ BUG: lock held at task exit time! ]
-
khelper/21 is exiting with locks still held!
2 locks held by khelper/21:
#0: (rcu_read_lock){.+.+.+}, at: [c01382fc]
.check_unsafe_exec+0x44/0x148
#1: (rcu_read_lock){.+.+.+}, at: [c0138368]
.check_unsafe_exec+0xb0/0x148
stack backtrace:
Call Trace:
[c00044483cf0] [c0011a54] .show_stack+0x6c/0x16c (unreliable)
[c00044483da0] [c009ae14] .debug_check_no_locks_held+0x98/0xb4
[c00044483e20] [c0073b1c] .do_exit+0x758/0x7b0
[c00044483f00] [c00853d8] .call_usermodehelper+0x170/0x174
[c00044483f90] [c002bd8c] .kernel_thread+0x54/0x70
net_namespace: 2000 bytes
Complete dmesg attached. Let me know if you need any other info. I will
try yesterday's next
tree to check if this problem can be recreated.
Thanks
-Sachin
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
Using pSeries machine description
Page orders: linear mapping = 16, virtual = 16, io = 12, vmemmap = 24
Using 1TB segments
Found initrd at 0xc360:0xc3bebc74
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #2 SMP Fri Apr 24 11:30:39 IST 2009
-
ppc64_pft_size= 0x19
physicalMemorySize= 0x8000
htab_hash_mask= 0x3
-
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.30-rc3-next-20090424 (r...@mjs22lp5) (gcc version 4.3.2
[gcc-4_3-branch revision 141291] (SUSE Linux) ) #2 SMP Fri Apr 24 11:30:39 IST
2009
[boot]0012 Setup Arch
Node 0 Memory: 0x800-0x4600
Node 1 Memory: 0x0-0x800 0x4600-0x8000
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Using shared processor idle loop
Zone PFN ranges:
DMA 0x - 0x8000
Normal 0x8000 - 0x8000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
1: 0x - 0x0800
0: 0x0800 - 0x4600
1: 0x4600 - 0x8000
On node 0 totalpages: 15872
DMA zone: 22 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 15850 pages, LIFO batch:1
On node 1 totalpages: 16896
DMA zone: 44 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 16852 pages, LIFO batch:1
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 32702
Policy zone: DMA
Kernel command line: root=/dev/sda3 sysrq=1
Experimental hierarchical RCU implementation.
RCU-based detection of stalled CPUs is enabled.
Experimental hierarchical RCU init done.
NR_IRQS:512
[boot]0020 XICS Init
[boot]0021 XICS Done
pic: no ISA interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 512.00 MHz
time_init: processor frequency = 4005.00 MHz
clocksource: timebase mult[7d] shift[22] registered
clockevent: decrementer mult[8312] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] - real [hvc0]
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS:8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 16384
... CHAINHASH_SIZE: 8192
memory used by lock dependency info: 4607 kB
per task-struct memory footprint: 1920 bytes
allocated 1310720 bytes of page_cgroup
please try cgroup_disable=memory option if you don't want
freeing bootmem node 0
freeing bootmem node 1
Memory: 2035200k/2097152k available (8448k kernel code, 67136k reserved, 1216k
data, 8988k bss, 448k init)
ODEBUG: 0 of 0 active objects replaced
ODEBUG: selftest passed
Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976)
Security Framework initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
irq: irq 2 on host null mapped to virtual irq 16
Testing tracer nop: PASSED
clockevent: decrementer mult[8312] shift[16] cpu[1]
Processor 1 found.
clockevent: decrementer mult[8312] shift[16] cpu[2]
Processor 2 found.
clockevent: decrementer mult[8312] shift[16] cpu[3]
Processor 3 found.
Brought up 4 CPUs
Node 0
General SPI question
Hi, Thanks a lot and sorry for the mistakes. I have gone through the trm of the adc as well as the omap driver. my question is that i want to interact the adc to the board. now should i directly use the omap driver or should i mak one of my own. if i make one of my own then i would like to know how would the spi registers be changed by driver. should it include the omap2 driver or is the fuctionality provided directly when i include spi.h. another doubt: when and why is the spidev.c/h used? i am deeply grateful towards you for helping me out thanks Arnav On Fri, Apr 24, 2009 at 11:50 AM, David Brownell davi...@pacbell.netwrote: On Thursday 23 April 2009, Arnav Das wrote: i am a newbie Lesson #1: make sure your Subject: lines match the message topic (I did a partial repair) and don't post to the wrong list (e.g. PPC lists for OMAP questions). and am doing a project on beagle board(running omap3530). i am interfacing an adc(ads7886) to the beagleboard via spi. need to know how the spi works Read the ads7886 data sheet, in this case. It uses a subset of SPI ... no input commands, just a 12-bit sample returned each time chipselect pulses. and how a module can access the spi registers of the omap. if someones already made an adc driver can they mail me? Use drivers/spi/omap2_mcspi.c on OMAP3 boards, at least to start with. If you want streaming conversions you may want to use different modes than are currently supported by that driver. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next April 24 : BUG: lock held at task exit time!
Hi Sachin,
On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant sach...@in.ibm.com wrote:
While booting today's next tree on a powerpc box [ power 6 blade]
observed the following :
khelper used greatest stack depth: 10176 bytes left
=
[ BUG: lock held at task exit time! ]
-
khelper/21 is exiting with locks still held!
2 locks held by khelper/21:
#0: (rcu_read_lock){.+.+.+}, at: [c01382fc]
.check_unsafe_exec+0x44/0x148
#1: (rcu_read_lock){.+.+.+}, at: [c0138368]
.check_unsafe_exec+0xb0/0x148
stack backtrace:
Call Trace:
[c00044483cf0] [c0011a54] .show_stack+0x6c/0x16c (unreliable)
[c00044483da0] [c009ae14] .debug_check_no_locks_held+0x98/0xb4
[c00044483e20] [c0073b1c] .do_exit+0x758/0x7b0
[c00044483f00] [c00853d8] .call_usermodehelper+0x170/0x174
[c00044483f90] [c002bd8c] .kernel_thread+0x54/0x70
net_namespace: 2000 bytes
Complete dmesg attached. Let me know if you need any other info. I will
try yesterday's next
tree to check if this problem can be recreated.
Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
(check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/) which has a
typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
(pine.lnx.4.64.0904240526080.15...@blonde.anvils on LKML).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgp3bAUz1wXp2.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
On Tue, Apr 21, 2009 at 08:27:57PM -0700, Linus Torvalds wrote:
Another week, another -rc.
I'm seeing some tests with sysbench+postgres+large pages fail on ppc64
although a very clear pattern is not forming as to what exactly is
causing it. However, the libhugetlbfs regression tests (make make
func) are triggering the following oops when calling mlock() and so are
likely related.
[ cut here ]
kernel BUG at arch/powerpc/mm/pgtable.c:243!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in: dm_snapshot dm_mirror dm_region_hash dm_log qla2xxx
loop nfnetlink iptable_filter iptable_nat nf_nat ip_tables
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
xt_tcpudp xt_limit ipt_LOG xt_pkttype x_tables
NIP: c002becc LR: c002c02c CTR:
REGS: c000ea92b4c0 TRAP: 0700 Not tainted (2.6.30-rc3-autokern1)
MSR: 80029032 EE,ME,CE,IR,DR CR: 28000484 XER: 2020
TASK = c395b660[7611] 'mlock' THREAD: c000ea928000 CPU: 3
GPR00: 0001 c000ea92b740 c08ea170 c000ec7d4980
GPR04: 3f00 c001e2278cf8 00190393 0001
GPR08: f2bc 0113 c001e2278c81
GPR12: 44000482 c093b880 28004422
GPR16: c000ea92bbf0 c09f06f0 00190113 c000ec7d4980
GPR20: f2bc 3f00 c001e2278cf8
GPR24: c000eaa90bb0 c000eaa90bb0 c000ea928000
GPR28: f2bc 00190393 0001 c001e2278cf8
NIP [c002becc] .assert_pte_locked+0x54/0x8c
LR [c002c02c] .ptep_set_access_flags+0x50/0x8c
Call Trace:
[c000ea92b740] [c000eaa90bb0] 0xc000eaa90bb0 (unreliable)
[c000ea92b7d0] [c00ed1b0] .hugetlb_cow+0xd4/0x654
[c000ea92b900] [c00edbf0] .hugetlb_fault+0x4c0/0x708
[c000ea92b9f0] [c00ee890] .follow_hugetlb_page+0x174/0x364
[c000ea92bae0] [c00d8d30] .__get_user_pages+0x288/0x4c0
[c000ea92bbb0] [c00da10c] .make_pages_present+0xa0/0xe0
[c000ea92bc40] [c00db758] .mlock_fixup+0x90/0x228
[c000ea92bd00] [c00dbb38] .do_mlock+0xc4/0x128
[c000ea92bda0] [c00dbccc] .SyS_mlock+0xb0/0xec
[c000ea92be30] [c000852c] syscall_exit+0x0/0x40
Instruction dump:
0b00 78892662 79291f24 7d69582a 7d600074 7800d182 0b00 78895e62
79291f24 7d29582a 7d200074 7800d182 0b00 3c004000 3960
780007c6
---[ end trace 36a7faa04fa9452b ]---
This corresponds to
#ifdef CONFIG_DEBUG_VM
void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
if (mm == init_mm)
return;
pgd = mm-pgd + pgd_index(addr);
BUG_ON(pgd_none(*pgd));
pud = pud_offset(pgd, addr);
BUG_ON(pud_none(*pud));
pmd = pmd_offset(pud, addr);
BUG_ON(!pmd_present(*pmd)); - THIS LINE
BUG_ON(!spin_is_locked(pte_lockptr(mm, pmd)));
}
#endif /* CONFIG_DEBUG_VM */
This area was last changed by commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
in the 2.6.30-rc1 timeframe. I think there was another hugepage-related
problem with this patch but I can't remember what it was. Full dmesg is
dmesg
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24
Found initrd at 0xc330:0xc4b67000
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #1 SMP Fri Apr 24 09:08:10 UTC 2009
-
ppc64_pft_size= 0x1b
physicalMemorySize= 0x1e800
htab_hash_mask= 0xf
-
Initializing cgroup subsys cpuset
Linux version 2.6.30-rc3-autokern1 (r...@elm3a121) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #1 SMP Fri Apr 24 09:08:10 UTC 2009
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0xee00
Node 1 Memory: 0xee00-0x1e800
PCI host bridge /p...@8002001 ranges:
IO 0x03fe0010..0x03fe001f - 0x
MEM 0x04008000..0x0400bfff - 0xc000
PCI host bridge /p...@8002002 ranges:
IO 0x03fe0060..0x03fe006f - 0x
MEM 0x0401..0x04017fff - 0x8000
PCI host bridge /p...@8002003 ranges:
IO 0x03fe0030..0x03fe003f - 0x
MEM 0x0400c000..0x0400 - 0xc000
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using dedicated idle loop
Zone PFN ranges:
DMA 0x - 0x001e8000
Normal 0x001e8000 - 0x001e8000
Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
On Tuesday 21 April 2009, John Williams wrote: Some (most?) of the Xilinx drivers currently have this construct: #ifdef CONFIG_OF // probe using OF #else If there are multiple ways of detecting the device, then the driver should be compilable on any system that allows either one. At the very least, it should be restricted to CONFIG_HAS_IOMEM, which is probably required for any of these, but not provided on stuff like UML or s390. Drivers that use of_* functions unconditionally need to depend on CONFIG_OF. Also, some of the xilinx drivers apparantly use DCR, which in turn is only defined when you have CONFIG_PPC_DCR, and these have so far only been used on powerpc. If other architectures start using DCR (I hope that never happens), we will need a global CONFIG_DCR option. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [V5] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
On Friday 17 April 2009, John Linn wrote: Added support for the new xps tft controller. The new core has PLB interface support in addition to existing DCR interface. Removed platform device support as both MicroBlaze and PowerPC use device tree. I just said in another email thread that we would need a CONFIG_DCR option that DCR using drivers should depend on, if it ever happened outside of powerpc. Well, apparently this happened earlier than I expected. Converting the driver to use the generic DCR interface makes it possible to use in any system that provides this interface, including those that use a hard CPU core with xilinx_fb on an FPGA, so it makes sense to just change the dependency in Kconfig and provide CONFIG_DCR in microblaze (unconditionally) as well as in powerpc instead of the existing CONFIG_PPC_DCR. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next April 24 : BUG: lock held at task exit time!
On Fri, 24 Apr 2009, Stephen Rothwell wrote:
On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant sach...@in.ibm.com wrote:
While booting today's next tree on a powerpc box [ power 6 blade]
observed the following :
khelper used greatest stack depth: 10176 bytes left
=
[ BUG: lock held at task exit time! ]
-
khelper/21 is exiting with locks still held!
2 locks held by khelper/21:
#0: (rcu_read_lock){.+.+.+}, at: [c01382fc]
.check_unsafe_exec+0x44/0x148
#1: (rcu_read_lock){.+.+.+}, at: [c0138368]
.check_unsafe_exec+0xb0/0x148
stack backtrace:
Call Trace:
[c00044483cf0] [c0011a54] .show_stack+0x6c/0x16c (unreliable)
[c00044483da0] [c009ae14] .debug_check_no_locks_held+0x98/0xb4
[c00044483e20] [c0073b1c] .do_exit+0x758/0x7b0
[c00044483f00] [c00853d8] .call_usermodehelper+0x170/0x174
[c00044483f90] [c002bd8c] .kernel_thread+0x54/0x70
net_namespace: 2000 bytes
Complete dmesg attached. Let me know if you need any other info. I will
try yesterday's next
tree to check if this problem can be recreated.
Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8
(check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/) which has a
typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins
(pine.lnx.4.64.0904240526080.15...@blonde.anvils on LKML).
Indeed, thanks for the headsup Stephen. My own config gives, not
Sachin's message (or not still visibly on screen anyway), but an
outright panic. Shame that leaked out into the big world, we'd
all have preferred a quiet fixup! Here's a patch, which I'll
also send as reply to the relevant thread.
[PATCH] check_unsafe_exec: rcu_read_unlock
Fix typo in previous commit: second rcu_read_lock should be rcu_read_unlock.
Signed-off-by: Hugh Dickins h...@veritas.com
---
fs/exec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.30-rc3-next-20090424/fs/exec.c 2009-04-24 12:23:43.0 +0100
+++ linux/fs/exec.c 2009-04-24 12:26:10.0 +0100
@@ -1043,7 +1043,7 @@ int check_unsafe_exec(struct linux_binpr
if (t-fs == p-fs)
n_fs++;
}
- rcu_read_lock();
+ rcu_read_unlock();
if (p-fs-users n_fs) {
bprm-unsafe |= LSM_UNSAFE_SHARE;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
On Fri, Apr 17, 2009 at 08:36:00PM -0400, Sean MacLennan wrote: Any update on the status of this patch? This patch was acked by Jean. The patchwork entry is http://patchwork.ozlabs.org/patch/21576/ and the original patch message is below. Yeah, that's a bit annoying. A case of too many trees again. Ben, Do you want to take this through your tree or should I take it through the powerpc tree? I'll be up-front and say silence will translate to 'powerpc tree' josh Cheers, Sean On Mon, 2 Feb 2009 12:01:59 -0500 Sean MacLennan smaclen...@pikatech.com wrote: This is a trivial patch that does not need to be in 2.6.29. While tracking down an EEPROM problem, I found the messages confusing... it looked like the EEPROM was being started before the I2C driver! Here is an example: at24 0-0052: 512 byte 24c04 EEPROM (writable) ibm-iic ef600700.i2c: using standard (100 kHz) mode ad7414 0-004a: chip found It looks like the at24 starts first, then the i2c driver, then the ad7414. By moving the message to after the of scan, we always get the driver, then the devices. Cheers, Sean Print the i2c driver message before scanning for devices so that the logs show the driver, then the devices. Currently you can get device(s), driver, device(s). Signed-off-by: Sean MacLennan smaclen...@pikatech.com --- diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c index 88f0db7..7fc0729 100644 --- a/drivers/i2c/busses/i2c-ibm_iic.c +++ b/drivers/i2c/busses/i2c-ibm_iic.c @@ -756,12 +756,12 @@ static int __devinit iic_probe(struct of_device *ofdev, goto error_cleanup; } -/* Now register all the child nodes */ -of_register_i2c_devices(adap, np); - dev_info(ofdev-dev, using %s mode\n, dev-fast_mode ? fast (400 kHz) : standard (100 kHz)); +/* Now register all the child nodes */ +of_register_i2c_devices(adap, np); + return 0; error_cleanup: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'merge' branch of the 4xx tree
Hi Paul, Please pull the following two commits for 2.6.30. One is a trivial MAINTAINERS fix, the other fixes a bug that computes the memory size of some 4xx boards incorrectly. The following changes since commit 6329db8bd60fbc0832f30c350b0181b8d865573e: Bartlomiej Zolnierkiewicz (1): powerpc: Fix modular build of ide-pmac when mediabay is built in are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge Josh Boyer (1): maintainers: Fix PowerPC 4xx git tree Valentine Barshak (1): powerpc/44x: Correct memory size calculation for denali-based boards MAINTAINERS |2 +- arch/powerpc/boot/4xx.c | 56 --- 2 files changed, 44 insertions(+), 14 deletions(-) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next April 24 : BUG: lock held at task exit time!
On Fri, Apr 24, 2009 at 12:55:44PM +0100, Hugh Dickins wrote: Indeed, thanks for the headsup Stephen. My own config gives, not Sachin's message (or not still visibly on screen anyway), but an outright panic. Shame that leaked out into the big world, we'd all have preferred a quiet fixup! Here's a patch, which I'll also send as reply to the relevant thread. Applied, will fold on reorder (since Ingo is asking for what will amount to reorder anyway). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [MTD] ofpart: Partitions at same address cannot have the same name v3
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partit...@ff00 {
reg = 0x00 0x80 ;
label = Root File System;
};
partit...@ff80 {
reg = 0x80 0x1a ;
label = Bitstream;
};
...
f...@ff00 {
compatible = partition;
reg = 0x00 0x100 ;
label = Full FLASH;
};
Because two nodes of a device tree cannot have the same name, but all the
partitions must be named partition, this special partition is invalid.
This patch makes ofpart.c accept spetial partitions compatible with
partition but not named partition.
These spetial partitions are very useful for flashing the full firmware
of a device from linux
---
This v3 includes feedback from Scott Wood, Peter Korsgaard Benjamin Kril
v3: Use the compatible propierty
v2: buggy implementation, strlen-1 instead of strlen
v1: Just check the firt part of the name
drivers/mtd/ofpart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 3e164f0..59c1e4a 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,9 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, name, len);
- if (strcmp(partname, partition) != 0) {
+ if ((strcmp(partname, partition) != 0)
+ (of_device_is_compatible(pp, partition) != 1))
+ {
nr_parts--;
continue;
}
--
1.6.2.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Next April 24 : BUG: lock held at task exit time!
Hi Al, On Fri, 24 Apr 2009 15:04:45 +0100 Al Viro v...@zeniv.linux.org.uk wrote: Applied, will fold on reorder (since Ingo is asking for what will amount to reorder anyway). Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpUACwsb23z8.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: removing get_immrbase()??
We've run into plenty of situations where customers will update the kernel, but insist that U-Boot and the device tree remain unchanged. when? I'm not aware of any significant # of cases that customer is willing to update kernel not dts. Usually if they are willing to update kernel they tend to be willing to update everything. I recently fried a U-Boot flash on a machine at home when upgrading and the machine sits there and is dead of course. Luckily that machine doesn't have to be up 24x7, so I can wait until I have time to fix the situation ... and I can either pull the socketed flash or hook up a JTAG debugger. But Freescale or other eval(!) boards or isolated Power Architecture based home use machines like my fried one should not be a reference for this kind of discussion. I see a very common scenario with Telecom/Networking customers. They have a boot flash with firmware and basic startup/BIST SW which they do not really ever want to touch at all even if they should after it shipped. If a remote upgrade on just a few out of n installed systems fails, they can send technicians to Mars to pull the board(s), and service guarantees, and profit, are out the window then. That makes U-Boot and/or subsequent ultra-low-level startup/BIST SW from the same boot source *very* firm. If a device-tree is served from there for whichever reason, then you have a *very* firm device-tree, too. Then these customers either have a second flash with a filesystem or more volatile images in the sense that they see that other flash as upgradable (if they have to), or a physical link to some remote fs that serves them the kernel and application load. They still do not like upgrades too much as any upgrade can have service impact. But they do them when necessary because they know they have a way to revert to previous or fixed releases remotely as they can always depend on the original boot loader to be there. It would not be smart to prohibit any change ever, but we also shouldn't cause device-tree changes a lot just because we felt like it today. Both seems a bit extreme. There must be some middle ground, err'ing towards the conservative side. A change affecting lower levels than the kernel should be very well thought through, and if it is necessary, we should strive to keep compatibility to a level that makes sense and possibly eases a transition over some time. If a few clearly marked code lines (with a possibly marked planned max lifetime) ease compatibility and transition, they should be considered. Hope this helps Heinz ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8349E's DMA controller like ISA controller but with more feature?
lhthanh wrote: Thanks for your explaination! So if I want to transfer a buffer of data from a single I/O port, will not DMA framework also be able ? No. Have I to write aother driver? Yes. Actually, I don't want write all because there are serveral DMA code at hand. I only want to use a framework instead of re-writing. There is no framework for what you want to do. There is only one other driver that does what you want (sound/soc/fsl/fsl_dma.c), and that is a complicated driver that does many things besides transferring data to an I/O port. And I afraid that I can not write code which assure sharing DMA channels. Look at arch/powerpc/boot/dts/mpc8610_hpcd.dts. The DMA channels that are needed by the 8610 audio driver have a different 'compatible' property. This is how you prevent the generic DMA driver from using a channel that you want. I'm afraid that you're going to have to study the DMA programming model, and my device driver, and write a brand new driver from scratch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
where to simplify code using is_power_of_2() function
just an observation that you can aesthetically simplify some ppc
code using the boolean is_power_of_2() routine from
include/linux/log2.h if you were so inclined:
arch/powerpc/sysdev/ppc4xx_pci.c:171: if ((size (size - 1)) != 0 ||
arch/powerpc/mm/ppc_mmu_32.c:216: if (n_hpteg (n_hpteg - 1)) {
arch/powerpc/boot/cuboot-pq2.c:176: if (mem-size[1] (mem-size[1] - 1))
arch/powerpc/boot/cuboot-pq2.c:178: if (io-size[1] (io-size[1] - 1))
arch/powerpc/lib/rheap.c:258: if ((alignment (alignment - 1)) != 0)
arch/powerpc/lib/rheap.c:307: if ((alignment (alignment - 1)) != 0)
arch/powerpc/lib/rheap.c:450: if (size = 0 || (alignment (alignment - 1))
!= 0)
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
On Fri, 2009-04-24 at 10:51 +0100, Mel Gorman wrote:
On Tue, Apr 21, 2009 at 08:27:57PM -0700, Linus Torvalds wrote:
Another week, another -rc.
I'm seeing some tests with sysbench+postgres+large pages fail on ppc64
although a very clear pattern is not forming as to what exactly is
causing it. However, the libhugetlbfs regression tests (make make
func) are triggering the following oops when calling mlock() and so are
likely related.
[ cut here ]
kernel BUG at arch/powerpc/mm/pgtable.c:243!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in: dm_snapshot dm_mirror dm_region_hash dm_log qla2xxx
loop nfnetlink iptable_filter iptable_nat nf_nat ip_tables
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
xt_tcpudp xt_limit ipt_LOG xt_pkttype x_tables
NIP: c002becc LR: c002c02c CTR:
REGS: c000ea92b4c0 TRAP: 0700 Not tainted (2.6.30-rc3-autokern1)
MSR: 80029032 EE,ME,CE,IR,DR CR: 28000484 XER: 2020
TASK = c395b660[7611] 'mlock' THREAD: c000ea928000 CPU: 3
GPR00: 0001 c000ea92b740 c08ea170 c000ec7d4980
GPR04: 3f00 c001e2278cf8 00190393 0001
GPR08: f2bc 0113 c001e2278c81
GPR12: 44000482 c093b880 28004422
GPR16: c000ea92bbf0 c09f06f0 00190113 c000ec7d4980
GPR20: f2bc 3f00 c001e2278cf8
GPR24: c000eaa90bb0 c000eaa90bb0 c000ea928000
GPR28: f2bc 00190393 0001 c001e2278cf8
NIP [c002becc] .assert_pte_locked+0x54/0x8c
LR [c002c02c] .ptep_set_access_flags+0x50/0x8c
Call Trace:
[c000ea92b740] [c000eaa90bb0] 0xc000eaa90bb0 (unreliable)
[c000ea92b7d0] [c00ed1b0] .hugetlb_cow+0xd4/0x654
[c000ea92b900] [c00edbf0] .hugetlb_fault+0x4c0/0x708
[c000ea92b9f0] [c00ee890] .follow_hugetlb_page+0x174/0x364
[c000ea92bae0] [c00d8d30] .__get_user_pages+0x288/0x4c0
[c000ea92bbb0] [c00da10c] .make_pages_present+0xa0/0xe0
[c000ea92bc40] [c00db758] .mlock_fixup+0x90/0x228
[c000ea92bd00] [c00dbb38] .do_mlock+0xc4/0x128
[c000ea92bda0] [c00dbccc] .SyS_mlock+0xb0/0xec
[c000ea92be30] [c000852c] syscall_exit+0x0/0x40
Instruction dump:
0b00 78892662 79291f24 7d69582a 7d600074 7800d182 0b00 78895e62
79291f24 7d29582a 7d200074 7800d182 0b00 3c004000 3960
780007c6
---[ end trace 36a7faa04fa9452b ]---
This corresponds to
#ifdef CONFIG_DEBUG_VM
void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
if (mm == init_mm)
return;
pgd = mm-pgd + pgd_index(addr);
BUG_ON(pgd_none(*pgd));
pud = pud_offset(pgd, addr);
BUG_ON(pud_none(*pud));
pmd = pmd_offset(pud, addr);
BUG_ON(!pmd_present(*pmd)); - THIS LINE
BUG_ON(!spin_is_locked(pte_lockptr(mm, pmd)));
}
#endif /* CONFIG_DEBUG_VM */
This area was last changed by commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
in the 2.6.30-rc1 timeframe. I think there was another hugepage-related
problem with this patch but I can't remember what it was.
It broke modules, but I don't remember anything hugepage related.
So the code changed from:
-#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
-({\
- int __changed = !pte_same(*(__ptep), __entry); \
- if (__changed) { \
- __ptep_set_access_flags(__ptep, __entry, __dirty); \
- flush_tlb_page_nohash(__vma, __address); \
- } \
- __changed; \
-})
to:
+int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
+ pte_t *ptep, pte_t entry, int dirty)
+{
+ int changed;
+ if (!dirty pte_need_exec_flush(entry, 0))
+ entry = do_dcache_icache_coherency(entry);
+ changed = !pte_same(*(ptep), entry);
+ if (changed) {
+ assert_pte_locked(vma-vm_mm, address);
+ __ptep_set_access_flags(ptep, entry);
+ flush_tlb_page_nohash(vma, address);
+ }
+ return changed;
+}
So the call to assert_pte_locked() is new. And it's never going to work
for huge pages, the page table structure is different right? Notice
pte_update() checks (arch/powerpc/include/asm/pgtable-ppc64.h):
198
Re: Enable Serial Management Controller (SMC) in MPC8265
On Thu, Apr 23, 2009 at 07:50:25PM -0400, Andres F Marquez wrote:
I am working with a MPC8265 processor for which I am compiling a
Kernel using LTIB.
Please contact Freescale support for issues with BSPs. Around here
you'll be told to upgrade to the latest upstream kernel. :-)
I enabled SCC1 (for the console) and SMC2 through the Kernel
(2.6.25) configuration tool using LTIB. I am able to run my system and
execute minicom to try to configure the needed serial port. I have not
been able to find the tty port that refers to either one of the two SMC
ports.
All CPM serial ports (whether SCC or SMC) will be /dev/ttyCPMn.
I have tried all the tty's that I get when I do ls /dev/tty* but
none of them seem to work. Below, I provide the list of tty's that I am
getting. ttyCPM0 is being used for the console. ttyCPM1 is the only one
that I am allowed to configure through minicom (for the rest it says
device not found).
Not allowed? Don't you have root access to your board?
After doing some research online, I added an entry in my
mpc8272ads.dts file for the smc serial controller. Below, I provide the
entries for the serial ports (one SCC1 and one SMC2):
ser...@11a00 {
device_type = serial;
compatible = fsl,mpc8280-scc-uart,
fsl,cpm2-scc-uart;
reg = 11a00 20 8000 100;
interrupts = 28 8;
interrupt-parent = PIC;
fsl,cpm-brg = 2;
fsl,cpm-command = 0080;
};
ser...@11a92 {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a92 20 88fc 2;
interrupts = 5 8;
interrupt-parent = PIC;
fsl,cpm-brg = 2;
fsl,cpm-command = 2120;
};
Do you really have both ports on the same BRG?
Change 11a92 to 11a90 -- it's the address of the register block, not the
first register within the block.
You should also change 8280 to 8265, though nothing currently cares.
Finally, I think 2.6.25 is too old to support automatic allocation of SMC
parameter RAM. Unless they've backported something in the BSP, you'll
have to manually allocate some space, remove that chunk from the muram
node, program SMC2_BASE yourself, and put the address of the actual
parameter RAM in the device tree. Or, upgrade to the latest upstream
kernel, or complain to Freescale sales and/or support that the BSP kernel
is too old for your desired use.
For some reason in uboot, it seems like the configurations for SCC1 and
SMC2 are exclusive. They depend on where the console is configured
(SCC1 or SMC2). Either one can be configured, but not both at the same
time (at least based on uboot configuration definitions. They are
within if's and elif's...). As I said before, both of them are able to
run the console.
I don't see any obvious pin conflict between SCC1 and SMC2. It's
probably just a u-boot limitation -- but make sure that the pins get set
up for SMC2 even if u-boot doesn't use it.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
help with inline assembly code?
Hi,
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never be inlined, it works fine.
First, here's the code:
void alter_opcode(unsigned long *addr, unsigned long opcode)
{
asm volatile(
stw%1,0(%0) \n\t
dcbf 0,%0 \n\t
sync \n\t
icbi 0,%0, \n\t
isync \n\t
:: r (addr), r (opcode): memory);
}
The symptom of the problem is a segfault on the stw instruction. I've
verified that the address it's trying to write to is the expected
address, and that the opcode being written is the expected opcode.
I assume I've mixed up the registers or constraints or
something...anyone want to take a crack at it?
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Chris Friesen wrote:
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never be inlined, it works fine.
First, here's the code:
void alter_opcode(unsigned long *addr, unsigned long opcode)
{
asm volatile(
stw%1,0(%0)\n\t
dcbf 0,%0\n\t
sync\n\t
icbi 0,%0,\n\t
isync\n\t
:: r (addr), r (opcode): memory);
}
The symptom of the problem is a segfault on the stw instruction. I've
verified that the address it's trying to write to is the expected
address,
Verified by looking at the address in addr, or by looking at the
reported faulting address?
and that the opcode being written is the expected opcode.
I assume I've mixed up the registers or constraints or
something...anyone want to take a crack at it?
Is the compiler assigning r0 to addr? That will be treated as a literal
zero instead. Try changing r (addr) to b (addr), or use stwx.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Scott Wood wrote:
Chris Friesen wrote:
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never be inlined, it works fine.
First, here's the code:
void alter_opcode(unsigned long *addr, unsigned long opcode)
{
asm volatile(
stw%1,0(%0)\n\t
dcbf 0,%0\n\t
sync\n\t
icbi 0,%0,\n\t
isync\n\t
:: r (addr), r (opcode): memory);
}
The symptom of the problem is a segfault on the stw instruction. I've
verified that the address it's trying to write to is the expected
address,
Verified by looking at the address in addr, or by looking at the
reported faulting address?
Verified by running it in userspace under gdb, then looking at the
registers listed in the disassembly and comparing it to the process maps.
and that the opcode being written is the expected opcode.
I assume I've mixed up the registers or constraints or
something...anyone want to take a crack at it?
Is the compiler assigning r0 to addr? That will be treated as a literal
zero instead. Try changing r (addr) to b (addr), or use stwx.
Bingo! Is there a constraint to tell the compiler to not use r0 for addr?
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Chris Friesen wrote: Scott Wood wrote: Is the compiler assigning r0 to addr? That will be treated as a literal zero instead. Try changing r (addr) to b (addr), or use stwx. Bingo! Is there a constraint to tell the compiler to not use r0 for addr? Yes, b. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with inline assembly code?
Scott Wood wrote: Chris Friesen wrote: Scott Wood wrote: Is the compiler assigning r0 to addr? That will be treated as a literal zero instead. Try changing r (addr) to b (addr), or use stwx. Bingo! Is there a constraint to tell the compiler to not use r0 for addr? Yes, b. Doh. Sorry, apparently I can't read today. Both of those fixes seem to work. Much appreciated. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsldma: use PCI Read Multiple command
By default, the Freescale 83xx DMA controller uses the PCI Read Line command when reading data over the PCI bus. Setting the controller to use the PCI Read Multiple command instead allows the controller to read much larger bursts of data, which provides a drastic speed increase. The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI bridge was between the devices trying to communicate. A simple test driver showed an increase from 4MB/sec to 116MB/sec when performing DMA over the PCI bus. Using DMA to transfer between blocks of local SDRAM showed no change in performance with this patch. The dmatest driver was also used to verify the correctness of the transfers, and showed no errors. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- drivers/dma/fsldma.c |5 +++-- drivers/dma/fsldma.h |1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index da8a8ed..638d00e 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -49,9 +49,10 @@ static void dma_init(struct fsl_dma_chan *fsl_chan) case FSL_DMA_IP_83XX: /* Set the channel to below modes: * EOTIE - End-of-transfer interrupt enable +* PRC_RM - PCI read multiple */ - DMA_OUT(fsl_chan, fsl_chan-reg_base-mr, FSL_DMA_MR_EOTIE, - 32); + DMA_OUT(fsl_chan, fsl_chan-reg_base-mr, FSL_DMA_MR_EOTIE + | FSL_DMA_MR_PRC_RM, 32); break; } diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h index 4f21a51..dc7f268 100644 --- a/drivers/dma/fsldma.h +++ b/drivers/dma/fsldma.h @@ -38,6 +38,7 @@ /* Special MR definition for MPC8349 */ #define FSL_DMA_MR_EOTIE 0x0080 +#define FSL_DMA_MR_PRC_RM 0x0800 #define FSL_DMA_SR_CH 0x0020 #define FSL_DMA_SR_PE 0x0010 -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Regarding the linkstation defconfig
On Fri, 24 Apr 2009, Rogério Brito wrote: Hi, Guennadi, Kumar Co. Guennadi, since you seem to be the one responsible for the linkstation/kurobox in the kernel, That's not howI interpret my role in linkstation development / support. I would like to ask you a few things that I couldn't quite understand. Please, forgive my ignorance here while I ask you some things: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 01. why is anticipatory the default scheduler for linkstations when CFQ is the default scheduler for the rest of the kernel? 02. since kuroboxes/linkstations are meant to store files, is there any reason why they don't have support for large blk devs enabled by default? 03. why is CONFIG_MIGRATION enabled in such low memory devices? 04. why is CONFIG_BLK_DEV_RAM enabled by default? 05. why is SCSI_LOWLEVEL enabled, if no device under that tree is used? 06. idem for CONFIG_NETDEV_1. 07. idem for CONFIG_WIRELESS. 08. idem for CONFIG_HWMON. 09. idem for CONFIG_CRYPTO_HW. 10. any reason why CONFIG_VIDEO_OUTPUT_CONTROL is configured as a module? 11. any reason why CIFS is not configured with extended attributes, while both ext3 and nfs are? 12. wouldn't it be a good thing to enable CONFIG_PRINTK_TIME? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - As I already replied to you earlier, I am not particularly interested in fine-tuning and optimisation of defconfigs. IMHO *_defconfigs are only examples of board configuration, that are known to build and work. The rest is up to the user / packager. Perhaps similar remarks would apply to the other device that you maintain? I forgot its name. Again, please, forgive my ignorance here regarding the questions above. I'm really looking for some clarification and to get things in shape both on my systems and in the default kernel configuration, in general. Feel free to submit patches with reasoning to the powerpc ML and respective maintainer as per MAINTAINERS file. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Regarding the linkstation defconfig
Dear Guennadi, and Kumar.
On Apr 24 2009, Guennadi Liakhovetski wrote:
On Fri, 24 Apr 2009, Rogério Brito wrote:
Guennadi, since you seem to be the one responsible for the
linkstation/kurobox in the kernel,
That's not howI interpret my role in linkstation development /
support.
Sorry. I thought that you were. I have, nonetheless, interest in helping
and understanding more about the platform.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
01. why is anticipatory the default scheduler for linkstations when CFQ
is the default scheduler for the rest of the kernel?
(...)
12. wouldn't it be a good thing to enable CONFIG_PRINTK_TIME?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
As I already replied to you earlier, I am not particularly interested in
fine-tuning and optimisation of defconfigs. IMHO *_defconfigs are only
examples of board configuration, that are known to build and work. The
rest is up to the user / packager.
IMVHO, defconfigs should be examples of board configuration, known to
build and work (like you said) *and* be, in a way, exemplary to the
user/packager.
Again, please, forgive my ignorance here regarding the questions above.
I'm really looking for some clarification and to get things in shape
both on my systems and in the default kernel configuration, in general.
Feel free to submit patches with reasoning to the powerpc ML and
respective maintainer as per MAINTAINERS file.
I'm doing that as a reply to this message.
Thanks for your guiding, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: minimizing the configuration of linkstation_defconfig
This patch addresses the following issues: 01. makes CFQ the default scheduler, to be in line with the rest of the kernel. 02. since linkstations are meant to store files, enable large blk devices. 03. disable CONFIG_MIGRATION in in such low memory devices. 04. disable CONFIG_BLK_DEV_RAM. 05. disable CONFIG_SCSI_LOWLEVEL, as no device under that tree is used. 06. idem for CONFIG_NETDEV_1. 07. idem for CONFIG_WIRELESS. 08. idem for CONFIG_HWMON. 09. idem for CONFIG_CRYPTO_HW. 10. disable CONFIG_VIDEO_OUTPUT_CONTROL. 11. keep consistency and disable extended attributes in CIFS, ext3, and NFS. 12. enable CONFIG_PRINTK_TIME. Signed-off-by: Rogério Brito rbr...@ime.usp.br --- Dear Kumar, please, apply this one. I have another patch regarding one regression regarding MTD PHYSMAP_COMPAT that I plan to send on top of this one. Thanks. --- a/arch/powerpc/configs/linkstation_defconfig2009-04-22 21:43:45.0 -0300 +++ b/arch/powerpc/configs/linkstation_defconfig2009-04-24 18:07:12.0 -0300 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.29-rc6 -# Fri Mar 6 00:07:38 2009 +# Linux kernel version: 2.6.30-rc3 +# Fri Apr 24 18:07:12 2009 # # CONFIG_PPC64 is not set @@ -14,6 +14,7 @@ CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set +CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y @@ -54,6 +55,7 @@ CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # @@ -68,6 +70,7 @@ CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set @@ -100,21 +103,24 @@ CONFIG_NAMESPACES=y # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y -# CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y -CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y @@ -124,10 +130,12 @@ CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y +# CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y @@ -135,6 +143,7 @@ CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y +# CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y @@ -146,8 +155,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set +CONFIG_LBD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -158,18 +166,16 @@ CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set -# CONFIG_DEFAULT_CFQ is not set +CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_FREEZER is not set # # Platform support # -CONFIG_PPC_MULTIPLATFORM=y -CONFIG_CLASSIC32=y # CONFIG_PPC_CHRP is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set @@ -191,6 +197,8 @@ CONFIG_LINKSTATION=y CONFIG_MPC10X_BRIDGE=y CONFIG_MPC10X_OPENPIC=y # CONFIG_MPC10X_STORE_GATHERING is not set +# CONFIG_AMIGAONE is not set +CONFIG_PPC_OF_BOOT_TRAMPOLINE=y # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set @@ -244,15 +252,18 @@ CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 -CONFIG_MIGRATION=y +# CONFIG_MIGRATION is not set # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_UNEVICTABLE_LRU=y +CONFIG_HAVE_MLOCK=y +CONFIG_HAVE_MLOCKED_PAGE_BIT=y CONFIG_PPC_4K_PAGES=y # CONFIG_PPC_16K_PAGES is not set # CONFIG_PPC_64K_PAGES is not set +# CONFIG_PPC_256K_PAGES is not set CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_PROC_DEVICETREE=y # CONFIG_CMDLINE_BOOL is not set @@ -277,6 +288,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set #
