* Re: [PATCH] powerpc: Don't use alloc_bootmem() in init_IRQ() path
From: Anton Vorontsov @ 2009-07-01 21:28 UTC (permalink / raw)
To: Timur Tabi
Cc: Arnd Bergmann, Ira Snyder, linuxppc-dev, Andrey Gusev,
Geert Uytterhoeven
In-Reply-To: <4A4BD187.8000605@freescale.com>
On Wed, Jul 01, 2009 at 04:13:43PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> > diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
> > index 63cdf98..074905c 100644
> > --- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
> > +++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
> > @@ -333,12 +333,10 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags,
> > if (ret)
> > return;
> >
> > - qe_ic = alloc_bootmem(sizeof(struct qe_ic));
> > + qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
>
> This function is called during init_IRQ() in main.c.
That's the main point of this patch (as subject says). Nowadays
init_IRQ() is called with kernel allocator available, so we
shouldn't use alloc_bootmem() anymore.
> Looking at the code, I don't see any earlier calls to kzalloc().
You seem to be looking into an outdated kernel. ;-) IIRC, the
first caller of kzalloc() in init_IRQ() path appeared in
commit 85355bb272db31a3f2dd99d547eef794805e1319
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Jun 18 22:01:20 2009 +0000
powerpc: Fix mpic alloc warning
> Are you sure this is supposed
> to work?
This was boot-tested on real HW. :-)
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use alloc_bootmem() in init_IRQ() path
From: Anton Vorontsov @ 2009-07-01 21:30 UTC (permalink / raw)
To: Kumar Gala
Cc: Arnd Bergmann, Ira Snyder, linuxppc-dev, Andrey Gusev,
Geert Uytterhoeven, Timur Tabi
In-Reply-To: <0B693A82-F60B-4451-9747-1A54EAB64FEC@kernel.crashing.org>
On Wed, Jul 01, 2009 at 04:25:22PM -0500, Kumar Gala wrote:
>
> On Jul 1, 2009, at 3:59 PM, Anton Vorontsov wrote:
>
> >qe_ic is in the same boat, just as every other PIC controller. Heh..
> >doing some 'grep alloc_bootmem', it seems that there are pretty
> >much offenders. Let's fix them?
> >
> >arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 2 +-
> >arch/powerpc/sysdev/ipic.c | 4 +---
> >arch/powerpc/sysdev/mpic.c | 9 ++++-----
> >arch/powerpc/sysdev/qe_lib/qe_ic.c | 4 +---
> >arch/powerpc/sysdev/uic.c | 3 +--
> >5 files changed, 8 insertions(+), 14 deletions(-)
>
> mpic should already be fixed.. I just thing the pull occurred after
> -rc1 because of Ben being sick.
Fixed by this?
commit 85355bb272db31a3f2dd99d547eef794805e1319
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Jun 18 22:01:20 2009 +0000
powerpc: Fix mpic alloc warning
Then this isn't enough. There were two more calls of alloc_bootmem()
in mpic.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* misaligned load/store in ppc32 memcpy
From: Kumar Gala @ 2009-06-30 21:56 UTC (permalink / raw)
To: Mark Nelson; +Cc: linuxppc-dev@ozlabs.org list
[-- Attachment #1: Type: text/html, Size: 493 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use alloc_bootmem() in init_IRQ() path
From: Timur Tabi @ 2009-07-01 21:47 UTC (permalink / raw)
To: avorontsov
Cc: Arnd Bergmann, Ira Snyder, linuxppc-dev, Andrey Gusev,
Geert Uytterhoeven
In-Reply-To: <20090701212858.GA28455@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> That's the main point of this patch (as subject says).
Yes, I see that now. :-)
> You seem to be looking into an outdated kernel. ;-) IIRC, the
> first caller of kzalloc() in init_IRQ() path appeared in
Yes, you're right.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use alloc_bootmem() in init_IRQ() path
From: Timur Tabi @ 2009-07-01 21:48 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090701205957.GA9583@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> This patch fixes various badnesses like this for all interrupt
> controllers:
...
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Preemption question (4xx related)
From: Benjamin Herrenschmidt @ 2009-07-01 22:13 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <24271342.post@talk.nabble.com>
On Tue, 2009-06-30 at 05:55 -0700, Felix Radensky wrote:
> Hi,
>
> Preemption is disabled on the vast majority of powerpc
> targets. Are there any known problems in this area ?
> I'd like to enable CONFIG_PREEMPT_VOLUNTARY on
> AMCC 405EX target, to increase application responsiveness.
> Is it a bad idea ?
In theory it should work, but as you may have noticed, it's generally
disabled and thus not very well tested.
It would be a good idea for us, some of the core devs, to turn that on
in our usual test configs in fact.
Cheers,
Ben.
^ permalink raw reply
* Re: PCI device support in Open Firmware (device tree syntax)
From: Benjamin Herrenschmidt @ 2009-07-01 22:15 UTC (permalink / raw)
To: Johnny Hung; +Cc: Marco Stornelli, linuxppc-dev, linux-embedded
In-Reply-To: <cb9ecdfa0906300033x4dfcc315gfd67522b77f6004a@mail.gmail.com>
> You are right. u-boot do PCI device BAR resources assign and flat
> device tree describe PCI device interrupt-map. I use "lspci -s xxx -x"
> for the PCI device, the resources was assigned properly.
Note that the device-tree -can- contain PCI devices, but it's not
mandatory.
If your bootloader does the probing and configuration of the PCI bus, it
might be a good idea for that bootloader to also create the PCI device
nodes in the tree, since this will allow in a near future the kernel to
"instanciate" them from that tree instead of probing with config space,
which is faster and more reliably. (Currently only ppc64 does that but
it will become generic soon).
Cheers,
Ben.
^ permalink raw reply
* [Question] MPC8360: Enabling DMA for CompactFlash in IDE mode
From: Richard Retanubun @ 2009-07-01 22:31 UTC (permalink / raw)
To: Linuxppc-dev-mList
Hello,
I am running on an MPC8360 board with u-boot-2009.06 and linux-2.6.26-13.
The board is booting from nor flash and then u-boot configures UPM-A for compact flash in true-IDE mode
(based on the design of the MPC8349ITX eval board). The IRQ used is IRQ6.
I got this setup going fine, but now I wish to enable DMA support to the compact flash to speed it up.
The HW wired the compact flash's DMA_DREQ and DMA_DACK to the CPUs DMA_DREQ3 (PC[17]) and DMA_DACK3 (PC[0]).
I added this in u-boot to configure the pins to their DMA functions:
/* DMA Controller, channel 3 for compact flash */
{2, 0, 1, 0, 1}, /* DMA_DACK3n / PTP_ALARM1 */
{2, 17, 2, 0, 2}, /* DMA_DREQ3n / PTP_PPS2 */
In the dtb, I added the following for dma and compact flash
dma@82a8 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,elo-dma";
reg = <0x82a8 4>;
ranges = <0 0x8100 0x1a8>;
interrupt-parent = <&ipic>;
interrupts = <0x47 8>;
cell-index = <0>;
/* The dma-channels are offset from 0x8100 */
dma-channel@0 {
compatible = "fsl,elo-dma-channel";
reg = <0 0x80>;
interrupt-parent = <&ipic>;
interrupts = <0x47 8>;
};
dma-channel@80 {
compatible = "fsl,elo-dma-channel";
reg = <0x80 0x80>;
interrupt-parent = <&ipic>;
interrupts = <0x47 8>;
};
dma-channel@100 {
compatible = "fsl,elo-dma-channel";
reg = <0x100 0x80>;
interrupt-parent = <&ipic>;
interrupts = <0x47 8>;
};
dma-channel@180 {
compatible = "fsl,elo-dma-channel";
reg = <0x180 0x28>;
interrupt-parent = <&ipic>;
interrupts = <0x47 8>;
};
}; /* dma@82a8 */
/* CS2 = Compact FLash in PATA/IDE connection */
pata@2,0 {
device_type = "ata";
compatible = "ata-generic";
reg = <0x2 0x0 0x10 0x2 0x20c 0x4>;
reg-shift = <0x1>;
pio-mode = <0x6>;
interrupts = <0x16 0x8>;
interrupt-parent = <&ipic>;
};
I enabled the kernel's CONFIG_ATA, CONFIG_ATA_SFF, CONFIG_PATA_PLATFORM, CONFIG_PATA_OF_PLATFORM for the CF
I also enabled CONFIG_DMADEVICES and CONFIG_FSL_DMA
with all this in place, I got this on boot:
of-fsl-dma e00082a8.dma: Probe the Freescale DMA driver for fsl,elo-dma controller at e00082a8...
of-fsl-dma-channel e0008100.dma-channe: #0 (fsl,elo-dma-channel), irq 71
of-fsl-dma-channel e0008180.dma-channe: #1 (fsl,elo-dma-channel), irq 71
of-fsl-dma-channel e0008200.dma-channe: #2 (fsl,elo-dma-channel), irq 71
of-fsl-dma-channel e0008280.dma-channe: #3 (fsl,elo-dma-channel), irq 71
[snip]
scsi0 : pata_platform
ata1: PATA max PIO6 mmio cmd 0xf8008000 ctl 0xf800820c irq 27
ata1.00: ATA-4: SG9CF1GSME4IRUG, 20071016, max UDMA/100
ata1.00: 1989792 sectors, multi 0: LBA
ata1.00: configured for PIO
scsi 0:0:0:0: Direct-Access ATA SG9CF1GSME4IRUG 2007 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 1989792 512-byte hardware sectors (1019 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 1989792 512-byte hardware sectors (1019 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
sd 0:0:0:0: [sda] Attached SCSI disk
[snip]
However, I don't think the CPU is using DMA channel 3 to speed up CF access
I tried doing "dd if=/dev/sda5 of=/dev/sda7 bs=4KB"
which copied 493MB at 2.5 MB/s with top showing about 75% CPU usage.
So, what am I missing?
(my guess is the glue between the DMA engine and the Compact flash,
but I'm not sure how to hook it up).
Thank you very much for everyone's time.
Richard Retanubun
-----------------
RuggedCom
30 Whitmore Road,Woodbdrige
Ontario, Canada
^ permalink raw reply
* Instruction machine check during NAND access on 405EX
From: Felix Radensky @ 2009-07-01 22:52 UTC (permalink / raw)
To: linuxppc-dev, Sean MacLennan
Hi,
I'm getting the following error on custom 405EX based system
running 2.6.30 kernel. It happens rarely, only on boot, while
mounting 250M ubifs partition. It happens also with jffs2.
To me it looks like some callback pointer is corrupted, but
I cannot see any problem in the code. Any ideas about what
goes wrong here are much appreciated.
Thanks a lot
Felix.
Creating 4 MTD partitions on "f8000000.ndfc.nand":
0x00000000-0x0fa00000 : "ROOT_1"
0x0fa00000-0x1f400000 : "ROOT_2"
0x1f400000-0x25800000 : "CONFIG"
0x25800000-0x3e800000 : "VAR"
UBI: attaching mtd6 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
Instruction machine check in kernel mode.
Oops: Machine check, sig: 7 [#1]
mlnx405ex
Modules linked in:
NIP: c0187840 LR: c018783c CTR: c018d1c0
REGS: dfffdf50 TRAP: 0202 Not tainted (2.6.27)
MSR: 00029030 <EE,ME,IR,DR> CR: 22022084 XER: 20000000
TASK = df82c000[1] 'swapper' THREAD: df82a000
GPR00: c018783c df82bc60 df82c000 00000000 df824080 df824040 df824000
000000ff
GPR08: 00000000 00000100 00000000 00000000 00000000 1004a354 c02a63ac
00000000
GPR16: 00000000 00000000 00000000 0000003f 00000000 df824080 c02fc974
00000003
GPR24: df824040 df824000 00000100 00000000 c0319b60 00000008 c0319c1c
df824080
NIP [c0187840] nand_read_page_hwecc+0x13c/0x174
LR [c018783c] nand_read_page_hwecc+0x138/0x174
Call Trace:
[df82bc60] [c018783c] nand_read_page_hwecc+0x138/0x174 (unreliable)
[df82bca0] [c018a6f0] nand_do_read_ops+0x15c/0x3dc
[df82bd00] [c018ad38] nand_read+0xa8/0xe4
[df82bd30] [c017f850] part_read+0x5c/0xe4
[df82bd40] [c0195e60] ubi_io_read+0x70/0x150
[df82bd80] [c0196360] ubi_io_read_ec_hdr+0x34/0x35c
[df82bdb0] [c0199604] ubi_scan+0x150/0x758
[df82be20] [c0190e58] ubi_attach_mtd_dev+0x340/0xb04
[df82bf10] [c02dd4e4] ubi_init+0x180/0x2d8
[df82bf60] [c0002368] do_one_initcall+0x38/0x188
[df82bfd0] [c02c617c] kernel_init+0x88/0xf4
[df82bff0] [c000dd60] kernel_thread+0x44/0x60
Instruction dump:
901c0094 7f7bba14 7fffd214 41820044 801e00b4 7fe4fb78 7cb8da14 7cd9da14
7c0903a6 7f83e378 4e800421 2c030000 <4080ffc4> 813c0098 37bdffff 39290001
---[ end trace 3d1f8dede54b62b1 ]---
^ permalink raw reply
* Re: Preemption question (4xx related)
From: Josh Boyer @ 2009-07-02 0:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Felix Radensky
In-Reply-To: <1246486393.14483.14.camel@pasglop>
On Thu, Jul 02, 2009 at 08:13:13AM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2009-06-30 at 05:55 -0700, Felix Radensky wrote:
>> Hi,
>>
>> Preemption is disabled on the vast majority of powerpc
>> targets. Are there any known problems in this area ?
>> I'd like to enable CONFIG_PREEMPT_VOLUNTARY on
>> AMCC 405EX target, to increase application responsiveness.
>> Is it a bad idea ?
>
>In theory it should work, but as you may have noticed, it's generally
>disabled and thus not very well tested.
>
>It would be a good idea for us, some of the core devs, to turn that on
>in our usual test configs in fact.
I've toyed with that idea myself. I keep coming back to the fact that you need
a workload that would really leverage it, and I don't have one at the moment.
josh
^ permalink raw reply
* Re: [PATCH 15/62] drivers/dma/fsldma.c: Remove unnecessary semicolons
From: Dan Williams @ 2009-07-02 0:27 UTC (permalink / raw)
To: Joe Perches
Cc: trivial, linuxppc-dev, Maciej Sosnowski, linux-kernel, Zhang Wei,
Andrew Morton, Li Yang
In-Reply-To: <03676ce0e272d44d1d4ea19639b28afb994c65eb.1246173680.git.joe@perches.com>
On Sun, Jun 28, 2009 at 9:26 AM, Joe Perches<joe@perches.com> wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> =A0drivers/dma/fsldma.c | =A0 =A02 +-
> =A01 files changed, 1 insertions(+), 1 deletions(-)
Applied 15 and 16.
Thanks,
Dan
^ permalink raw reply
* Re: misaligned load/store in ppc32 memcpy
From: Mark Nelson @ 2009-07-02 1:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <6ABDC992-9D67-4C9C-A3A7-59F408FC9E50@kernel.crashing.org>
Hi Kumar,
On Wednesday 01 July 2009 07:56:31 Kumar Gala wrote:
> Mark,
>
> Ben pointed me to you regarding my question if we should be expecting misaligned load/store operations in the ppc32 mempcy that exists in copy_32.S.
>
> (To be more specific, I'm seeing this behavior and wondering if we really should have memcpy avoid doing word size ld/st if the addresses aren't also aligned)
>
That's a good question; but because I don't really know very much about the
ppc32 cores that this memcpy routine was written and tested with (let alone
the newer embedded variations) I'll CC Paul and hopefully he can let us know :)
Thanks!
Mark
^ permalink raw reply
* [PATCH 2/2] KVM/PPC: Fix kvm_main.c build error for PPC KVM
From: Yang Shi @ 2009-07-02 2:55 UTC (permalink / raw)
To: yu.liu, hollisb, avi; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <47a7508d4561874c1a052cebe1b7f42b19831393.1246502441.git.yang.shi@windriver.com>
With the latest kernel building KVM for PPC, got integer overflow
error in kvm_main.c file. The root cause is that compiler consider
KVM_PAGES_PER_HPAGE as signed long type, however it should be
unsigned long type.
So, change it to unsigned long type in include/asm/kvm_host.h
Signed-off-by: Yang Shi <yang.shi@windriver.com>
---
arch/powerpc/include/asm/kvm_host.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index dfdf13c..fddc3ed 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -34,7 +34,7 @@
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
/* We don't currently support large pages. */
-#define KVM_PAGES_PER_HPAGE (1<<31)
+#define KVM_PAGES_PER_HPAGE (1UL << 31)
struct kvm;
struct kvm_run;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error
From: Yang Shi @ 2009-07-02 2:55 UTC (permalink / raw)
To: yu.liu, hollisb, avi; +Cc: linuxppc-dev, kvm, kvm-ppc
Since include/asm/mmu-fsl-booke.h was replaced by include/asm/mmu-book3e.h,
fix e500_tlb.h to reflect the change and fix e500_tlb.c to align with the
new page size macro definition in include/asm/mmu-book3e.h.
Signed-off-by: Yang Shi <yang.shi@windriver.com>
---
arch/powerpc/kvm/e500_tlb.c | 8 ++++----
arch/powerpc/kvm/e500_tlb.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index 0e773fc..616762b 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm/e500_tlb.c
@@ -309,7 +309,7 @@ static inline void kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
vcpu_e500->shadow_pages[tlbsel][esel] = new_page;
/* Force TS=1 IPROT=0 TSIZE=4KB for all guest mappings. */
- stlbe->mas1 = MAS1_TSIZE(BOOKE_PAGESZ_4K)
+ stlbe->mas1 = MAS1_TSIZE(BOOK3E_PAGESZ_4K)
| MAS1_TID(get_tlb_tid(gtlbe)) | MAS1_TS | MAS1_VALID;
stlbe->mas2 = (gvaddr & MAS2_EPN)
| e500_shadow_mas2_attrib(gtlbe->mas2,
@@ -545,7 +545,7 @@ int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *vcpu)
case 0:
/* TLB0 */
gtlbe->mas1 &= ~MAS1_TSIZE(~0);
- gtlbe->mas1 |= MAS1_TSIZE(BOOKE_PAGESZ_4K);
+ gtlbe->mas1 |= MAS1_TSIZE(BOOK3E_PAGESZ_4K);
stlbsel = 0;
sesel = kvmppc_e500_stlbe_map(vcpu_e500, 0, esel);
@@ -679,14 +679,14 @@ void kvmppc_e500_tlb_setup(struct kvmppc_vcpu_e500 *vcpu_e500)
/* Insert large initial mapping for guest. */
tlbe = &vcpu_e500->guest_tlb[1][0];
- tlbe->mas1 = MAS1_VALID | MAS1_TSIZE(BOOKE_PAGESZ_256M);
+ tlbe->mas1 = MAS1_VALID | MAS1_TSIZE(BOOK3E_PAGESZ_256M);
tlbe->mas2 = 0;
tlbe->mas3 = E500_TLB_SUPER_PERM_MASK;
tlbe->mas7 = 0;
/* 4K map for serial output. Used by kernel wrapper. */
tlbe = &vcpu_e500->guest_tlb[1][1];
- tlbe->mas1 = MAS1_VALID | MAS1_TSIZE(BOOKE_PAGESZ_4K);
+ tlbe->mas1 = MAS1_VALID | MAS1_TSIZE(BOOK3E_PAGESZ_4K);
tlbe->mas2 = (0xe0004500 & 0xFFFFF000) | MAS2_I | MAS2_G;
tlbe->mas3 = (0xe0004500 & 0xFFFFF000) | E500_TLB_SUPER_PERM_MASK;
tlbe->mas7 = 0;
diff --git a/arch/powerpc/kvm/e500_tlb.h b/arch/powerpc/kvm/e500_tlb.h
index 45b064b..abb1bf8 100644
--- a/arch/powerpc/kvm/e500_tlb.h
+++ b/arch/powerpc/kvm/e500_tlb.h
@@ -16,7 +16,7 @@
#define __KVM_E500_TLB_H__
#include <linux/kvm_host.h>
-#include <asm/mmu-fsl-booke.h>
+#include <asm/mmu-book3e.h>
#include <asm/tlb.h>
#include <asm/kvm_e500.h>
--
1.6.0.4
^ permalink raw reply related
* RE: [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error
From: Liu Yu-B13201 @ 2009-07-02 3:09 UTC (permalink / raw)
To: Yang Shi, hollisb, avi; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <47a7508d4561874c1a052cebe1b7f42b19831393.1246502441.git.yang.shi@windriver.com>
This fix is already accepted in kvm.git=20
> -----Original Message-----
> From: Yang Shi [mailto:yang.shi@windriver.com]=20
> Sent: Thursday, July 02, 2009 10:55 AM
> To: Liu Yu-B13201; hollisb@us.ibm.com; avi@redhat.com
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;=20
> linuxppc-dev@ozlabs.org
> Subject: [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error
>=20
> Since include/asm/mmu-fsl-booke.h was replaced by=20
> include/asm/mmu-book3e.h,
> fix e500_tlb.h to reflect the change and fix e500_tlb.c to=20
> align with the
> new page size macro definition in include/asm/mmu-book3e.h.
>=20
> Signed-off-by: Yang Shi <yang.shi@windriver.com>
> ---
> arch/powerpc/kvm/e500_tlb.c | 8 ++++----
> arch/powerpc/kvm/e500_tlb.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
> index 0e773fc..616762b 100644
> --- a/arch/powerpc/kvm/e500_tlb.c
> +++ b/arch/powerpc/kvm/e500_tlb.c
> @@ -309,7 +309,7 @@ static inline void=20
> kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
> vcpu_e500->shadow_pages[tlbsel][esel] =3D new_page;
> =20
> /* Force TS=3D1 IPROT=3D0 TSIZE=3D4KB for all guest mappings. */
> - stlbe->mas1 =3D MAS1_TSIZE(BOOKE_PAGESZ_4K)
> + stlbe->mas1 =3D MAS1_TSIZE(BOOK3E_PAGESZ_4K)
> | MAS1_TID(get_tlb_tid(gtlbe)) | MAS1_TS | MAS1_VALID;
> stlbe->mas2 =3D (gvaddr & MAS2_EPN)
> | e500_shadow_mas2_attrib(gtlbe->mas2,
> @@ -545,7 +545,7 @@ int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *vcpu)
> case 0:
> /* TLB0 */
> gtlbe->mas1 &=3D ~MAS1_TSIZE(~0);
> - gtlbe->mas1 |=3D MAS1_TSIZE(BOOKE_PAGESZ_4K);
> + gtlbe->mas1 |=3D MAS1_TSIZE(BOOK3E_PAGESZ_4K);
> =20
> stlbsel =3D 0;
> sesel =3D=20
> kvmppc_e500_stlbe_map(vcpu_e500, 0, esel);
> @@ -679,14 +679,14 @@ void kvmppc_e500_tlb_setup(struct=20
> kvmppc_vcpu_e500 *vcpu_e500)
> =20
> /* Insert large initial mapping for guest. */
> tlbe =3D &vcpu_e500->guest_tlb[1][0];
> - tlbe->mas1 =3D MAS1_VALID | MAS1_TSIZE(BOOKE_PAGESZ_256M);
> + tlbe->mas1 =3D MAS1_VALID | MAS1_TSIZE(BOOK3E_PAGESZ_256M);
> tlbe->mas2 =3D 0;
> tlbe->mas3 =3D E500_TLB_SUPER_PERM_MASK;
> tlbe->mas7 =3D 0;
> =20
> /* 4K map for serial output. Used by kernel wrapper. */
> tlbe =3D &vcpu_e500->guest_tlb[1][1];
> - tlbe->mas1 =3D MAS1_VALID | MAS1_TSIZE(BOOKE_PAGESZ_4K);
> + tlbe->mas1 =3D MAS1_VALID | MAS1_TSIZE(BOOK3E_PAGESZ_4K);
> tlbe->mas2 =3D (0xe0004500 & 0xFFFFF000) | MAS2_I | MAS2_G;
> tlbe->mas3 =3D (0xe0004500 & 0xFFFFF000) |=20
> E500_TLB_SUPER_PERM_MASK;
> tlbe->mas7 =3D 0;
> diff --git a/arch/powerpc/kvm/e500_tlb.h b/arch/powerpc/kvm/e500_tlb.h
> index 45b064b..abb1bf8 100644
> --- a/arch/powerpc/kvm/e500_tlb.h
> +++ b/arch/powerpc/kvm/e500_tlb.h
> @@ -16,7 +16,7 @@
> #define __KVM_E500_TLB_H__
> =20
> #include <linux/kvm_host.h>
> -#include <asm/mmu-fsl-booke.h>
> +#include <asm/mmu-book3e.h>
> #include <asm/tlb.h>
> #include <asm/kvm_e500.h>
> =20
> --=20
> 1.6.0.4
>=20
>=20
^ permalink raw reply
* Re: misaligned load/store in ppc32 memcpy
From: Paul Mackerras @ 2009-07-02 3:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: Mark Nelson, linuxppc-dev@ozlabs.org list
In-Reply-To: <6ABDC992-9D67-4C9C-A3A7-59F408FC9E50@kernel.crashing.org>
Kumar Gala writes:
> Ben pointed me to you regarding my question if we should be expecting
> misaligned load/store operations in the ppc32 mempcy that exists in
> copy_32.S.
> (To be more specific, I'm seeing this behavior and wondering if we
> really should have memcpy avoid doing word size ld/st if the addresses
> aren't also aligned)
We align the destination to a word boundary using byte-by-byte copies,
then copy words using word loads and stores. The loads may be
misaligned, but they are still faster than doing aligned loads and
shuffling the bits around - or at least they were when measured the
speed 10 years or so ago, which would have been on 750 or 74xx cpus.
If the penalty for unaligned loads on Freescale embedded cores is high
enough that it's faster to shuffle the bits or to copy byte-by-byte
then we can have an alternative version for them.
Paul.
^ permalink raw reply
* Re: [PATCH] [spi_mpc83xx] Always enable legacy support.
From: Joakim Tjernlund @ 2009-07-02 6:18 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090701211212.GA26231@oksana.dev.rtsoft.ru>
Anton Vorontsov <avorontsov@ru.mvista.com> wrote on 01/07/2009 23:12:12:
>
> On Wed, Jul 01, 2009 at 09:16:12PM +0200, Joakim Tjernlund wrote:
> > There are out of tree boards that need this legacy support too.
>
> Heh.
>
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> > I hope this is OK. I just discovered that spi didn't work for
> > me in 2.6.30 and I have no time to work on coverting my boards.
>
> I'd convert them for you if they were in-tree. :-) But I don't
> think that moving the kernel backwards because of out-of-tree
> boards is a good thing.
:), but allowing out-of-tree boards one or two kernel releases to catch up
with a legacy printout would have been nice.
>
> > I don't have a clue either on how to do that, any pointers
> > how to add a few spidev devices via OF?
>
> Something like this will work:
>
> spi@4c0 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> compatible = "fsl,spi";
> reg = <0x4c0 0x40>;
> interrupts = <2>;
> interrupt-parent = <&qeic>;
> /* provide chip-selects here */
> gpios = <&qe_pio_d 13 0 /* CS0 */
> &qe_pio_d 14 0>; /* CS1 */
> mode = "cpu-qe";
>
> device@0 {
> compatible = "spidev";
> reg = <0>; /* CS0*/
> spi-max-frequency = <50000000>;
> };
>
> device@0 {
> compatible = "spidev";
> reg = <1>; /* CS1 */
> spi-max-frequency = <50000000>;
> };
> };
>
> You can look at arch/powerpc/boot/dts/mpc832x_rdb.dts as an
> example.
>
> Note that "spidev" isn't correct compatible entry to use,
> but it's quick and dirty solution. A proper solution is to
> add a proper compatible entry into the device-tree, and
> add "spidev" alias into drivers/of/base.c:of_modalias_table.
Thanks
Jocke
^ permalink raw reply
* Re: RAMDISK on EP88xc
From: Frank Svendsbøe @ 2009-07-02 7:10 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: linuxppc-dev
In-Reply-To: <97dd5fd20907011314j1974728fs745bbc62e2b1e6ec@mail.gmail.com>
On Wed, Jul 1, 2009 at 10:14 PM, Mikhail
Zaturenskiy<mzaturenskiy.st@gmail.com> wrote:
>> Hi Mikhail,
>> Try setting CONFIG_EXT2_FS=y, then recompile your kernel and reboot.
>
> Hi Frank, just tried that but still getting the same "Unpacking
> initramfs... failed!" output
>
Hmm... according to "Kernel command line: console=ttyCPM0,9600n8
loglevel=7" you haven't
specified where root is. Add root=/dev/ram to the kernel command line,
and specify where the
init process is located (for instance init=/sbin/init).
I haven't tried Denks ramdisk image. You can create one for yourself
using dd, gzip and U-Boots
mkimage tool. If the ramdisk image is larger than 4MB, you must either
change the default
CONFIG_BLK_DEV_RAM_SIZE=4096, or set ramdisk size in the kernel command line.
Btw, I use an older kernel than you use, but I have these defined:
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
Maybe they're obsolete now, but you can try to add them to your defconfig file.
Good luck ;-)
- Frank
^ permalink raw reply
* Re: Preemption question (4xx related)
From: Benjamin Herrenschmidt @ 2009-07-02 7:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Felix Radensky
In-Reply-To: <20090702001450.GF6189@zod.rchland.ibm.com>
On Wed, 2009-07-01 at 20:14 -0400, Josh Boyer wrote:
> I've toyed with that idea myself. I keep coming back to the fact that you need
> a workload that would really leverage it, and I don't have one at the moment.
To some extent that's true but just turning full preemption including
kernel side with all the associated debug bits and lockdep should make a
whole bunch of things show up even with ordinary workloads.
For 440 tend to boot an ubuntu distro off NFS root with all X & DRI 3D
etc... and then run compiz :-)
Cheers,
Ben.
^ permalink raw reply
* AW: Direct MII connection between MPC8313 and VIRTEX FPGA
From: Frank Prepelica @ 2009-07-02 8:13 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
Hi Grant
Thank you very much so far. It helped me a lot!
Best regards
Frank
=20
=20
=20
=09
> -----Urspr=FCngliche Nachricht-----
> Von: =
linuxppc-dev-bounces+frank.prepelica=3Dubidyne.com@lists.ozlabs.org
> =
[mailto:linuxppc-dev-bounces+frank.prepelica=3Dubidyne.com@lists.ozlabs.o=
rg]
> Im Auftrag von Grant Likely
> Gesendet: Dienstag, 30. Juni 2009 18:17
> An: Frank Prepelica
> Cc: linuxppc-dev@ozlabs.org
> Betreff: Re: Direct MII connection between MPC8313 and VIRTEX FPGA
>=20
> On Tue, Jun 30, 2009 at 2:35 AM, Frank
> Prepelica<Frank.Prepelica@ubidyne.com> wrote:
> >> What kernel version are you using?
> >
> > We are using kernel version 2.6.24. I've searched for "current =
speed" in
> version 2.6.28.7 and I've found that string.
> >
> >> Yes, you need to modify the DTB. =A0You have a back to back MII
> >> connection, not a phy, so you do *not* want to have a PHY node in =
the
> >> device tree.
> >
> > Hmm, but I do have a "PHY", don't I?. The "PHY" will be emulated in =
the
> FPGA. Of course, it's not a physical PHY but it should look like one.
>=20
> No, it sounds like you don't. If you've got a back-to-back MII
> connection, then you can fix the link speed and you don't need to do
> any form of PHY emulation. ie. you don't need to wire up the MDIO
> pins.
>=20
> > So, do I really need the remove the complete PHY description in the =
DTB?
>=20
> yes.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* How to set DDR data bus width to 16Bit
From: Frank Prepelica @ 2009-07-02 8:17 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Does anyone knows how to set the DDR data bus width to 16Bit in linux?
I've found that=20
option in U-Boot in the MPC8313ERDB_config file. (verfied with a memory
dump of the=20
CPU register (DDR_SDRAM_CFG) - the 16Bit DBW is set(10b) ). But after
starting=20
linux the value is set to 00b (=3Dreseverd).
We are using a customized MPC8313ERDB board.
Thanks in advance
Kind regards
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
^ permalink raw reply
* Re: How to set DDR data bus width to 16Bit
From: Norbert van Bolhuis @ 2009-07-02 9:04 UTC (permalink / raw)
To: Frank Prepelica; +Cc: linuxppc-dev
In-Reply-To: <29DC34A6B43468409F5A371CFE34E849D7F173@ex01.ads.ubidyne.de>
you have to do it via your bootloader (u-boot) which sets up
the DDR memory controller.
Linux (already) assumes memory is available.
Are you sure linux kernel is changing DDR_SDRAM_CFG ?
When our linux-2.6.28 kernel is up, it's still 0xc3080000 when I read
physical address 0xe0002110.
Btw. We did some performance tests with 16 bit bus-width (DDR2 memory)
and surprisingly performance was almost as good as 32 bit bus-width
---
N. van Bolhuis.
Frank Prepelica wrote:
> Hi all,
>
> Does anyone knows how to set the DDR data bus width to 16Bit in linux?
> I've found that
> option in U-Boot in the MPC8313ERDB_config file. (verfied with a memory
> dump of the
> CPU register (DDR_SDRAM_CFG) - the 16Bit DBW is set(10b) ). But after
> starting
> linux the value is set to 00b (=reseverd).
>
> We are using a customized MPC8313ERDB board.
>
> Thanks in advance
>
>
> Kind regards
>
> Frank Prepelica
> Software Design Engineer
>
> Ubidyne GmbH
> Lise-Meitner-Str.-14
> 89081 Ulm - Germany
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Preemption question (4xx related)
From: Michel Dänzer @ 2009-07-02 9:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Felix Radensky
In-Reply-To: <1246486393.14483.14.camel@pasglop>
On Thu, 2009-07-02 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-06-30 at 05:55 -0700, Felix Radensky wrote:
> > Hi,
> >=20
> > Preemption is disabled on the vast majority of powerpc
> > targets. Are there any known problems in this area ?
> > I'd like to enable CONFIG_PREEMPT_VOLUNTARY on
> > AMCC 405EX target, to increase application responsiveness.
> > Is it a bad idea ?
>=20
> In theory it should work, but as you may have noticed, it's generally
> disabled and thus not very well tested.
>=20
> It would be a good idea for us, some of the core devs, to turn that on
> in our usual test configs in fact.
FWIW, on my PowerBook I've been running with CONFIG_PREEMPT_VOLUNTARY
enabled for a long time (more than a year). No problems so far, and it
definitely seems to help a lot for interactivity.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* AW: How to set DDR data bus width to 16Bit
From: Frank Prepelica @ 2009-07-02 9:45 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev
> you have to do it via your bootloader (u-boot) which sets up
> the DDR memory controller.
> Linux (already) assumes memory is available.
> Are you sure linux kernel is changing DDR_SDRAM_CFG ?
> When our linux-2.6.28 kernel is up, it's still 0xc3080000 when I read
> physical address 0xe0002110.
Hi Norbert, thank you for your fast reply!
You are absolutly right! I made a silly mistake. I've read the value of
the 0xe0002110 with a 8bit pointer.
The value is actually 0xC3100000 which means the 16bit bus width is set.
Just to be sure. Is this the only change (in the bootloader) I have to
make that all data accesses are 16bit wide?
> Btw. We did some performance tests with 16 bit bus-width (DDR2 memory)
> and surprisingly performance was almost as good as 32 bit bus-width
This is exactly our intention to test. Thanks for that hint. Very good
to
know!
Thank you.
Best regards
Frank
^ permalink raw reply
* Re: AW: How to set DDR data bus width to 16Bit
From: Norbert van Bolhuis @ 2009-07-02 10:30 UTC (permalink / raw)
To: Frank Prepelica; +Cc: linuxppc-dev
In-Reply-To: <29DC34A6B43468409F5A371CFE34E849D7F193@ex01.ads.ubidyne.de>
Hi Frank,
Yes, it's 0xC3100000 for 16 bit. I showed the 32bit value.
Yes, to go to 16 bit bus-width (1 DDR(2) device), this is the only
change needed in u-boot, assuming you have 2 DDR(2) devices (like 8313E-RDB)
which together provide 16+16 = 32bit bus-width.
Since, surprisingly, the 16 bit application/u-boot performance was almost as
good as 32 bit we even tested with I-cache and D-cache turned off.
u-boot provides commands for this (which I didn't know, see some previous
emails from me on this mailing-list).
Also with I-cache and D-cache turned off the 16 bit bus-width performance was
almost as good as 32 bit. So our conclusion was that the 16/32 bit DDR2 memory
access is not the limiting factor when it comes to "SW performance".
Therefore we decided to go for 16 bit bus-width for a new/tiny 8313 based
design.
Please let me know your test results. I would expect you to conclude more
or less the same.
Best Regards,
Norbert.
Frank Prepelica wrote:
>> you have to do it via your bootloader (u-boot) which sets up
>> the DDR memory controller.
>> Linux (already) assumes memory is available.
>> Are you sure linux kernel is changing DDR_SDRAM_CFG ?
>> When our linux-2.6.28 kernel is up, it's still 0xc3080000 when I read
>> physical address 0xe0002110.
>
>
> Hi Norbert, thank you for your fast reply!
>
> You are absolutly right! I made a silly mistake. I've read the value of
> the 0xe0002110 with a 8bit pointer.
>
> The value is actually 0xC3100000 which means the 16bit bus width is set.
>
> Just to be sure. Is this the only change (in the bootloader) I have to
> make that all data accesses are 16bit wide?
>
>> Btw. We did some performance tests with 16 bit bus-width (DDR2 memory)
>> and surprisingly performance was almost as good as 32 bit bus-width
>
> This is exactly our intention to test. Thanks for that hint. Very good
> to
> know!
>
> Thank you.
>
> Best regards
> Frank
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox