Re: kernel panic during kernel module load (powerpc specific part)
I believe that the basic premise is that you should provide a directly
reachable copy of the save/rstore functions, even if this means that
you need several copies of the functions.
I just fixed a very similar problem with grub2 in fact. It was using r0
and trashing the saved LR that way.
The real fix is indeed to statically link those gcc "helpers", we
shouldn't generate things like cross-module calls inside function prologs
and epilogues, when stackframes aren't even guaranteed to be reliable.
However, in the grub2 case, it was easier to just use r12 :-)
For not just the module loading case, I believe r12 is the only real solution
now. I checked one debugger capable of doing ELF download. It also uses r12 for
trampoline code. I am guessing for the reason that prompted this discussion.
Without r12 we'd have to change standard libraries to automagically link in gcc
helpers for any conceivable non-.text section, which I am not sure is feasible.
How would you write section independent helper functions which link to any
section needing them?!
Asking users to create their own section specific copy of helper functions is
definitely not portable if the module or other code is not architecture
dependent.
It is a normal gcc feature that you can assign specific code to non-.text
sections and it is not documented that it may crash depending on the OS arch
the ELF is built for, so asking for a Power Architecture specific change on
tool libs to make Power Architecture Linux happy seems a bit much to ask.
Using r12 in any Linux related trampoline code seems a reachable goal, and it
would eliminate the conflict to the ABI.
Regards,
Heinz
Hi,
I've tried the fix using register r12 for the trampoline code, instead of
register r11.
I'd to adapt entry_matches() too:
--- arch/powerpc/kernel/module_32.c(revision 1898)
+++ arch/powerpc/kernel/module_32.c(working copy)
@@ -187,8 +187,8 @@
static inline int entry_matches(struct ppc_plt_entry *entry, Elf32_Addr val)
{
-if (entry->jump[0] == 0x3d60 + ((val + 0x8000) >> 16)
- && entry->jump[1] == 0x396b + (val & 0x))
+if (entry->jump[0] == 0x3d80 + ((val + 0x8000) >> 16)
+ && entry->jump[1] == 0x398c + (val & 0x))
return 1;
return 0;
}
@@ -215,10 +215,9 @@
entry++;
}
-/* Stolen from Paul Mackerras as well... */
-entry->jump[0] = 0x3d60+((val+0x8000)>>16);/* lis r11,sym@ha */
-entry->jump[1] = 0x396b + (val&0x);/* addi r11,r11,sym@l*/
-entry->jump[2] = 0x7d6903a6;/* mtctr r11 */
+entry->jump[0] = 0x3d80+((val+0x8000)>>16); /* lis r12,sym@ha */
+entry->jump[1] = 0x398c + (val&0x); /* addi r12,r12,sym@l*/
+entry->jump[2] = 0x7d8903a6;/* mtctr r12 */
entry->jump[3] = 0x4e800420;/* bctr */
DEBUGP("Initialized plt for 0x%x at %p\n", val, entry);
It looks working, also in the case the trampoline code is used.
Please see also the debug session below.
Let me summarize the situation:
+ According to Freescale, EABI assigns a dedicated function to register r11.
+ The ELF sections .text and .init.text may trigger the usage of the
trampoline code.
+ The trampoline code must not user register r11, too.
+ We must not depend on addresses returned by vmalloc during kernel module
loading.
I think the bug must be fixed !!!
Regards
Steffen
--
(gdb) bt
#0 0xd54990f0 in ?? ()
#1 0xd5499088 in ?? ()
#2 0xc0001d9c in do_one_initcall (fn=0xd76e26ac) at init/main.c:716
#3 0xc0059630 in sys_init_module (umod=0x4802f008, len=,
uargs=0x10012008 "") at kernel/module.c:2470
#4 0xc000dff8 in syscall_dotrace_cont () at arch/powerpc/kernel/entry_32.S:331
Backtrace stopped: frame did not save the PC
<-- we are returning from the driver init entry point
(gdb) info reg r11
r110xcbb57f003417669376
(gdb) x/2x 0xcbb57f00
0xcbb57f00:0xcbb57f200xc0001d9c
<-- register r11 is fine here
0xd54990f0: lis r12,-10386
0xd54990f4: addir12,r12,-20268
0xd54990f8: mtctr r12
<-- this is the trampoline code using now r12, instead of r11
(gdb) info reg r12
r120xd76db0d43614290132
(gdb) info reg ctr
ctr0xd76db0d43614290132
0xd54990fc: bctr
<-- we are jumping to the epilogue
0xd76db0d4: lwz r29,-12(r11)
0xd76db0d8: lwz r30,-8(r11)
0xd76db0dc: lwz r0,4(r11)
0xd76db0e0: lwz r31,-4(r11)
0xd76db0e4: mtlrr0
0xd76db0e8: mr r1,r11
<- the epilogue
(gdb) info reg lr
lr 0xc0001d9c0xc0001d9c
0xc0001d9c : lis r9,-16330
0xc0001da0 : lwz r0,12296(r9)
0xc0001da4 : lis r9,-16330
0xd76db0ec: blr
<-- the jump back to do_one_initcall()
<-- no crash
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Optimise the 64bit optimised __clear_user
I blame Mikey for this. He elevated my slightly dubious testcase: # dd if=/dev/zero of=/dev/null bs=1M count=1 to benchmark status. And naturally we need to be number 1 at creating zeros. So lets improve __clear_user some more. As Paul suggests we can use dcbz for large lengths. This patch gets the destination 128 byte aligned then uses dcbz on whole cachelines. Before: 1048576 bytes (10 GB) copied, 0.414744 s, 25.3 GB/s After: 1048576 bytes (10 GB) copied, 0.268597 s, 39.0 GB/s 39 GB/s, a new record. Signed-off-by: Anton Blanchard --- Index: linux-build/arch/powerpc/lib/string_64.S === --- linux-build.orig/arch/powerpc/lib/string_64.S 2012-06-04 16:18:56.351604302 +1000 +++ linux-build/arch/powerpc/lib/string_64.S2012-06-04 16:47:10.538500871 +1000 @@ -78,7 +78,7 @@ _GLOBAL(__clear_user) blt .Lshort_clear mr r8,r3 mtocrf 0x01,r6 - clrldi r6,r6,(64-3) + clrldi r7,r6,(64-3) /* Get the destination 8 byte aligned */ bf cr7*4+3,1f @@ -93,11 +93,16 @@ err1; sth r0,0(r3) err1; stw r0,0(r3) addir3,r3,4 -3: sub r4,r4,r6 - srdir6,r4,5 +3: sub r4,r4,r7 + cmpdi r4,32 + cmpdi cr1,r4,512 blt .Lshort_clear - mtctr r6 + bgt cr1,.Llong_clear + +.Lmedium_clear: + srdir7,r4,5 + mtctr r7 /* Do 32 byte chunks */ 4: @@ -139,3 +144,52 @@ err1; stb r0,0(r3) 10:li r3,0 blr + +.Llong_clear: + /* Destination is 8 byte aligned, need to get it 128 byte aligned */ + bf cr7*4+0,11f +err2; std r0,0(r3) + addir3,r3,8 + addir4,r4,-8 + +11:srdir6,r6,4 + mtocrf 0x01,r6 + + bf cr7*4+3,12f +err2; std r0,0(r3) +err2; std r0,8(r3) + addir3,r3,16 + addir4,r4,-16 + +12:bf cr7*4+2,13f +err2; std r0,0(r3) +err2; std r0,8(r3) +err2; std r0,16(r3) +err2; std r0,24(r3) + addir3,r3,32 + addir4,r4,-32 + +13:bf cr7*4+1,14f +err2; std r0,0(r3) +err2; std r0,8(r3) +err2; std r0,16(r3) +err2; std r0,24(r3) +err2; std r0,32(r3) +err2; std r0,40(r3) +err2; std r0,48(r3) +err2; std r0,56(r3) + addir3,r3,64 + addir4,r4,-64 + +14:srdir6,r4,7 + mtctr r6 + +15: +err2; dcbzr0,r3 + addir3,r3,128 + addir4,r4,-128 + bdnz15b + + cmpdi r4,32 + blt .Lshort_clear + b .Lmedium_clear ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pci: save P2P bridge resource if possible
When PCI probe flag PCI_REASSIGN_ALL_RSRC has been passed into PCI
core, it's hoped that all resources to be reassigned by PCI core.
As to particular P2P (PCI-to-PCI) bridge, the size of the corresponding
BAR (I/O, MMIO, prefetchable MMIO) is calculated by the resources
required by the PCI devices behind the P2P bridge. That means that
the information like start/end address retrieved from the hardware
registers of the P2P bridge is meainingless in the case. However,
we still count that in and the BARs might have been configured by
firmware with non-zero size. That leads to space waste.
The patch explicitly sets the size of P2P bridge BARs to zero in
case that resource reassignment is expected with PCI probe flag
PCI_REASSIGN_ALL_RSRC. In the result, it will save overall resource
required by the system without waste.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/pci-common.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 8e78e93..0fe214d 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -966,13 +966,14 @@ static void __devinit pcibios_fixup_bridge(struct pci_bus
*bus)
if (i >= 3 && bus->self->transparent)
continue;
- /* If we are going to re-assign everything, mark the resource
-* as unset and move it down to 0
+ /* If we're going to reassign everything, we can
+* shrink the P2P resource to have size as being
+* of 0 in order to save space.
*/
if (pci_has_flag(PCI_REASSIGN_ALL_RSRC)) {
res->flags |= IORESOURCE_UNSET;
- res->end -= res->start;
res->start = 0;
+ res->end = -1;
continue;
}
@@ -1234,7 +1235,14 @@ void pcibios_allocate_bus_resources(struct pci_bus *bus)
pr_warning("PCI: Cannot allocate resource region "
"%d of PCI bridge %d, will remap\n", i, bus->number);
clear_resource:
- res->start = res->end = 0;
+ /* The resource might be figured out when doing
+* reassignment based on the resources required
+* by the downstream PCI devices. Here we set
+* the size of the resource to be 0 in order to
+* save more space.
+*/
+ res->start = 0;
+ res->end = -1;
res->flags = 0;
}
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pci: save P2P bridge resource if possible
On Mon, 2012-06-04 at 16:15 +0800, Gavin Shan wrote:
> When PCI probe flag PCI_REASSIGN_ALL_RSRC has been passed into PCI
> core, it's hoped that all resources to be reassigned by PCI core.
> As to particular P2P (PCI-to-PCI) bridge, the size of the corresponding
> BAR (I/O, MMIO, prefetchable MMIO) is calculated by the resources
> required by the PCI devices behind the P2P bridge. That means that
> the information like start/end address retrieved from the hardware
> registers of the P2P bridge is meainingless in the case. However,
> we still count that in and the BARs might have been configured by
> firmware with non-zero size. That leads to space waste.
>
> The patch explicitly sets the size of P2P bridge BARs to zero in
> case that resource reassignment is expected with PCI probe flag
> PCI_REASSIGN_ALL_RSRC. In the result, it will save overall resource
> required by the system without waste.
Hrm... there was a reason I wasn't doing that but I can't
remember what it was, it's possible it no longer applies. I'll
have to make sure this patch is tested on various 4xx and FSL
configs.
Cheers,
Ben.
> Signed-off-by: Gavin Shan
> ---
> arch/powerpc/kernel/pci-common.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c
> b/arch/powerpc/kernel/pci-common.c
> index 8e78e93..0fe214d 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -966,13 +966,14 @@ static void __devinit pcibios_fixup_bridge(struct
> pci_bus *bus)
> if (i >= 3 && bus->self->transparent)
> continue;
>
> - /* If we are going to re-assign everything, mark the resource
> - * as unset and move it down to 0
> + /* If we're going to reassign everything, we can
> + * shrink the P2P resource to have size as being
> + * of 0 in order to save space.
>*/
> if (pci_has_flag(PCI_REASSIGN_ALL_RSRC)) {
> res->flags |= IORESOURCE_UNSET;
> - res->end -= res->start;
> res->start = 0;
> + res->end = -1;
> continue;
> }
>
> @@ -1234,7 +1235,14 @@ void pcibios_allocate_bus_resources(struct pci_bus
> *bus)
> pr_warning("PCI: Cannot allocate resource region "
> "%d of PCI bridge %d, will remap\n", i, bus->number);
> clear_resource:
> - res->start = res->end = 0;
> + /* The resource might be figured out when doing
> + * reassignment based on the resources required
> + * by the downstream PCI devices. Here we set
> + * the size of the resource to be 0 in order to
> + * save more space.
> + */
> + res->start = 0;
> + res->end = -1;
> res->flags = 0;
> }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add MSR_DE to MSR_KERNEL
Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set in order to support break points for booke archs. This adds MSR_DE for kernel space only, protected by CONFIG_BDI_SWITCH Signed-off-by: Joakim Tjernlund --- arch/powerpc/include/asm/reg_booke.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 500fe1d..b3e57ed 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -37,7 +37,11 @@ #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE) #define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE) #else +#ifdef CONFIG_BDI_SWITCH +#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE) +#else #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE) +#endif #define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE) #endif -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
Benjamin Herrenschmidt wrote on 2012/06/02 23:21:16: > > On Sat, 2012-06-02 at 20:29 +0200, Joakim Tjernlund wrote: > > > > hmm, where does this go w.r.t the patch? Got the feeling that the > > best thing is to just turn MSR:DE on and be done with it? > > Not unconditionally, we need to have a close look, that might be ok > specifically for BookE 32-bit, it's certainly not ok for BookE 64-bit at > this point. > > For now, I'm ok with a debug CONFIG_* option. > > Also do we know if MSR:DE has any performance impact on any CPU ? I know > having DACs enabled has a major impact on some for example. I just sent a new patch, named [PATCH] powerpc: Add MSR_DE to MSR_KERNEL which will only add MSR_DE for booke under CONFIG_BDI_SWITCH ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pci: save P2P bridge resource if possible
>> When PCI probe flag PCI_REASSIGN_ALL_RSRC has been passed into PCI
>> core, it's hoped that all resources to be reassigned by PCI core.
>> As to particular P2P (PCI-to-PCI) bridge, the size of the corresponding
>> BAR (I/O, MMIO, prefetchable MMIO) is calculated by the resources
>> required by the PCI devices behind the P2P bridge. That means that
>> the information like start/end address retrieved from the hardware
>> registers of the P2P bridge is meainingless in the case. However,
>> we still count that in and the BARs might have been configured by
>> firmware with non-zero size. That leads to space waste.
>>
>> The patch explicitly sets the size of P2P bridge BARs to zero in
>> case that resource reassignment is expected with PCI probe flag
>> PCI_REASSIGN_ALL_RSRC. In the result, it will save overall resource
>> required by the system without waste.
>
>Hrm... there was a reason I wasn't doing that but I can't
>remember what it was, it's possible it no longer applies. I'll
>have to make sure this patch is tested on various 4xx and FSL
>configs.
>
Ok. Thanks, Ben. By the way, I've tested it on Firebird-L machine
while passing PCI_REASSIGN_ALL_RSRC into PCI core. Everything looks
fine :-)
>Cheers,
>Ben.
Thanks,
Gavin
>
>> Signed-off-by: Gavin Shan
>> ---
>> arch/powerpc/kernel/pci-common.c | 16
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/pci-common.c
>> b/arch/powerpc/kernel/pci-common.c
>> index 8e78e93..0fe214d 100644
>> --- a/arch/powerpc/kernel/pci-common.c
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -966,13 +966,14 @@ static void __devinit pcibios_fixup_bridge(struct
>> pci_bus *bus)
>> if (i >= 3 && bus->self->transparent)
>> continue;
>>
>> -/* If we are going to re-assign everything, mark the resource
>> - * as unset and move it down to 0
>> +/* If we're going to reassign everything, we can
>> + * shrink the P2P resource to have size as being
>> + * of 0 in order to save space.
>> */
>> if (pci_has_flag(PCI_REASSIGN_ALL_RSRC)) {
>> res->flags |= IORESOURCE_UNSET;
>> -res->end -= res->start;
>> res->start = 0;
>> +res->end = -1;
>> continue;
>> }
>>
>> @@ -1234,7 +1235,14 @@ void pcibios_allocate_bus_resources(struct pci_bus
>> *bus)
>> pr_warning("PCI: Cannot allocate resource region "
>> "%d of PCI bridge %d, will remap\n", i, bus->number);
>> clear_resource:
>> -res->start = res->end = 0;
>> +/* The resource might be figured out when doing
>> + * reassignment based on the resources required
>> + * by the downstream PCI devices. Here we set
>> + * the size of the resource to be 0 in order to
>> + * save more space.
>> + */
>> +res->start = 0;
>> +res->end = -1;
>> res->flags = 0;
>> }
>>
>
>
>___
>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
NIC bring-up issue on powerpc-440 based board
Hi All, I'm trying to bring-up a PCIe based NIC(e1000e) card on a PowerPC-440 based board, I'm able to list this device under lspci from the user space, but the driver probe fails and looks like mmio mapping doesn't look right. Following is the bootlog of the kernel. Can anyone point out what is going wrong here? The kernel is a relocatable one and system memory is mapped at 0x5000_ to 0x6000_ I dont have a serial console, I use ttyprintk to get the userspace prints (on dmesg). <6>[0.00] Using XXX machine description<5>[0.00] Linux version 3.3.0-rc2 (root@sumeshkn) (gcc version 4.4.6 20110214 (4.4.5-6) (GCC) ) #125 PREEMPT Mon Jun 4 04:51:02 EDT 2012<7>[0.00] Found initrd at 0xc0937000:0xc0d8803b<7>[0.00] Top of RAM: 0x6000, Total RAM: 0x1000<7>[0.00] Memory hole size: 1280MB<7>[0.00] Zone PFN ranges:<7>[0.00] DMA 0x0005 -> 0x0006<7>[0.00] Normal empty<7>[0.00] HighMem empty<7>[0.00] Movable zone start PFN for each node<7>[0.00] Early memory PFN ranges<7>[ 0.00] 0: 0x0005 -> 0x0006<7>[0.00] On node 0 totalpages: 65536<7>[0.00] free_area_init_node: node 0, pgdat c026d258, node_mem_map c02b<7>[0.00] DMA zone: 512 pages used for memmap<7>[0.00] DMA zone: 0 pages reserved<7>[0.00] DMA zone: 65024 pages, LIFO batch:15<6>[0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts<7>[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768<7>[0.00] pcpu-alloc: [0] 0 <7>[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024<5>[ 0.00] Kernel command line: root=/dev/ram<6>[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)<6>[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)<6>[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)<7>[0.00] High memory: 0k<6>[ 0.00] Memory: 252632k/262144k available (2372k kernel code, 9512k reserved, 148k data, 222k bss, 160k init)<6>[0.00] Kernel virtual memory layout:<6>[0.00] * 0xfffcf000..0xf000 : fixmap<6>[0.00] * 0xffc0..0xffe0 : highmem PTEs<6>[0.00] * 0xffa0..0xffc0 : consistent mem<6>[0.00] * 0xffa0..0xffa0 : early ioremap<6>[0.00] * 0xd100..0xffa0 : vmalloc & ioremap<6>[0.00] NR_IRQS:512<6>[ 0.00] kmemleak: Kernel memory leak detector disabled<7>[0.00] time_init: decrementer frequency = 166.67 MHz<7>[0.00] time_init: processor frequency = 666.64 MHz<6>[0.00] clocksource: timebase mult[600] shift[24] registered<7>[0.00] clockevent: decrementer mult[2aac] shift[32] cpu[0]<6>[0.00] Console: colour dummy device 80x25<6>[0.00] console [tty0] enabled<4>[0.00] kmemleak: Early log buffer exceeded (907), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE<6>[ 0.61] pid_max: default: 32768 minimum: 301<6>[0.85] Mount-cache hash table entries: 512<6>[0.000279] NET: Registered protocol family 16<6>[ 0.104014] PCI host bridge /pciex (primary) ranges:<6>[0.104017] MEM 0x8000..0x9fff -> 0x8000 <6>[0.104019] IO 0xb000..0xb00f -> 0x<6>[ 0.104029] PCIE0: successfully set as root-complex<6>[0.104072] PCI: Probing PCI hardware<7>[0.104075] PCI: Scanning PHB /pciex<7>[0.104076] PCI: PHB IO resource= -000f [100]<7>[0.104077] PCI: PHB MEM resource 0 = 8000-9fff [200]<7>[ 0.104077] PCI: PHB MEM offset = <7>[0.104078] PCI: PHB IO offset = <6>[0.104110] PCI host bridge to bus :00<6>[ 0.104113] pci_bus :00: root bus resource [io 0x-0xf]<6>[ 0.104115] pci_bus :00: root bus resource [mem 0x8000-0x9fff]<7>[ 0.104116] pci-common-probe mode: 0<7>[0.104117] pci_bus :00: PCI_DRIVER: pci_scanning_bus<7>[0.104119] PCI_DRIVER: pci_setup_device <7>[ 0.104121] pci :00:00.0: PCI_DRIVER [8086:105e] type 0 class 0x000200<7>[ 0.104121] pci :00:00.0: pci_cfg_space_size -before<7>[0.104122] pci :00:00.0: pci_cfg_space_size - after<7>[0.104122] PCI_DRIVER: pci_fixup_device<7>[0.104123] PCI_DRIVER: case pci_fixup_early<7>[ 0.104124] pci :00:00.0: calling fixup_xxx+0x0/0x64<7>[0.104125] XXX_FIXUP_EARLY: vendor : 8086, device: 105e<7>[0.104126] pci :00:00.0: calling quirk_mmio_always_on+0x0/0x24<7>[0.104127] pci :00:00.0: pci_fxup_device (pci_fixup_early)<7>[0.104127] PCI_DRIVER: pci_read_bases:vendor:8086,device:105e Pos : 0x0, Reg:0x10<7>[0.104128] pci :00:00.0: reg 10: [mem 0x8000-0x8001fff
Re: [PATCH v5 2/5] powerpc/85xx: add HOTPLUG_CPU support
On Fri, Jun 01, 2012 at 04:27:27PM -0500, Scott Wood wrote:
> On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
> \> +#if defined(CONFIG_FSL_BOOKE) || defined(CONFIG_6xx)
> > +extern void __flush_disable_L1(void);
> > +#endif
>
> Prototypes aren't normally guarded by ifdefs.
OK. Thanks.
>
> > +static void __cpuinit smp_85xx_mach_cpu_die(void)
> > +{
> > + unsigned int cpu = smp_processor_id();
> > + u32 tmp;
> > +
> > + local_irq_disable();
> > + idle_task_exit();
> > + generic_set_cpu_dead(cpu);
> > + mb();
> > +
> > + mtspr(SPRN_TCR, 0);
> > +
> > + __flush_disable_L1();
> > + tmp = (mfspr(SPRN_HID0) & ~(HID0_DOZE|HID0_SLEEP)) | HID0_NAP;
> > + mtspr(SPRN_HID0, tmp);
> > +
> > + /* Enter NAP mode. */
> > + tmp = mfmsr();
> > + tmp |= MSR_WE;
> > + mb();
> > + mtmsr(tmp);
> > + isync();
>
> Need isync after writing to HID0.
>
> > + /*
> > +* We don't set the BPTR register here upon it points
> > +* to the boot page properly.
> > +*/
> > + mpic_reset_core(hw_cpu);
>
> That comment's wording is hard to follow -- maybe s/upon it points/since
> it already points/
>
> > + /* wait until core is ready... */
> > + if (!spin_event_timeout(in_be32(&spin_table->addr_l) == 1,
> > + 1, 100)) {
> > + pr_err("%s: timeout waiting for core %d to reset\n",
> > + __func__, hw_cpu);
> > + ret = -ENOENT;
> > + goto out;
> > + }
>
> We need to fix U-Boot to write addr_l last (with an msync beforehand).
I agree.
>
> > -#ifdef CONFIG_KEXEC
> > +#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
>
> Let's not grow lists like this. Is there any harm in building it
> unconditionally?
>
> -Scott
We need this ifdef. We only set give_timebase/take_timebase
when CONFIG_KEXEC or CONFIG_HOTPLUG_CPU is defined.
-Chenhui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 3/5] powerpc/85xx: add sleep and deep sleep support
On Fri, Jun 01, 2012 at 04:54:35PM -0500, Scott Wood wrote:
> On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
> > From: Li Yang
> >
> > In sleep PM mode, the clocks of e500 core and unused IP blocks is
> > turned off. IP blocks which are allowed to wake up the processor
> > are still running.
> >
> > Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode
> > in addtion to the sleep PM mode.
> >
> > While in deep sleep PM mode, additionally, the power supply is
> > removed from e500 core and most IP blocks. Only the blocks needed
> > to wake up the chip out of deep sleep are ON.
> >
> > This patch supports 32-bit and 36-bit address space.
> >
> > The sleep mode is equal to the Standby state in Linux. The deep sleep
> > mode is equal to the Suspend-to-RAM state of Linux Power Management.
> >
> > Command to enter sleep mode.
> > echo standby > /sys/power/state
> > Command to enter deep sleep mode.
> > echo mem > /sys/power/state
> >
> > Signed-off-by: Dave Liu
> > Signed-off-by: Li Yang
> > Signed-off-by: Jin Qing
> > Signed-off-by: Jerry Huang
> > Cc: Scott Wood
> > Signed-off-by: Zhao Chenhui
> > ---
> > Changes for v5:
> > * Rename flush_disable_L1 to __flush_disable_L1.
> >
> > arch/powerpc/Kconfig |2 +-
> > arch/powerpc/include/asm/cacheflush.h |5 +
> > arch/powerpc/kernel/Makefile |3 +
> > arch/powerpc/kernel/l2cache_85xx.S| 53 +++
> > arch/powerpc/platforms/85xx/Makefile |3 +
> > arch/powerpc/platforms/85xx/sleep.S | 609
> > +
> > arch/powerpc/sysdev/fsl_pmc.c | 91 -
> > arch/powerpc/sysdev/fsl_soc.h |5 +
> > 8 files changed, 752 insertions(+), 19 deletions(-)
> > create mode 100644 arch/powerpc/kernel/l2cache_85xx.S
> > create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> >
> > diff --git a/arch/powerpc/include/asm/cacheflush.h
> > b/arch/powerpc/include/asm/cacheflush.h
> > index 94ec20a..baa000c 100644
> > --- a/arch/powerpc/include/asm/cacheflush.h
> > +++ b/arch/powerpc/include/asm/cacheflush.h
> > @@ -33,6 +33,11 @@ extern void flush_dcache_page(struct page *page);
> > #if defined(CONFIG_FSL_BOOKE) || defined(CONFIG_6xx)
> > extern void __flush_disable_L1(void);
> > #endif
> > +#if defined(CONFIG_FSL_BOOKE)
> > +extern void flush_dcache_L1(void);
> > +#else
> > +#define flush_dcache_L1() do { } while (0)
> > +#endif
>
> It doesn't seem right to no-op this on other platforms.
The pmc_suspend_enter() in fsl_pmc.c used by mpc85xx and mpc86xx,
but flush_dcache_L1() have no definition in mpc86xx platform.
I will write flush_dcache_L1() for mpc86xx platform.
>
> > extern void __flush_icache_range(unsigned long, unsigned long);
> > static inline void flush_icache_range(unsigned long start, unsigned long
> > stop)
> > diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> > index f5808a3..cb70dba 100644
> > --- a/arch/powerpc/kernel/Makefile
> > +++ b/arch/powerpc/kernel/Makefile
> > @@ -64,6 +64,9 @@ obj-$(CONFIG_FA_DUMP) += fadump.o
> > ifeq ($(CONFIG_PPC32),y)
> > obj-$(CONFIG_E500) += idle_e500.o
> > endif
> > +ifneq ($(CONFIG_PPC_E500MC),y)
> > +obj-$(CONFIG_PPC_85xx) += l2cache_85xx.o
> > +endif
>
> Can we introduce a symbol that specifically means pre-e500mc e500,
> rather than using negative logic?
>
> I think something like CONFIG_PPC_E500_V1_V2 has been proposed before.
Agree. But CONFIG_PPC_E500_V1_V2 haven't been merged.
>
> > -static int pmc_probe(struct platform_device *ofdev)
> > +static int pmc_probe(struct platform_device *pdev)
> > {
> > - pmc_regs = of_iomap(ofdev->dev.of_node, 0);
> > + struct device_node *np = pdev->dev.of_node;
> > +
> > + pmc_regs = of_iomap(np, 0);
> > if (!pmc_regs)
> > return -ENOMEM;
> >
> > - pmc_dev = &ofdev->dev;
> > + pmc_flag = PMC_SLEEP;
> > + if (of_device_is_compatible(np, "fsl,mpc8536-pmc"))
> > + pmc_flag |= PMC_DEEP_SLEEP;
> > +
> > + if (of_device_is_compatible(np, "fsl,p1022-pmc"))
> > + pmc_flag |= PMC_DEEP_SLEEP;
> > +
> > suspend_set_ops(&pmc_suspend_ops);
> > +
> > + pr_info("Freescale PMC driver\n");
>
> If you're going to be noisy on probe, at least provide some useful info
> like whether deep sleep or jog are supported.
>
> > return 0;
> > }
> >
> > diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
> > index c6d0073..949377d 100644
> > --- a/arch/powerpc/sysdev/fsl_soc.h
> > +++ b/arch/powerpc/sysdev/fsl_soc.h
> > @@ -48,5 +48,10 @@ extern struct platform_diu_data_ops diu_ops;
> > void fsl_hv_restart(char *cmd);
> > void fsl_hv_halt(void);
> >
> > +/*
> > + * Cast the ccsrbar to 64-bit parameter so that the assembly
> > + * code can be compatible with both 32-bit & 36-bit.
> > + */
> > +extern void mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
>
> s/Cast the ccsrbar to 64-bit parameter/ccsrbar is u64 rather than
>
Re: kernel panic during kernel module load (powerpc specific part)
On Fri, Jun 01, 2012 at 11:33:37AM +, Wrobel Heinz-R39252 wrote: > > > I believe that the basic premise is that you should provide a directly > > > reachable copy of the save/rstore functions, even if this means that > > you need several copies of the functions. > > > > I just fixed a very similar problem with grub2 in fact. It was using r0 > > and trashing the saved LR that way. > > > > The real fix is indeed to statically link those gcc "helpers", we > > shouldn't generate things like cross-module calls inside function prologs > > and epilogues, when stackframes aren't even guaranteed to be reliable. > > > > However, in the grub2 case, it was easier to just use r12 :-) > > For not just the module loading case, I believe r12 is the only real solution > now. I checked one debugger capable of doing ELF download. It also uses r12 > for trampoline code. I am guessing for the reason that prompted this > discussion. > I disagree. Look carefully at Be's answer: cross-module calls are intrinsically dangerous when stack frames are in a transient state. > Without r12 we'd have to change standard libraries to automagically link in > gcc helpers for any conceivable non-.text section, which I am not sure is > feasible. How would you write section independent helper functions which link > to any section needing them?! I don't thnk that it is tha bad: the helpers should be linked to the default .text section when needed, typically the init code and so on are mapped within the reach of that section (otherwise you'll end up with the linker complaining that it finds overflowing branch offsets between .text and .init.text). > Asking users to create their own section specific copy of helper functions is > definitely not portable if the module or other code is not architecture > dependent. Well, it automagically works on 64 bit. There is is performed by magic built into the linker. > It is a normal gcc feature that you can assign specific code to non-.text > sections and it is not documented that it may crash depending on the OS arch > the ELF is built for, so asking for a Power Architecture specific change on > tool libs to make Power Architecture Linux happy seems a bit much to ask. > Once again I disagree. > Using r12 in any Linux related trampoline code seems a reachable goal, and it > would eliminate the conflict to the ABI. > There is no conflict to the ABI. These functions are supposed to be directly reachable from whatever code section may need them. Now I have a question: how did you get the need for this? None of my kernels uses them: - if I compile with -O2, the compiler simply expands epilogue and prologue to series of lwz and stw - if I compile with -Os, the compiler generates lmw/stmw which give the smallest possible cache footprint Neither did I find a single reference to these functions in several systems that I grepped for. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD
Hi, On Mon, 2012-05-21 at 22:04 +0300, Felipe Balbi wrote: > On Mon, May 21, 2012 at 08:57:22AM +0200, Christoph Fritz wrote: > > USB controller may access a wrong address for the dTD (endpoint transfer > > descriptor) and then hang. This happens a lot when doing tests with > > g_ether module and iperf, a tool for measuring maximum TCP and UDP > > bandwidth. > > > > This hardware bug is explained in detail by errata number 2858 for i.MX23: > > http://cache.freescale.com/files/dsp/doc/errata/IMX23CE.pdf > > > > All (?) SOCs with an IP from chipidea suffer from this problem. > > mv_udc_core fixes this bug by commit daec765. There still may be > > unfixed drivers. > > > > Signed-off-by: Christoph Fritz > > Signed-off-by: Christian Hemp > > --- > > drivers/usb/gadget/fsl_udc_core.c | 15 ++- > > 1 files changed, 14 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/usb/gadget/fsl_udc_core.c > > b/drivers/usb/gadget/fsl_udc_core.c > > index 55abfb6..72f2139 100644 > > --- a/drivers/usb/gadget/fsl_udc_core.c > > +++ b/drivers/usb/gadget/fsl_udc_core.c > > @@ -65,6 +65,8 @@ static struct usb_sys_interface *usb_sys_regs; > > /* it is initialized in probe() */ > > static struct fsl_udc *udc_controller = NULL; > > > > +static struct ep_td_struct *last_free_td; > > I don't want to see global variables anymore. In fact, please convert > this to the new udc_start()/udc_stop() calls and use the generic > map/unmap routines. > > That'll help you get rid of a bunch of useless code on the driver. After > that you should remove all header includes and drop the ARCH > dependency. > > You can also drop the big-/little-endian helpers as you can make use of > generic writel()/readl() routines. > > Please make sure these series comes in with enough time to reach v3.6 > merge window in about 3 months. > > You can put this fix together on that series after you drop the global. Before I came to do the proposed changes, I stumbled upon this: In file included from drivers/usb/gadget/fsl_udc_core.c:49: drivers/usb/gadget/fsl_usb2_udc.h: In function ‘get_qh_by_ep’: drivers/usb/gadget/fsl_usb2_udc.h:585: error: ‘struct fsl_ep’ has no member named ‘desc’ drivers/usb/gadget/fsl_udc_core.c: In function ‘done’: drivers/usb/gadget/fsl_udc_core.c:187: error: ‘struct fsl_ep’ has no member named ‘desc’ drivers/usb/gadget/fsl_udc_core.c:187: error: ‘struct fsl_ep’ has no member named ‘desc’ my proposed regression patch: --- From: Christoph Fritz Date: Mon, 4 Jun 2012 12:58:21 +0200 Subject: [PATCH] usb: gadget: regression fix - useage of usb_ep This patch removes redundant pointer to struct usb_endpoint_descriptor which were missed in commit 79149b8: usb: gadget: Update fsl_udc_core to use usb_endpoint_descriptor inside the struct usb_ep Signed-off-by: Christoph Fritz --- drivers/usb/gadget/fsl_udc_core.c |2 +- drivers/usb/gadget/fsl_usb2_udc.h |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index 2831685..678ec4d 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -2575,7 +2575,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev) /* for ep0: the desc defined here; * for other eps, gadget layer called ep_enable with defined desc */ - udc_controller->eps[0].desc = &fsl_ep0_desc; + udc_controller->eps[0].ep.desc = &fsl_ep0_desc; udc_controller->eps[0].ep.maxpacket = USB_MAX_CTRL_PAYLOAD; /* setup the udc->eps[] for non-control endpoints and link diff --git a/drivers/usb/gadget/fsl_usb2_udc.h b/drivers/usb/gadget/fsl_usb2_udc.h index 5cd7b7e..f61a967 100644 --- a/drivers/usb/gadget/fsl_usb2_udc.h +++ b/drivers/usb/gadget/fsl_usb2_udc.h @@ -568,10 +568,10 @@ static void dump_msg(const char *label, const u8 * buf, unsigned int length) /* * ### internal used help routines. */ -#define ep_index(EP) ((EP)->desc->bEndpointAddress&0xF) +#define ep_index(EP) ((EP)->ep.desc->bEndpointAddress&0xF) #define ep_maxpacket(EP) ((EP)->ep.maxpacket) #define ep_is_in(EP) ( (ep_index(EP) == 0) ? (EP->udc->ep0_dir == \ - USB_DIR_IN ):((EP)->desc->bEndpointAddress \ + USB_DIR_IN) : ((EP)->ep.desc->bEndpointAddress \ & USB_DIR_IN)==USB_DIR_IN) #define get_ep_by_pipe(udc, pipe) ((pipe == 1)? &udc->eps[0]: \ &udc->eps[pipe]) -- 1.7.2.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source
On Fri, Jun 01, 2012 at 05:08:52PM -0500, Scott Wood wrote:
> On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
> > Add APIs for setting wakeup source and lossless Ethernet in low power modes.
> > These APIs can be used by wake-on-packet feature.
> >
> > Signed-off-by: Dave Liu
> > Signed-off-by: Li Yang
> > Signed-off-by: Jin Qing
> > Signed-off-by: Zhao Chenhui
> > ---
> > arch/powerpc/sysdev/fsl_pmc.c | 71
> > -
> > arch/powerpc/sysdev/fsl_soc.h |9 +
> > 2 files changed, 79 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/sysdev/fsl_pmc.c b/arch/powerpc/sysdev/fsl_pmc.c
> > index 1dc6e9e..c1170f7 100644
> > --- a/arch/powerpc/sysdev/fsl_pmc.c
> > +++ b/arch/powerpc/sysdev/fsl_pmc.c
> > @@ -34,6 +34,7 @@ struct pmc_regs {
> > __be32 powmgtcsr;
> > #define POWMGTCSR_SLP 0x0002
> > #define POWMGTCSR_DPSLP0x0010
> > +#define POWMGTCSR_LOSSLESS 0x0040
> > __be32 res3[2];
> > __be32 pmcdr;
> > };
> > @@ -43,6 +44,74 @@ static unsigned int pmc_flag;
> >
> > #define PMC_SLEEP 0x1
> > #define PMC_DEEP_SLEEP 0x2
> > +#define PMC_LOSSLESS 0x4
> > +
> > +/**
> > + * mpc85xx_pmc_set_wake - enable devices as wakeup event source
> > + * @pdev: platform device affected
> > + * @enable: True to enable event generation; false to disable
> > + *
> > + * This enables the device as a wakeup event source, or disables it.
> > + *
> > + * RETURN VALUE:
> > + * 0 is returned on success
> > + * -EINVAL is returned if device is not supposed to wake up the system
> > + * Error code depending on the platform is returned if both the platform
> > and
> > + * the native mechanism fail to enable the generation of wake-up events
> > + */
> > +int mpc85xx_pmc_set_wake(struct platform_device *pdev, bool enable)
>
> Why does it have to be a platform_device? Would a bare device_node work
> here? If it's for stuff like device_may_wakeup() that could be in a
> platform_device wrapper function.
It does not have to be a platform_device. I think it can be a struct device.
>
> Where does this get called from? I don't see an example user in this
> patchset.
It will be used by a gianfar related patch. I plan to submit that patch
after these patches accepted.
>
> > +{
> > + int ret = 0;
> > + struct device_node *clk_np;
> > + u32 *prop;
> > + u32 pmcdr_mask;
> > +
> > + if (!pmc_regs) {
> > + pr_err("%s: PMC is unavailable\n", __func__);
> > + return -ENODEV;
> > + }
> > +
> > + if (enable && !device_may_wakeup(&pdev->dev))
> > + return -EINVAL;
>
> Who is setting can_wakeup for these devices?
The device driver is responsible to set can_wakeup.
>
> > + clk_np = of_parse_phandle(pdev->dev.of_node, "fsl,pmc-handle", 0);
> > + if (!clk_np)
> > + return -EINVAL;
> > +
> > + prop = (u32 *)of_get_property(clk_np, "fsl,pmcdr-mask", NULL);
>
> Don't cast the const away.
OK.
>
> > + if (!prop) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > + pmcdr_mask = be32_to_cpup(prop);
> > +
> > + if (enable)
> > + /* clear to enable clock in low power mode */
> > + clrbits32(&pmc_regs->pmcdr, pmcdr_mask);
> > + else
> > + setbits32(&pmc_regs->pmcdr, pmcdr_mask);
>
> What is the default PMCDR if this function is never called? Should init
> to all bits set on PM driver probe (or maybe limit it to defined bits
> only, though that's a little harder to do generically).
>
> -Scot
The default PMCDR is defined separately by individual chip.
I agree with you. I will have a try.
-Chenhui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD
On Mon, 2012-06-04 at 13:30 +0200, Christoph Fritz wrote:
> Hi,
>
> On Mon, 2012-05-21 at 22:04 +0300, Felipe Balbi wrote:
> > On Mon, May 21, 2012 at 08:57:22AM +0200, Christoph Fritz wrote:
> > > USB controller may access a wrong address for the dTD (endpoint transfer
> > > descriptor) and then hang. This happens a lot when doing tests with
> > > g_ether module and iperf, a tool for measuring maximum TCP and UDP
> > > bandwidth.
> > >
> > > This hardware bug is explained in detail by errata number 2858 for i.MX23:
> > > http://cache.freescale.com/files/dsp/doc/errata/IMX23CE.pdf
> > >
> > > All (?) SOCs with an IP from chipidea suffer from this problem.
> > > mv_udc_core fixes this bug by commit daec765. There still may be
> > > unfixed drivers.
> > >
> > > Signed-off-by: Christoph Fritz
> > > Signed-off-by: Christian Hemp
> > > ---
> > > drivers/usb/gadget/fsl_udc_core.c | 15 ++-
> > > 1 files changed, 14 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/usb/gadget/fsl_udc_core.c
> > > b/drivers/usb/gadget/fsl_udc_core.c
> > > index 55abfb6..72f2139 100644
> > > --- a/drivers/usb/gadget/fsl_udc_core.c
> > > +++ b/drivers/usb/gadget/fsl_udc_core.c
> > > @@ -65,6 +65,8 @@ static struct usb_sys_interface *usb_sys_regs;
> > > /* it is initialized in probe() */
> > > static struct fsl_udc *udc_controller = NULL;
> > >
> > > +static struct ep_td_struct *last_free_td;
> >
> > I don't want to see global variables anymore. In fact, please convert
> > this to the new udc_start()/udc_stop() calls and use the generic
> > map/unmap routines.
> >
> > That'll help you get rid of a bunch of useless code on the driver. After
> > that you should remove all header includes and drop the ARCH
> > dependency.
> >
> > You can also drop the big-/little-endian helpers as you can make use of
> > generic writel()/readl() routines.
> >
> > Please make sure these series comes in with enough time to reach v3.6
> > merge window in about 3 months.
> >
> > You can put this fix together on that series after you drop the global.
>
> Before I came to do the proposed changes, I stumbled upon this:
>
> In file included from drivers/usb/gadget/fsl_udc_core.c:49:
> drivers/usb/gadget/fsl_usb2_udc.h: In function ‘get_qh_by_ep’:
> drivers/usb/gadget/fsl_usb2_udc.h:585: error: ‘struct fsl_ep’ has no member
> named ‘desc’
> drivers/usb/gadget/fsl_udc_core.c: In function ‘done’:
> drivers/usb/gadget/fsl_udc_core.c:187: error: ‘struct fsl_ep’ has no member
> named ‘desc’
> drivers/usb/gadget/fsl_udc_core.c:187: error: ‘struct fsl_ep’ has no member
> named ‘desc’
>
>
> my proposed regression patch:
> ---
> From: Christoph Fritz
> Date: Mon, 4 Jun 2012 12:58:21 +0200
> Subject: [PATCH] usb: gadget: regression fix - useage of usb_ep
After that, I stumbled upon this dmesg:
Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
fsl-usb2-udc fsl-usb2-udc: clk_get("usb") failed
fsl-usb2-udc: probe of fsl-usb2-udc failed with error -2
Sascha, could you give me a hint?
Thanks,
-- Christoph
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel panic during kernel module load (powerpc specific part)
On Mon, Jun 04, 2012 at 09:43:01AM +0200, Steffen Rumler wrote: > Let me summarize the situation: > >+ According to Freescale, EABI assigns a dedicated function to register > r11. >+ The ELF sections .text and .init.text may trigger the usage of the > trampoline code. >+ The trampoline code must not user register r11, too. >+ We must not depend on addresses returned by vmalloc during kernel module > loading. > > I think the bug must be fixed !!! I agree. If you submit your patch with a nice description of the problem and how the patch fixes it, along with your Signed-off-by, I'll send it upstream. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
Hi, On Mon, Jun 4, 2012 at 12:58 AM, Anton Blanchard wrote: > > I blame Mikey for this. He elevated my slightly dubious testcase: > > # dd if=/dev/zero of=/dev/null bs=1M count=1 > > to benchmark status. And naturally we need to be number 1 at creating > zeros. So lets improve __clear_user some more. > > As Paul suggests we can use dcbz for large lengths. This patch gets > the destination 128 byte aligned then uses dcbz on whole cachelines. > > Before: > 1048576 bytes (10 GB) copied, 0.414744 s, 25.3 GB/s > > After: > 1048576 bytes (10 GB) copied, 0.268597 s, 39.0 GB/s > > 39 GB/s, a new record. > > Signed-off-by: Anton Blanchard > --- > > Index: linux-build/arch/powerpc/lib/string_64.S > === > --- linux-build.orig/arch/powerpc/lib/string_64.S 2012-06-04 > 16:18:56.351604302 +1000 > +++ linux-build/arch/powerpc/lib/string_64.S 2012-06-04 16:47:10.538500871 > +1000 > @@ -78,7 +78,7 @@ _GLOBAL(__clear_user) [..] > +15: > +err2; dcbz r0,r3 > + addi r3,r3,128 > + addi r4,r4,-128 > + bdnz 15b This breaks architecture spec (and at least one implementation); cache lines are not guaranteed to be 128 bytes. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
On Jun 4, 2012, at 8:12 AM, Olof Johansson wrote: > Hi, > > On Mon, Jun 4, 2012 at 12:58 AM, Anton Blanchard wrote: >> >> I blame Mikey for this. He elevated my slightly dubious testcase: >> >> # dd if=/dev/zero of=/dev/null bs=1M count=1 >> >> to benchmark status. And naturally we need to be number 1 at creating >> zeros. So lets improve __clear_user some more. >> >> As Paul suggests we can use dcbz for large lengths. This patch gets >> the destination 128 byte aligned then uses dcbz on whole cachelines. >> >> Before: >> 1048576 bytes (10 GB) copied, 0.414744 s, 25.3 GB/s >> >> After: >> 1048576 bytes (10 GB) copied, 0.268597 s, 39.0 GB/s >> >> 39 GB/s, a new record. >> >> Signed-off-by: Anton Blanchard >> --- >> >> Index: linux-build/arch/powerpc/lib/string_64.S >> === >> --- linux-build.orig/arch/powerpc/lib/string_64.S 2012-06-04 >> 16:18:56.351604302 +1000 >> +++ linux-build/arch/powerpc/lib/string_64.S2012-06-04 >> 16:47:10.538500871 +1000 >> @@ -78,7 +78,7 @@ _GLOBAL(__clear_user) > [..] > >> +15: >> +err2; dcbzr0,r3 >> + addir3,r3,128 >> + addir4,r4,-128 >> + bdnz15b > > This breaks architecture spec (and at least one implementation); cache > lines are not guaranteed to be 128 bytes. I'm guessing it breaks more than one (FSL 64-bit is 64byte cache lines). - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD
On Mon, Jun 04, 2012 at 01:30:24PM +0200, Christoph Fritz wrote: > Hi, > > On Mon, 2012-05-21 at 22:04 +0300, Felipe Balbi wrote: > > On Mon, May 21, 2012 at 08:57:22AM +0200, Christoph Fritz wrote: > > > USB controller may access a wrong address for the dTD (endpoint transfer > > > descriptor) and then hang. This happens a lot when doing tests with > > > g_ether module and iperf, a tool for measuring maximum TCP and UDP > > > bandwidth. > > > > > > This hardware bug is explained in detail by errata number 2858 for i.MX23: > > > http://cache.freescale.com/files/dsp/doc/errata/IMX23CE.pdf > > > > > > All (?) SOCs with an IP from chipidea suffer from this problem. > > > mv_udc_core fixes this bug by commit daec765. There still may be > > > unfixed drivers. > > > > > > Signed-off-by: Christoph Fritz > > > Signed-off-by: Christian Hemp > > > --- > > > drivers/usb/gadget/fsl_udc_core.c | 15 ++- > > > 1 files changed, 14 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/usb/gadget/fsl_udc_core.c > > > b/drivers/usb/gadget/fsl_udc_core.c > > > index 55abfb6..72f2139 100644 > > > --- a/drivers/usb/gadget/fsl_udc_core.c > > > +++ b/drivers/usb/gadget/fsl_udc_core.c > > > @@ -65,6 +65,8 @@ static struct usb_sys_interface *usb_sys_regs; > > > /* it is initialized in probe() */ > > > static struct fsl_udc *udc_controller = NULL; > > > > > > +static struct ep_td_struct *last_free_td; > > > > I don't want to see global variables anymore. In fact, please convert > > this to the new udc_start()/udc_stop() calls and use the generic > > map/unmap routines. > > > > That'll help you get rid of a bunch of useless code on the driver. After > > that you should remove all header includes and drop the ARCH > > dependency. > > > > You can also drop the big-/little-endian helpers as you can make use of > > generic writel()/readl() routines. > > > > Please make sure these series comes in with enough time to reach v3.6 > > merge window in about 3 months. > > > > You can put this fix together on that series after you drop the global. > > Before I came to do the proposed changes, I stumbled upon this: > > In file included from drivers/usb/gadget/fsl_udc_core.c:49: > drivers/usb/gadget/fsl_usb2_udc.h: In function ‘get_qh_by_ep’: > drivers/usb/gadget/fsl_usb2_udc.h:585: error: ‘struct fsl_ep’ has no member > named ‘desc’ > drivers/usb/gadget/fsl_udc_core.c: In function ‘done’: > drivers/usb/gadget/fsl_udc_core.c:187: error: ‘struct fsl_ep’ has no member > named ‘desc’ > drivers/usb/gadget/fsl_udc_core.c:187: error: ‘struct fsl_ep’ has no member > named ‘desc’ > > > my proposed regression patch: > --- > From: Christoph Fritz > Date: Mon, 4 Jun 2012 12:58:21 +0200 > Subject: [PATCH] usb: gadget: regression fix - useage of usb_ep > > This patch removes redundant pointer to struct usb_endpoint_descriptor which > were missed in commit 79149b8: > > usb: gadget: Update fsl_udc_core to use usb_endpoint_descriptor inside the > struct usb_ep > > Signed-off-by: Christoph Fritz > --- > drivers/usb/gadget/fsl_udc_core.c |2 +- > drivers/usb/gadget/fsl_usb2_udc.h |4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/gadget/fsl_udc_core.c > b/drivers/usb/gadget/fsl_udc_core.c > index 2831685..678ec4d 100644 > --- a/drivers/usb/gadget/fsl_udc_core.c > +++ b/drivers/usb/gadget/fsl_udc_core.c > @@ -2575,7 +2575,7 @@ static int __init fsl_udc_probe(struct platform_device > *pdev) > /* for ep0: the desc defined here; >* for other eps, gadget layer called ep_enable with defined desc >*/ > - udc_controller->eps[0].desc = &fsl_ep0_desc; > + udc_controller->eps[0].ep.desc = &fsl_ep0_desc; > udc_controller->eps[0].ep.maxpacket = USB_MAX_CTRL_PAYLOAD; > > /* setup the udc->eps[] for non-control endpoints and link > diff --git a/drivers/usb/gadget/fsl_usb2_udc.h > b/drivers/usb/gadget/fsl_usb2_udc.h > index 5cd7b7e..f61a967 100644 > --- a/drivers/usb/gadget/fsl_usb2_udc.h > +++ b/drivers/usb/gadget/fsl_usb2_udc.h > @@ -568,10 +568,10 @@ static void dump_msg(const char *label, const u8 * buf, > unsigned int length) > /* > * ### internal used help routines. > */ > -#define ep_index(EP) ((EP)->desc->bEndpointAddress&0xF) > +#define ep_index(EP) ((EP)->ep.desc->bEndpointAddress&0xF) > #define ep_maxpacket(EP) ((EP)->ep.maxpacket) > #define ep_is_in(EP) ( (ep_index(EP) == 0) ? (EP->udc->ep0_dir == \ > - USB_DIR_IN ):((EP)->desc->bEndpointAddress \ > + USB_DIR_IN) : ((EP)->ep.desc->bEndpointAddress \ > & USB_DIR_IN)==USB_DIR_IN) > #define get_ep_by_pipe(udc, pipe)((pipe == 1)? &udc->eps[0]: \ > &udc->eps[pipe]) > -- > 1.7.2.5 Please send as a proper patch so I can apply. -- balbi signature.asc Description: Digital signature ___ Linuxppc-de
[PATCH] usb: gadget: regression fix - useage of usb_ep
This patch removes redundant pointer to struct usb_endpoint_descriptor which were missed in commit 79149b8: usb: gadget: Update fsl_udc_core to use usb_endpoint_descriptor inside the struct usb_ep Due to clock framework regressions, this patch is only compile tested! Signed-off-by: Christoph Fritz --- drivers/usb/gadget/fsl_udc_core.c |2 +- drivers/usb/gadget/fsl_usb2_udc.h |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index 2831685..678ec4d 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -2575,7 +2575,7 @@ static int __init fsl_udc_probe(struct platform_device *pdev) /* for ep0: the desc defined here; * for other eps, gadget layer called ep_enable with defined desc */ - udc_controller->eps[0].desc = &fsl_ep0_desc; + udc_controller->eps[0].ep.desc = &fsl_ep0_desc; udc_controller->eps[0].ep.maxpacket = USB_MAX_CTRL_PAYLOAD; /* setup the udc->eps[] for non-control endpoints and link diff --git a/drivers/usb/gadget/fsl_usb2_udc.h b/drivers/usb/gadget/fsl_usb2_udc.h index 5cd7b7e..f61a967 100644 --- a/drivers/usb/gadget/fsl_usb2_udc.h +++ b/drivers/usb/gadget/fsl_usb2_udc.h @@ -568,10 +568,10 @@ static void dump_msg(const char *label, const u8 * buf, unsigned int length) /* * ### internal used help routines. */ -#define ep_index(EP) ((EP)->desc->bEndpointAddress&0xF) +#define ep_index(EP) ((EP)->ep.desc->bEndpointAddress&0xF) #define ep_maxpacket(EP) ((EP)->ep.maxpacket) #define ep_is_in(EP) ( (ep_index(EP) == 0) ? (EP->udc->ep0_dir == \ - USB_DIR_IN ):((EP)->desc->bEndpointAddress \ + USB_DIR_IN) : ((EP)->ep.desc->bEndpointAddress \ & USB_DIR_IN)==USB_DIR_IN) #define get_ep_by_pipe(udc, pipe) ((pipe == 1)? &udc->eps[0]: \ &udc->eps[pipe]) -- 1.7.2.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 2/5] powerpc/85xx: add HOTPLUG_CPU support
On 06/04/2012 06:04 AM, Zhao Chenhui wrote: > On Fri, Jun 01, 2012 at 04:27:27PM -0500, Scott Wood wrote: >> On 05/11/2012 06:53 AM, Zhao Chenhui wrote: >>> -#ifdef CONFIG_KEXEC >>> +#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU) >> >> Let's not grow lists like this. Is there any harm in building it >> unconditionally? >> >> -Scott > > We need this ifdef. We only set give_timebase/take_timebase > when CONFIG_KEXEC or CONFIG_HOTPLUG_CPU is defined. If we really need this to be a compile-time decision, make a new symbol for it, but I really think this should be decided at runtime. Just because we have kexec or hotplug support enabled doesn't mean that's actually what we're doing at the moment. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Cannot boot an kernel version other than 2.6.35 on P2020RDB-PCA
Hello all, I am currently working on the Freescale P2020RDB-PCA Board, which has been delivred with the linux-2.6.35 kernel. I succeed in re-generating my own uImage in 2.6.35 thanks to ELDK, but when I want to move on to a newer or older version of linux, the system does not respond any longer just after the boot whith the nfsboot command, the logs are : ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-2.6.39 Created: 2012-05-29 8:24:54 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:3514882 Bytes = 3.4 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 00c0 Booting using the fdt blob at 0xc0 Uncompressing Kernel Image ... OK Loading Device Tree to 00ffa000, end 00fffd4a ... OK NB : nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.1:$rootpath ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:P2020RDB-PC:eth0:off console=ttyS0,115200 I have unsuccessfully tried to rebuild the device tree blob and use the default kernel configuration "mpc85xx_defconfig" that comes with the mainline code. My systems seems to be linux-2.6.35 dependent, I do not known how it can be possible, because I can use the kernel.org source of the 2.6.35 whith no problems but when I use the 3.0, for example, with the same configuration but it does not work. Best regards, Cedric MAUSSIRE ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Serial RAPID IO kernel hang on maintenance read transaction
On 06/01/2012 04:40 PM, Proicou, Mike wrote: > > I've been struggling with a kernel hang during bootup + enumeration of > a Rapid IO system. > > My current system contains a N.A.T MCH (using the IDT/Tundra Tsi 578 > switch) and a Vadatech AMC719 card using the Freescale P4080 > processor. There will be other cards added to the system, but I'm > testing with just this for now. > > I'm using a Linux kernel version 2.6.34.6. I've set riohdid=0 on the > kernel command line, and I'm expecting Linux to fully enumerate and > configure the Rapid IO fabric. (This may be a bad assumption on my part.) > > After lots of tracing, I've determined that the kernel is hanging on > the first maintenance transaction to the switch. The hang will often > be followed by a "machine check in kernel mode" exception and panic. > Though we're running the 3.0.6 kernel we encountered an almost identical situation and the crash/traceback also appears to be the same. In our case, the lock-up was due to a bug in the Freescale machine check exception handler and the trigger for this was an AckID mis-match on our switch ports. Specifically, the AckID mis-matched triggered an sRIO error. This triggers a machine check via the routine machine_check_e500mc. This routine checks to see if the MCSR_BUS_RBERR flag in SPRN_MCSR is set to determine if it should run the fsl_rio_mcheck_exception code which will handle the fixups to keep the machine check from crashing the system. However, what I found out was the MCSR_BUS_RBERR is a BookE architecture bit that isn't implemented on the powerPC architecture--or at least on the p4080/e500MC processor/core specifically. In fact, as near as I can determine, the only clue you have that this is a rapidio error is the fact that you've received a machine check error--though I'm sure there's something clever that could be done to narrow it down a bit better. So basically, you have to modify the machine check handler to decide whether or not to call the fsl_rio_mcheck_exception code based on the rapidIO error registers (SRIO_LTLEDCSR and SRIO_PxESCSR) rather than on the SPRN_MCSR register. I handled this by hacking the machine check handler to always call the fsl_rio_mcheck_exception routine for any load/guarded load error--we weren't having issues with writes--and then modified the fsl_rio_mcheck_exception routine to do the fixups if there was a pending rapidio error and return the "recoverable" bit to the top level handler or "0" if a rapidio error wasn't detected; It's crude but it worked. Now, this didn't solve our whole problem in that the exception handler doesn't perform or setup any bus-recovery code, this just keeps the error from crashing your kernel. In the end, we disabled the default enumeration/discovery code and added our own code layered on top of the Freescale rio driver code--nothing that can or even should be submitted to a general code tree. It's messy, but we were tight on time, already had an existing driver that implemented custom functions for our stuff and didn't have to time to work out the proper kernel internals to change. I'm sorry I cannot give you anything more useful, but hopefully this will help a bit. Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel panic during kernel module load (powerpc specific part)
On Mon, 2012-06-04 at 13:03 +0200, Gabriel Paubert wrote: > There is no conflict to the ABI. These functions are supposed to be > directly reachable from whatever code > section may need them. > > Now I have a question: how did you get the need for this? > > None of my kernels uses them: > - if I compile with -O2, the compiler simply expands epilogue and > prologue to series of lwz and stw > - if I compile with -Os, the compiler generates lmw/stmw which give > the smallest possible cache footprint > > Neither did I find a single reference to these functions in several > systems that I grepped for. Newer gcc's ... even worse, with -Os, it does it for a single register spill afaik. At least that's how I hit it with grub2 using whatever gcc is in fc17. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 3/5] powerpc/85xx: add sleep and deep sleep support
On 06/04/2012 06:12 AM, Zhao Chenhui wrote:
> On Fri, Jun 01, 2012 at 04:54:35PM -0500, Scott Wood wrote:
>> On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
>>> diff --git a/arch/powerpc/include/asm/cacheflush.h
>>> b/arch/powerpc/include/asm/cacheflush.h
>>> index 94ec20a..baa000c 100644
>>> --- a/arch/powerpc/include/asm/cacheflush.h
>>> +++ b/arch/powerpc/include/asm/cacheflush.h
>>> @@ -33,6 +33,11 @@ extern void flush_dcache_page(struct page *page);
>>> #if defined(CONFIG_FSL_BOOKE) || defined(CONFIG_6xx)
>>> extern void __flush_disable_L1(void);
>>> #endif
>>> +#if defined(CONFIG_FSL_BOOKE)
>>> +extern void flush_dcache_L1(void);
>>> +#else
>>> +#define flush_dcache_L1() do { } while (0)
>>> +#endif
>>
>> It doesn't seem right to no-op this on other platforms.
>
> The pmc_suspend_enter() in fsl_pmc.c used by mpc85xx and mpc86xx,
> but flush_dcache_L1() have no definition in mpc86xx platform.
> I will write flush_dcache_L1() for mpc86xx platform.
How about only calling the function when it's needed? If we didn't need
an L1 flush here on 86xx before, why do we need it now?
>>> extern void __flush_icache_range(unsigned long, unsigned long);
>>> static inline void flush_icache_range(unsigned long start, unsigned long
>>> stop)
>>> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
>>> index f5808a3..cb70dba 100644
>>> --- a/arch/powerpc/kernel/Makefile
>>> +++ b/arch/powerpc/kernel/Makefile
>>> @@ -64,6 +64,9 @@ obj-$(CONFIG_FA_DUMP) += fadump.o
>>> ifeq ($(CONFIG_PPC32),y)
>>> obj-$(CONFIG_E500) += idle_e500.o
>>> endif
>>> +ifneq ($(CONFIG_PPC_E500MC),y)
>>> +obj-$(CONFIG_PPC_85xx) += l2cache_85xx.o
>>> +endif
>>
>> Can we introduce a symbol that specifically means pre-e500mc e500,
>> rather than using negative logic?
>>
>> I think something like CONFIG_PPC_E500_V1_V2 has been proposed before.
>
> Agree. But CONFIG_PPC_E500_V1_V2 haven't been merged.
Has the concept been NACKed, or just forgotten? If the latter, you
could include it in this patchset.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source
On 06/04/2012 06:36 AM, Zhao Chenhui wrote:
> On Fri, Jun 01, 2012 at 05:08:52PM -0500, Scott Wood wrote:
>> On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
>>> Add APIs for setting wakeup source and lossless Ethernet in low power modes.
>>> These APIs can be used by wake-on-packet feature.
>>>
>>> Signed-off-by: Dave Liu
>>> Signed-off-by: Li Yang
>>> Signed-off-by: Jin Qing
>>> Signed-off-by: Zhao Chenhui
>>> ---
>>> arch/powerpc/sysdev/fsl_pmc.c | 71
>>> -
>>> arch/powerpc/sysdev/fsl_soc.h |9 +
>>> 2 files changed, 79 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/powerpc/sysdev/fsl_pmc.c b/arch/powerpc/sysdev/fsl_pmc.c
>>> index 1dc6e9e..c1170f7 100644
>>> --- a/arch/powerpc/sysdev/fsl_pmc.c
>>> +++ b/arch/powerpc/sysdev/fsl_pmc.c
>>> @@ -34,6 +34,7 @@ struct pmc_regs {
>>> __be32 powmgtcsr;
>>> #define POWMGTCSR_SLP 0x0002
>>> #define POWMGTCSR_DPSLP0x0010
>>> +#define POWMGTCSR_LOSSLESS 0x0040
>>> __be32 res3[2];
>>> __be32 pmcdr;
>>> };
>>> @@ -43,6 +44,74 @@ static unsigned int pmc_flag;
>>>
>>> #define PMC_SLEEP 0x1
>>> #define PMC_DEEP_SLEEP 0x2
>>> +#define PMC_LOSSLESS 0x4
>>> +
>>> +/**
>>> + * mpc85xx_pmc_set_wake - enable devices as wakeup event source
>>> + * @pdev: platform device affected
>>> + * @enable: True to enable event generation; false to disable
>>> + *
>>> + * This enables the device as a wakeup event source, or disables it.
>>> + *
>>> + * RETURN VALUE:
>>> + * 0 is returned on success
>>> + * -EINVAL is returned if device is not supposed to wake up the system
>>> + * Error code depending on the platform is returned if both the platform
>>> and
>>> + * the native mechanism fail to enable the generation of wake-up events
>>> + */
>>> +int mpc85xx_pmc_set_wake(struct platform_device *pdev, bool enable)
>>
>> Why does it have to be a platform_device? Would a bare device_node work
>> here? If it's for stuff like device_may_wakeup() that could be in a
>> platform_device wrapper function.
>
> It does not have to be a platform_device. I think it can be a struct device.
Why does it even need that? The low level mechanism for influencing
PMCDR should only need a device node, not a Linux device struct.
>> Where does this get called from? I don't see an example user in this
>> patchset.
>
> It will be used by a gianfar related patch. I plan to submit that patch
> after these patches accepted.
It would be nice to see how this is used when reviewing this.
>>> +{
>>> + int ret = 0;
>>> + struct device_node *clk_np;
>>> + u32 *prop;
>>> + u32 pmcdr_mask;
>>> +
>>> + if (!pmc_regs) {
>>> + pr_err("%s: PMC is unavailable\n", __func__);
>>> + return -ENODEV;
>>> + }
>>> +
>>> + if (enable && !device_may_wakeup(&pdev->dev))
>>> + return -EINVAL;
>>
>> Who is setting can_wakeup for these devices?
>
> The device driver is responsible to set can_wakeup.
How would the device driver know how to set it? Wouldn't this depend on
the particular SoC and low power mode?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Optimise the 64bit optimised __clear_user
I blame Mikey for this. He elevated my slightly dubious testcase: # dd if=/dev/zero of=/dev/null bs=1M count=1 to benchmark status. And naturally we need to be number 1 at creating zeros. So lets improve __clear_user some more. As Paul suggests we can use dcbz for large lengths. This patch gets the destination cacheline aligned then uses dcbz on whole cachelines. Before: 1048576 bytes (10 GB) copied, 0.414744 s, 25.3 GB/s After: 1048576 bytes (10 GB) copied, 0.268597 s, 39.0 GB/s 39 GB/s, a new record. Signed-off-by: Anton Blanchard --- v2: handle any cacheline size Index: linux-build/arch/powerpc/lib/string_64.S === --- linux-build.orig/arch/powerpc/lib/string_64.S 2012-06-04 16:18:56.351604302 +1000 +++ linux-build/arch/powerpc/lib/string_64.S2012-06-05 11:42:10.044654851 +1000 @@ -19,6 +19,12 @@ */ #include +#include + + .section".toc","aw" +PPC64_CACHES: + .tc ppc64_caches[TC],ppc64_caches + .section".text" /** * __clear_user: - Zero a block of memory in user space, with less checking. @@ -94,9 +100,14 @@ err1; stw r0,0(r3) addir3,r3,4 3: sub r4,r4,r6 - srdir6,r4,5 + cmpdi r4,32 + cmpdi cr1,r4,512 blt .Lshort_clear + bgt cr1,.Llong_clear + +.Lmedium_clear: + srdir6,r4,5 mtctr r6 /* Do 32 byte chunks */ @@ -139,3 +150,53 @@ err1; stb r0,0(r3) 10:li r3,0 blr + +.Llong_clear: + ld r5,PPC64_CACHES@toc(r2) + + bf cr7*4+0,11f +err2; std r0,0(r3) + addir3,r3,8 + addir4,r4,-8 + + /* Destination is 16 byte aligned, need to get it cacheline aligned */ +11:lwz r7,DCACHEL1LOGLINESIZE(r5) + lwz r9,DCACHEL1LINESIZE(r5) + + /* +* With worst case alignment the long clear loop takes a minimum +* of 1 byte less than 2 cachelines. +*/ + sldir10,r9,2 + cmpdr4,r10 + blt .Lmedium_clear + + neg r6,r3 + addir10,r9,-1 + and.r5,r6,r10 + beq 13f + + srdir6,r5,4 + mtctr r6 + mr r8,r3 +12: +err1; std r0,0(r3) +err1; std r0,8(r3) + addir3,r3,16 + bdnz12b + + sub r4,r4,r5 + +13:srd r6,r4,r7 + mtctr r6 + mr r8,r3 +14: +err1; dcbzr0,r3 + add r3,r3,r9 + bdnz14b + + and r4,r4,r10 + + cmpdi r4,32 + blt .Lshort_clear + b .Lmedium_clear ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/ftrace: Do not trace restore_interrupts()
As I was adding code that affects all archs, I started testing function
tracer against PPC64 and found that it currently locks up with 3.4
kernel. I figured it was due to tracing a function that shouldn't be, so
I went through the following process to bisect to find the culprit:
cat /debug/tracing/available_filter_functions > t
num=`wc -l t`
sed -ne "1,${num}p" t > t1
let num=num+1
sed -ne "${num},$p" t > t2
cat t1 > /debug/tracing/set_ftrace_filter
echo function /debug/tracing/current_tracer
It finally came down to this function: restore_interrupts()
I'm not sure why this locks up the system. It just seems to prevent
scheduling from occurring. Interrupts seem to still work, as I can ping
the box. But all user processes freeze.
When restore_interrupts() is not traced, function tracing works fine.
Cc: sta...@kernel.org
Signed-off-by: Steven Rostedt
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 641da9e..64eec59 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -277,7 +277,7 @@ EXPORT_SYMBOL(arch_local_irq_restore);
* NOTE: This is called with interrupts hard disabled but not marked
* as such in paca->irq_happened, so we need to resync this.
*/
-void restore_interrupts(void)
+void notrace restore_interrupts(void)
{
if (irqs_disabled()) {
local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ftrace: Do not trace restore_interrupts()
On Mon, 2012-06-04 at 22:27 -0400, Steven Rostedt wrote:
> As I was adding code that affects all archs, I started testing function
> tracer against PPC64 and found that it currently locks up with 3.4
> kernel. I figured it was due to tracing a function that shouldn't be, so
> I went through the following process to bisect to find the culprit:
>
> cat /debug/tracing/available_filter_functions > t
> num=`wc -l t`
> sed -ne "1,${num}p" t > t1
> let num=num+1
> sed -ne "${num},$p" t > t2
> cat t1 > /debug/tracing/set_ftrace_filter
> echo function /debug/tracing/current_tracer
>
>
> It finally came down to this function: restore_interrupts()
>
> I'm not sure why this locks up the system. It just seems to prevent
> scheduling from occurring. Interrupts seem to still work, as I can ping
> the box. But all user processes freeze.
>
> When restore_interrupts() is not traced, function tracing works fine.
>
> Cc: sta...@kernel.org
This is what I get for cut-and-pasting from a random git commit. That
should be:
Cc: sta...@vger.kernel.org
-- Steve
> Signed-off-by: Steven Rostedt
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 641da9e..64eec59 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -277,7 +277,7 @@ EXPORT_SYMBOL(arch_local_irq_restore);
> * NOTE: This is called with interrupts hard disabled but not marked
> * as such in paca->irq_happened, so we need to resync this.
> */
> -void restore_interrupts(void)
> +void notrace restore_interrupts(void)
> {
> if (irqs_disabled()) {
> local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: pseries: Round up MSI-X requests
Hi,
> On Mon, 2012-06-04 at 16:43 +1000, Michael Ellerman wrote:
> > There is some chance this will result in breakage because the driver
> > asks for N - and assumes that is what was allocated - and the
> > device is configured for > N.
>
> We can fix that. We can whack the configuration back with N, just know
> that we have "allocated" > N.
I agree we don't want to be giving back a larger value than requested.
There's only one place that can happen in theory and since firmware only
returns power of two values I dont think it will happen in practise.
Even so do we want to do something like this (as yet untested)? If the
rounded up request fails we retry with the original request.
The pseries msi free code just sets our vectors to 0 so it doesn't need
to know how many were originally allocated.
Anton
--
[PATCH] powerpc: pseries: Round up MSI-X requests
The pseries firmware currently refuses any non power of two MSI-X
request. Unfortunately most network drivers end up asking for that
because they want a power of two for RX queues and one or two extra
for everything else.
This patch rounds up the firmware request to the next power of two
if the quota allows it. If this fails we fall back to using the
original request size.
Signed-off-by: Anton Blanchard
---
Index: linux-build/arch/powerpc/platforms/pseries/msi.c
===
--- linux-build.orig/arch/powerpc/platforms/pseries/msi.c 2012-06-04
15:58:48.095833249 +1000
+++ linux-build/arch/powerpc/platforms/pseries/msi.c2012-06-05
12:15:58.711074499 +1000
@@ -387,12 +387,13 @@ static int check_msix_entries(struct pci
return 0;
}
-static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type)
{
struct pci_dn *pdn;
int hwirq, virq, i, rc;
struct msi_desc *entry;
struct msi_msg msg;
+ int nvec = nvec_in;
pdn = get_pdn(pdev);
if (!pdn)
@@ -402,10 +403,23 @@ static int rtas_setup_msi_irqs(struct pc
return -EINVAL;
/*
+* Firmware currently refuse any non power of two allocation
+* so we round up if the quota will allow it.
+*/
+ if (type == PCI_CAP_ID_MSIX) {
+ int m = roundup_pow_of_two(nvec);
+ int quota = msi_quota_for_device(pdev, m);
+
+ if (quota >= m)
+ nvec = m;
+ }
+
+ /*
* Try the new more explicit firmware interface, if that fails fall
* back to the old interface. The old interface is known to never
* return MSI-Xs.
*/
+again:
if (type == PCI_CAP_ID_MSI) {
rc = rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, nvec);
@@ -417,6 +431,10 @@ static int rtas_setup_msi_irqs(struct pc
rc = rtas_change_msi(pdn, RTAS_CHANGE_MSIX_FN, nvec);
if (rc != nvec) {
+ if (nvec != nvec_in) {
+ nvec = nvec_in;
+ goto again;
+ }
pr_debug("rtas_msi: rtas_change_msi() failed\n");
return rc;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, June 05, 2012 7:03 AM
> To: Zhao Chenhui-B35336
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org;
> ga...@kernel.crashing.org; Li Yang-R58472
> Subject: Re: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup
> event source
>
> On 06/04/2012 06:36 AM, Zhao Chenhui wrote:
> > On Fri, Jun 01, 2012 at 05:08:52PM -0500, Scott Wood wrote:
> >> On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
> >>> Add APIs for setting wakeup source and lossless Ethernet in low power
> modes.
> >>> These APIs can be used by wake-on-packet feature.
> >>>
> >>> Signed-off-by: Dave Liu
> >>> Signed-off-by: Li Yang
> >>> Signed-off-by: Jin Qing
> >>> Signed-off-by: Zhao Chenhui
> >>> ---
> >>> arch/powerpc/sysdev/fsl_pmc.c | 71
> -
> >>> arch/powerpc/sysdev/fsl_soc.h |9 +
> >>> 2 files changed, 79 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/arch/powerpc/sysdev/fsl_pmc.c
> b/arch/powerpc/sysdev/fsl_pmc.c
> >>> index 1dc6e9e..c1170f7 100644
> >>> --- a/arch/powerpc/sysdev/fsl_pmc.c
> >>> +++ b/arch/powerpc/sysdev/fsl_pmc.c
> >>> @@ -34,6 +34,7 @@ struct pmc_regs {
> >>> __be32 powmgtcsr;
> >>> #define POWMGTCSR_SLP0x0002
> >>> #define POWMGTCSR_DPSLP 0x0010
> >>> +#define POWMGTCSR_LOSSLESS 0x0040
> >>> __be32 res3[2];
> >>> __be32 pmcdr;
> >>> };
> >>> @@ -43,6 +44,74 @@ static unsigned int pmc_flag;
> >>>
> >>> #define PMC_SLEEP0x1
> >>> #define PMC_DEEP_SLEEP 0x2
> >>> +#define PMC_LOSSLESS 0x4
> >>> +
> >>> +/**
> >>> + * mpc85xx_pmc_set_wake - enable devices as wakeup event source
> >>> + * @pdev: platform device affected
> >>> + * @enable: True to enable event generation; false to disable
> >>> + *
> >>> + * This enables the device as a wakeup event source, or disables it.
> >>> + *
> >>> + * RETURN VALUE:
> >>> + * 0 is returned on success
> >>> + * -EINVAL is returned if device is not supposed to wake up the
> system
> >>> + * Error code depending on the platform is returned if both the
> platform and
> >>> + * the native mechanism fail to enable the generation of wake-up
> events
> >>> + */
> >>> +int mpc85xx_pmc_set_wake(struct platform_device *pdev, bool enable)
> >>
> >> Why does it have to be a platform_device? Would a bare device_node
> work
> >> here? If it's for stuff like device_may_wakeup() that could be in a
> >> platform_device wrapper function.
> >
> > It does not have to be a platform_device. I think it can be a struct
> device.
>
> Why does it even need that? The low level mechanism for influencing
> PMCDR should only need a device node, not a Linux device struct.
It does no harm to pass the device structure and makes more sense for object
oriented interface design.
>
> >> Where does this get called from? I don't see an example user in this
> >> patchset.
> >
> > It will be used by a gianfar related patch. I plan to submit that patch
> > after these patches accepted.
>
> It would be nice to see how this is used when reviewing this.
>
> >>> +{
> >>> + int ret = 0;
> >>> + struct device_node *clk_np;
> >>> + u32 *prop;
> >>> + u32 pmcdr_mask;
> >>> +
> >>> + if (!pmc_regs) {
> >>> + pr_err("%s: PMC is unavailable\n", __func__);
> >>> + return -ENODEV;
> >>> + }
> >>> +
> >>> + if (enable && !device_may_wakeup(&pdev->dev))
> >>> + return -EINVAL;
> >>
> >> Who is setting can_wakeup for these devices?
> >
> > The device driver is responsible to set can_wakeup.
>
> How would the device driver know how to set it? Wouldn't this depend on
> the particular SoC and low power mode?
It is based on the "fsl,magic-packet" and "fsl,wake-on-filer" device tree
properties.
Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Cannot boot an kernel version other than 2.6.35 on P2020RDB-PCA
Hi Cedric MAUSSIRE, P2020RDB-PCA Board gets supported since kernel 3.3 in mainline code. Are you sure the board works on kernel 2.6.35? Regards, Yuantian From: linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org] On Behalf Of MAUSSIRE Cedric Sent: 2012年6月4日 23:06 To: linuxppc-dev@lists.ozlabs.org Subject: Cannot boot an kernel version other than 2.6.35 on P2020RDB-PCA Hello all, I am currently working on the Freescale P2020RDB-PCA Board, which has been delivred with the linux-2.6.35 kernel. I succeed in re-generating my own uImage in 2.6.35 thanks to ELDK, but when I want to move on to a newer or older version of linux, the system does not respond any longer just after the boot whith the nfsboot command, the logs are : ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-2.6.39 Created: 2012-05-29 8:24:54 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:3514882 Bytes = 3.4 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 00c0 Booting using the fdt blob at 0xc0 Uncompressing Kernel Image ... OK Loading Device Tree to 00ffa000, end 00fffd4a ... OK NB : nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.1:$rootpath ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:P2020RDB-PC:eth0:off console=ttyS0,115200 I have unsuccessfully tried to rebuild the device tree blob and use the default kernel configuration "mpc85xx_defconfig" that comes with the mainline code. My systems seems to be linux-2.6.35 dependent, I do not known how it can be possible, because I can use the kernel.org source of the 2.6.35 whith no problems but when I use the 3.0, for example, with the same configuration but it does not work. Best regards, Cedric MAUSSIRE ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
