* 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
* Re: Preemption question (4xx related)
From: Josh Boyer @ 2009-07-02 11:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Felix Radensky
In-Reply-To: <1246519992.7551.1.camel@pasglop>
On Thu, Jul 02, 2009 at 05:33:12PM +1000, Benjamin Herrenschmidt wrote:
>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.
I can look at doing that for ppc44x_defconfig. I'll be honest and say I don't
expect it to go well, particularly with lockdep :).
>For 440 tend to boot an ubuntu distro off NFS root with all X & DRI 3D
>etc... and then run compiz :-)
Yes. Because that's a totally realistic workload for a 440. I'm surprised you
don't have a p595 machine acting as your home router too! ;)
josh
^ permalink raw reply
* Re: [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error
From: Avi Kivity @ 2009-07-02 11:19 UTC (permalink / raw)
To: Liu Yu-B13201; +Cc: linuxppc-dev, Yang Shi, kvm-ppc, hollisb, kvm
In-Reply-To: <0A1FE637C2C7E148B9573BB60CC630E531C59D@zch01exm26.fsl.freescale.net>
On 07/02/2009 06:09 AM, Liu Yu-B13201 wrote:
> This fix is already accepted in kvm.git
>
What about the other? Is it needed?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Detlev Zundel @ 2009-07-02 13:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090701170436.GA502@b07421-ec1.am.freescale.net>
Hi Scott,
> On Wed, Jul 01, 2009 at 02:13:29PM +0200, Detlev Zundel wrote:
>> Hi,
>>
>> > As for my device tree, I reverted back to the original version with
>> > nothing filled in and just replaced 0xfa20xxxx with 0xf000xxxx as Gary
>> > suggested earlier.
>>
>> Would it be a problem to also dynamically fixup IMMR in the device tree
>> from U-Boot?
>
> Yes. It can appear in multiple places in the device tree (for exmaple,
> in things like the localbus and pci nodes where we have some IMMR
> registers but need ranges to point outside IMMR); this introduces more
> dependencies between u-boot and the input dtb than just getting the
> address right in the first place.
Ah, I see - the IMMR address is duplicated because the nodes you mention
are not children of "soc", so they cannot reference that parent address
space.
I guess re-arranging the hierarchy is not viable, but maybe we can
include this orthogonal parent-child relation. For example, could a
"reg-parent" phandle solve this duplication?
Cheers
Detlev
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: RAMDISK on EP88xc
From: Mikhail Zaturenskiy @ 2009-07-02 13:43 UTC (permalink / raw)
To: Frank Svendsbøe; +Cc: linuxppc-dev
In-Reply-To: <1ba63b520907020010u46a3b495h79672fc4f6d84c14@mail.gmail.com>
On Thu, Jul 2, 2009 at 2:10 AM, Frank
Svendsb=F8e<frank.svendsboe@gmail.com> wrote:
> On Wed, Jul 1, 2009 at 10:14 PM, Mikhail
> Zaturenskiy<mzaturenskiy.st@gmail.com> wrote:
> Hmm... according to "Kernel command line: console=3DttyCPM0,9600n8
> loglevel=3D7" you haven't
> specified where root is. Add root=3D/dev/ram to the kernel command line,
> and specify where the
> init process is located (for instance init=3D/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=3D4096, 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=3Dy
> CONFIG_BLK_DEV_LOOP=3Dy
> CONFIG_BLK_DEV_RAM=3Dy
> CONFIG_BLK_DEV_RAM_COUNT=3D16
> CONFIG_BLK_DEV_RAM_SIZE=3D4096
>
> Maybe they're obsolete now, but you can try to add them to your defconfig=
file.
>
> Good luck ;-)
>
Thanks Frank, this seems to be leading me down the right path. I tried
some of those defines out yesterday and they got the kernel to at
least attempt to load the ramdisk, so I'm getting somewhere. Also
added root=3D/dev/ram (also tried /dev/ram0) and init=3D/sbin/init but for
now things are failing before processing those args.
I haven't tried CONFIG_BLK_DEV or CONFIG_BLK_DEV_LOOP and am still
playing around with the values for CONFIG_BLK_DEV_RAM_COUNT and
CONFIG_BLK_DEV_RAM_SIZE. Strangely, the DEV_RAM defines are completely
missing from my config so I have to put them in manually... (as
opposed to via menuconfig). I'll post back when it's working or when
I've tried all of this and still am getting some error.
Meanwhile a side question - why does BLK_DEV_RAM_COUNT default to 16?
^ 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