* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfgang Denk @ 2009-06-06 22:16 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <4b73d43f0905071909v6e6e8b2el9eb6d4a1b9038f45@mail.gmail.com>
Dear John,
In message <4b73d43f0905071909v6e6e8b2el9eb6d4a1b9038f45@mail.gmail.com> you wrote:
>
> I think the fec's parent clock is the ipb clock not the ppc core clock.
> Could that be the problem?
I don't think so.
When debugging, I printed the actual clock frequencies, and they
looked as expected. And "arch/powerpc/platforms/512x/clock.c" has
this:
385 static struct clk fec_clk = {
386 .name = "fec_clk",
387 .flags = CLK_HAS_CTRL,
388 .reg = 0,
389 .bit = 13,
390 .calc = unity_clk_calc,
391 .parent = &ips_clk,
392 };
which looks OK to me.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The human mind ordinarily operates at only ten percent of its
capacity. The rest is overhead for the operating system.
^ permalink raw reply
* Re: [RFC][PATCH v5] MPC5121 TLB errata workaround
From: Wolfgang Denk @ 2009-06-06 22:07 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-dev, Paul Mackerras, gunnar
In-Reply-To: <200903161652.09747.david.jander@protonic.nl>
Dear David Jander,
In message <200903161652.09747.david.jander@protonic.nl> you wrote:
> Complete workaround for DTLB errata in e300c2/c3/c4 processors.
>
> Due to the bug, the hardware-implemented LRU algorythm always goes to way
> 1 of the TLB. This fix implements the proposed software workaround in
> form of a LRW table for chosing the TLB-way.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: David Jander <david@protonic.nl>
What is the actual status of this patch?
Patchwork (http://patchwork.ozlabs.org/patch/24502/) says it's
"superseded" - but by what?
I can't see such code in mainline - what happened to it?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
One essential to success is that you desire be an all-obsessing one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.
^ permalink raw reply
* Re: how can i send real-time signal?
From: Benedikt Spranger @ 2009-06-06 20:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <23892580.post@talk.nabble.com>
Am Fri, 5 Jun 2009 10:41:56 -0700 (PDT)
schrieb wael showair <showair2003@yahoo.com>:
> My aim is : Each time the DSP-core interrupts the MPC8555 processor, a
> process in the user space will be informed by the arrival of this each
> interrupt.
You should have a look at drivers/uio...
> So i decided to use sw signals, in the ISR of the DSP-core interrupt
> i send a SW signal to the user space process? Is this the best
> solution? are there any better suggestion to achieve my aim?
signals are expensive. Look at the UIO-Framework for a cheaper solution.
preallocated RT-Signals on the other Hand are fragile. Blocking reads
are cheaper and in case of preempt-RT, but not resticted to it, much
easier to handle.
Bene
^ permalink raw reply
* [PATCH] powerpc: Enable additional BAT registers in setup_745x_specifics()
From: Gerhard Pircher @ 2009-06-06 21:12 UTC (permalink / raw)
To: linuxppc-dev
Currently the kernel expects the additional four IBAT and DBAT registers
to be available, but doesn't enable these registers on 745x CPUs, which
have them disabled after reset. Thus set the HIGH_BAT_EN bit in HID0
register, if the corresponding MMU feature is defined.
Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
---
arch/powerpc/kernel/cpu_setup_6xx.S | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/kernel/cpu_setup_6xx.S
index 54f767e..1e9949e 100644
--- a/arch/powerpc/kernel/cpu_setup_6xx.S
+++ b/arch/powerpc/kernel/cpu_setup_6xx.S
@@ -239,6 +239,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE
ori r11,r11,HID0_LRSTK | HID0_BTIC
oris r11,r11,HID0_DPM@h
+BEGIN_MMU_FTR_SECTION
+ oris r11,r11,HID0_HIGH_BAT@h
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_HIGH_BATS)
BEGIN_FTR_SECTION
xori r11,r11,HID0_BTIC
END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
--
1.5.6.5
--
GMX FreeDSL mit DSL 6.000 Flatrate und Telefonanschluss nur 17,95 Euro/mtl.!
http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply related
* Re: [PATCH] Remove machine_is(chrp) from 64-bit kernel
From: Benjamin Herrenschmidt @ 2009-06-06 21:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1244306290.3751.2032.camel@macbook.infradead.org>
On Sat, 2009-06-06 at 17:38 +0100, David Woodhouse wrote:
> The CHRP platform type only exists in a 32-bit build. Don't bother
> checking machine_is(chrp) if we're in 64-bit mode.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Isn't the test bogus anyway ? It should be if (!machine_is(powermac))
but is useless since the function is called via:
machine_device_initcall(powermac, pmac_declare_of_platform_devices);
Cheers,
Ben.
> diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
> index 45936c9..c22f7e8 100644
> --- a/arch/powerpc/platforms/powermac/setup.c
> +++ b/arch/powerpc/platforms/powermac/setup.c
> @@ -518,9 +518,10 @@ static int __init pmac_declare_of_platform_devices(void)
> {
> struct device_node *np;
>
> +#ifdef CONFIG_PPC32
> if (machine_is(chrp))
> return -1;
> -
> +#endif
> np = of_find_node_by_name(NULL, "valkyrie");
> if (np)
> of_platform_device_create(np, "valkyrie", NULL);
>
^ permalink raw reply
* Re: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
From: Sachin Sant @ 2009-06-06 19:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Mel Gorman, linuxppc-dev
In-Reply-To: <1244233062.31984.6.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 4342 bytes --]
Benjamin Herrenschmidt wrote:
> No, Mel's patch is for a different problem and has been fixed upstream
> already. This is more concerning... I'm not sure what's up but would
> you be able to send a disassembly of the hpte_need_flush() function in
> your kernel binary for me to see what access precisely caused the
> fault ?
>
Was able to recreate this with git3 kernel. Here is the disassembly
shm-fork 10 10 (64): PASS
shm-fork 10 20 (32): cpu 0x1: Vector: 300 (Data Access) at [c0000000faa13490]
pc: c000000000038240: .hpte_need_flush+0x1bc/0x2d8
lr: c0000000000380f0: .hpte_need_flush+0x6c/0x2d8
sp: c0000000faa13710
msr: 8000000000009032
dar: c00000005e5e0480
dsisr: 40000000
current = 0xc0000000f9bde3e0
paca = 0xc000000000b72600
pid = 12152, comm = shm-fork
enter ? for help
[c0000000faa13710] c000000000038264 .hpte_need_flush+0x1e0/0x2d8 (unreliable)
[c0000000faa137d0] c000000000039fa4 .huge_ptep_get_and_clear+0x40/0x5c
[c0000000faa13850] c00000000012d044 .__unmap_hugepage_range+0x178/0x2b8
[c0000000faa13940] c00000000012d1d8 .unmap_hugepage_range+0x54/0x88
[c0000000faa139e0] c000000000116f78 .unmap_vmas+0x178/0x8f4
[c0000000faa13b30] c00000000011c690 .unmap_region+0xfc/0x1e4
[c0000000faa13c00] c00000000011de20 .do_munmap+0x2f4/0x38c
[c0000000faa13cc0] c0000000002f6a08 .SyS_shmdt+0xc0/0x188
[c0000000faa13d70] c00000000000c430 .sys_ipc+0x274/0x2fc
[c0000000faa13e30] c000000000008534 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000004000021d2dc
SP (fffee026010) is in userspace
1:mon> di $.hpte_need_flush
c000000000038084 fac1ffb0 std r22,-80(r1)
c000000000038088 7c0802a6 mflr r0
c00000000003808c f8010010 std r0,16(r1)
c000000000038090 2fa70000 cmpdi cr7,r7,0
c000000000038094 fb21ffc8 std r25,-56(r1)
c000000000038098 6cc01000 xoris r0,r6,4096
c00000000003809c fb41ffd0 std r26,-48(r1)
c0000000000380a0 7cd93378 mr r25,r6
c0000000000380a4 fb61ffd8 std r27,-40(r1)
c0000000000380a8 7cb62b78 mr r22,r5
c0000000000380ac fb81ffe0 std r28,-32(r1)
......... <SNIP> .........
1:mon>
c000000000038204 38090001 addi r0,r9,1
c000000000038208 78004602 rldicl r0,r0,40,24
c00000000003820c 7c004a14 add r0,r0,r9
c000000000038210 78090220 clrldi r9,r0,40
c000000000038214 2fbd0000 cmpdi cr7,r29,0
c000000000038218 409e0010 bne cr7,c000000000038228 # .hpte_need_flush+0x1a4/0x2d8
c00000000003821c 7929e0e4 rldicr r9,r9,28,35
c000000000038220 7be00120 clrldi r0,r31,36
c000000000038224 4800000c b c000000000038230 # .hpte_need_flush+0x1ac/0x2d8
c000000000038228 792945c6 rldicr r9,r9,40,23
c00000000003822c 7be00600 clrldi r0,r31,24
c000000000038230 7d3f0378 or r31,r9,r0
c000000000038234 7c1cb82e lwzx r0,r28,r23
c000000000038238 3d360001 addis r9,r22,1
c00000000003823c 2f800000 cmpwi cr7,r0,0
c000000000038240 eb898000 ld r28,-32768(r9) <<== +0x1bc should be this
1:mon> r
R00 = 0000000000000000 R16 = 0000000023aa4db0
R01 = c0000000faa13710 R17 = 0000000000000000
R02 = c000000000a9d788 R18 = ffffffffffff9010
R03 = 0000000000000004 R19 = 0000000000000000
R04 = 000003fff0000000 R20 = 0000000000000000
R05 = c00000005e5d8480 R21 = 0000040000000000
R06 = 0000364008000393 R22 = c00000005e5d8480
R07 = 0000000000000001 R23 = 0000000000750000
R08 = 0000000000000004 R24 = 0000000000000000
R09 = c00000005e5e8480 R25 = 0000364008000393
R10 = 000000000003fff0 R26 = c0000000673f0680
R11 = 0000000000000280 R27 = 0000000000000004
R12 = 0000000044022422 R28 = c000000000890430
R13 = c000000000b72600 R29 = 0000000000000001
R14 = 00000000ffffffff R30 = c000000000fe0430
R15 = ffffffffffffffff R31 = 8812ebfff0000000
pc = c000000000038240 .hpte_need_flush+0x1bc/0x2d8
lr = c0000000000380f0 .hpte_need_flush+0x6c/0x2d8
msr = 8000000000009032 cr = 44022422
ctr = c00000000025cc28 xer = 0000000000000001 trap = 300
dar = c00000005e5e0480 dsisr = 40000000
1:mon>
Have attached the complete disassembly.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: disassembly.log --]
[-- Type: text/x-log, Size: 8364 bytes --]
shm-fork 10 10 (64): PASS
shm-fork 10 20 (32): cpu 0x1: Vector: 300 (Data Access) at [c0000000faa13490]
pc: c000000000038240: .hpte_need_flush+0x1bc/0x2d8
lr: c0000000000380f0: .hpte_need_flush+0x6c/0x2d8
sp: c0000000faa13710
msr: 8000000000009032
dar: c00000005e5e0480
dsisr: 40000000
current = 0xc0000000f9bde3e0
paca = 0xc000000000b72600
pid = 12152, comm = shm-fork
enter ? for help
[c0000000faa13710] c000000000038264 .hpte_need_flush+0x1e0/0x2d8 (unreliable)
[c0000000faa137d0] c000000000039fa4 .huge_ptep_get_and_clear+0x40/0x5c
[c0000000faa13850] c00000000012d044 .__unmap_hugepage_range+0x178/0x2b8
[c0000000faa13940] c00000000012d1d8 .unmap_hugepage_range+0x54/0x88
[c0000000faa139e0] c000000000116f78 .unmap_vmas+0x178/0x8f4
[c0000000faa13b30] c00000000011c690 .unmap_region+0xfc/0x1e4
[c0000000faa13c00] c00000000011de20 .do_munmap+0x2f4/0x38c
[c0000000faa13cc0] c0000000002f6a08 .SyS_shmdt+0xc0/0x188
[c0000000faa13d70] c00000000000c430 .sys_ipc+0x274/0x2fc
[c0000000faa13e30] c000000000008534 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000004000021d2dc
SP (fffee026010) is in userspace
1:mon> di $.hpte_need_flush
c000000000038084 fac1ffb0 std r22,-80(r1)
c000000000038088 7c0802a6 mflr r0
c00000000003808c f8010010 std r0,16(r1)
c000000000038090 2fa70000 cmpdi cr7,r7,0
c000000000038094 fb21ffc8 std r25,-56(r1)
c000000000038098 6cc01000 xoris r0,r6,4096
c00000000003809c fb41ffd0 std r26,-48(r1)
c0000000000380a0 7cd93378 mr r25,r6
c0000000000380a4 fb61ffd8 std r27,-40(r1)
c0000000000380a8 7cb62b78 mr r22,r5
c0000000000380ac fb81ffe0 std r28,-32(r1)
c0000000000380b0 eb828d30 ld r28,-29392(r2)
c0000000000380b4 fbc1fff0 std r30,-16(r1)
c0000000000380b8 781b27e2 rldicl r27,r0,36,63
c0000000000380bc fbe1fff8 std r31,-8(r1)
c0000000000380c0 7c7a1b78 mr r26,r3
1:mon>
c0000000000380c4 fae1ffb8 std r23,-72(r1)
c0000000000380c8 789f03e4 rldicr r31,r4,0,47
c0000000000380cc fb01ffc0 std r24,-64(r1)
c0000000000380d0 fba1ffe8 std r29,-24(r1)
c0000000000380d4 f821ff41 stdu r1,-192(r1)
c0000000000380d8 eaed0040 ld r23,64(r13)
c0000000000380dc 7fdcba14 add r30,r28,r23
c0000000000380e0 eb1e0008 ld r24,8(r30)
c0000000000380e4 419e0014 beq cr7,c0000000000380f8 # .hpte_need_flush+0x74/0x2d8
c0000000000380e8 7fe4fb78 mr r4,r31
c0000000000380ec 48000d85 bl c000000000038e70 # .get_slice_psize+0x0/0x38
c0000000000380f0 60000000 nop
c0000000000380f4 7c7b1b78 mr r27,r3
c0000000000380f8 e8028d38 ld r0,-29384(r2)
c0000000000380fc 7fbf0040 cmpld cr7,r31,r0
c000000000038100 419d00a8 bgt cr7,c0000000000381a8 # .hpte_need_flush+0x124/0x2d8
1:mon>
c000000000038104 3800ffff li r0,-1
c000000000038108 3ba00000 li r29,0
c00000000003810c 78000600 clrldi r0,r0,24
c000000000038110 7fbf0040 cmpld cr7,r31,r0
c000000000038114 409d000c ble cr7,c000000000038120 # .hpte_need_flush+0x9c/0x2d8
c000000000038118 e9228d40 ld r9,-29376(r2)
c00000000003811c eba90002 lwa r29,0(r9)
c000000000038120 2fbd0000 cmpdi cr7,r29,0
c000000000038124 e97a0390 ld r11,912(r26)
c000000000038128 409e003c bne cr7,c000000000038164 # .hpte_need_flush+0xe0/0x2d8
c00000000003812c 796b83e4 rldicr r11,r11,16,47
c000000000038130 7be02702 rldicl r0,r31,36,28
c000000000038134 3d200bf6 lis r9,3062
c000000000038138 7c005b78 or r0,r0,r11
c00000000003813c 6129e61b ori r9,r9,58907
c000000000038140 7c0049d2 mulld r0,r0,r9
1:mon>
c000000000038144 78090700 clrldi r9,r0,28
c000000000038148 7800e120 rldicl r0,r0,28,36
c00000000003814c 7d290214 add r9,r9,r0
c000000000038150 38090001 addi r0,r9,1
c000000000038154 7800e120 rldicl r0,r0,28,36
c000000000038158 7c004a14 add r0,r0,r9
c00000000003815c 78090700 clrldi r9,r0,28
c000000000038160 48000038 b c000000000038198 # .hpte_need_flush+0x114/0x2d8
c000000000038164 796b26e4 rldicr r11,r11,4,59
c000000000038168 7be0c220 rldicl r0,r31,24,40
c00000000003816c 3d2000bf lis r9,191
c000000000038170 7c005b78 or r0,r0,r11
c000000000038174 612950d9 ori r9,r9,20697
c000000000038178 7c0049d2 mulld r0,r0,r9
c00000000003817c 78090220 clrldi r9,r0,40
c000000000038180 78004602 rldicl r0,r0,40,24
1:mon>
c000000000038184 7d290214 add r9,r9,r0
c000000000038188 38090001 addi r0,r9,1
c00000000003818c 78004602 rldicl r0,r0,40,24
c000000000038190 7c004a14 add r0,r0,r9
c000000000038194 78090220 clrldi r9,r0,40
c000000000038198 7d200074 cntlzd r0,r9
c00000000003819c 7800d182 rldicl r0,r0,58,6
c0000000000381a0 0b000000 tdnei r0,0
c0000000000381a4 48000070 b c000000000038214 # .hpte_need_flush+0x190/0x2d8
c0000000000381a8 e9228d48 ld r9,-29368(r2)
c0000000000381ac eba90002 lwa r29,0(r9)
c0000000000381b0 2fbd0000 cmpdi cr7,r29,0
c0000000000381b4 409e0034 bne cr7,c0000000000381e8 # .hpte_need_flush+0x164/0x2d8
c0000000000381b8 3d200bf6 lis r9,3062
c0000000000381bc 7be02702 rldicl r0,r31,36,28
c0000000000381c0 6129e61b ori r9,r9,58907
1:mon>
c0000000000381c4 7c0049d2 mulld r0,r0,r9
c0000000000381c8 78090700 clrldi r9,r0,28
c0000000000381cc 7800e120 rldicl r0,r0,28,36
c0000000000381d0 7d290214 add r9,r9,r0
c0000000000381d4 38090001 addi r0,r9,1
c0000000000381d8 7800e120 rldicl r0,r0,28,36
c0000000000381dc 7c004a14 add r0,r0,r9
c0000000000381e0 78090700 clrldi r9,r0,28
c0000000000381e4 48000038 b c00000000003821c # .hpte_need_flush+0x198/0x2d8
c0000000000381e8 3d2000bf lis r9,191
c0000000000381ec 7be0c220 rldicl r0,r31,24,40
c0000000000381f0 612950d9 ori r9,r9,20697
c0000000000381f4 7c0049d2 mulld r0,r0,r9
c0000000000381f8 78090220 clrldi r9,r0,40
c0000000000381fc 78004602 rldicl r0,r0,40,24
c000000000038200 7d290214 add r9,r9,r0
1:mon>
c000000000038204 38090001 addi r0,r9,1
c000000000038208 78004602 rldicl r0,r0,40,24
c00000000003820c 7c004a14 add r0,r0,r9
c000000000038210 78090220 clrldi r9,r0,40
c000000000038214 2fbd0000 cmpdi cr7,r29,0
c000000000038218 409e0010 bne cr7,c000000000038228 # .hpte_need_flush+0x1a4/0x2d8
c00000000003821c 7929e0e4 rldicr r9,r9,28,35
c000000000038220 7be00120 clrldi r0,r31,36
c000000000038224 4800000c b c000000000038230 # .hpte_need_flush+0x1ac/0x2d8
c000000000038228 792945c6 rldicr r9,r9,40,23
c00000000003822c 7be00600 clrldi r0,r31,24
c000000000038230 7d3f0378 or r31,r9,r0
c000000000038234 7c1cb82e lwzx r0,r28,r23
c000000000038238 3d360001 addis r9,r22,1
c00000000003823c 2f800000 cmpwi cr7,r0,0
c000000000038240 eb898000 ld r28,-32768(r9)
1:mon> r
R00 = 0000000000000000 R16 = 0000000023aa4db0
R01 = c0000000faa13710 R17 = 0000000000000000
R02 = c000000000a9d788 R18 = ffffffffffff9010
R03 = 0000000000000004 R19 = 0000000000000000
R04 = 000003fff0000000 R20 = 0000000000000000
R05 = c00000005e5d8480 R21 = 0000040000000000
R06 = 0000364008000393 R22 = c00000005e5d8480
R07 = 0000000000000001 R23 = 0000000000750000
R08 = 0000000000000004 R24 = 0000000000000000
R09 = c00000005e5e8480 R25 = 0000364008000393
R10 = 000000000003fff0 R26 = c0000000673f0680
R11 = 0000000000000280 R27 = 0000000000000004
R12 = 0000000044022422 R28 = c000000000890430
R13 = c000000000b72600 R29 = 0000000000000001
R14 = 00000000ffffffff R30 = c000000000fe0430
R15 = ffffffffffffffff R31 = 8812ebfff0000000
pc = c000000000038240 .hpte_need_flush+0x1bc/0x2d8
lr = c0000000000380f0 .hpte_need_flush+0x6c/0x2d8
msr = 8000000000009032 cr = 44022422
ctr = c00000000025cc28 xer = 0000000000000001 trap = 300
dar = c00000005e5e0480 dsisr = 40000000
1:mon>
^ permalink raw reply
* Re: Missing some interrupts
From: Grant Likely @ 2009-06-06 17:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, wael showair
In-Reply-To: <9e4733910906060634k16a2dc6er138820e71cd2c6cf@mail.gmail.com>
On Sat, Jun 6, 2009 at 7:34 AM, Jon Smirl<jonsmirl@gmail.com> wrote:
> On Sat, Jun 6, 2009 at 9:17 AM, wael showair<showair2003@yahoo.com> wrote:
>>
>> Hi All,
>> i have a freescale board, that contains MPC8555 processor & DSP-core
>> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of
>> the MPC8555 processor.
>>
>> i test one interrupt from the DSP-core to the MPC8555 processor where i
>> configure this interrupt line to be edge-triggered (falling edge) & i
>> receive it successfully
>> but
>> when i generate this interrupt 10 successive times using for loop
>> i just receive 2 interrupts?
>>
>> why can't i receive the 8 other interrupts?
>> i print the value of every irq number inside do_IRQ & i found that i receive
>> the DSP-interrupt just only twice.
>>
>> do u have any suggestions to solve this problem?
>> i want to make sure that i can receive 10 interrupts
>
> Don't do a printk() with interrupts disabled. A printk() takes 1.5ms
> on a mpc5200.
Look at /proc/interrupts instead to see how many IRQs are received.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/install: Bail with error code on error in install script
From: Grant Likely @ 2009-06-06 16:44 UTC (permalink / raw)
To: linuxppc-dev, benh, John Linn
In-Reply-To: <20090606163837.17482.56209.stgit@localhost.localdomain>
Oops, forgot one. Here is a new request including the xilinxfb refactoring=
:
The following changes since commit baf75b0a42a1b3f6fca80f8949b6141eaff61b0d=
:
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next
Grant Likely (1):
powerpc/virtex: refactor intc driver and add support for i8259 cascad=
ing
John Linn (1):
fbdev: Add PLB support and cleanup DCR in xilinxfb driver.
Roderick Colenbrander (3):
powerpc/virtex: Add support for Xilinx PCI host bridge
powerpc/virtex: Add Xilinx ML510 reference design support
powerpc/virtex: Add ml510 reference design device tree
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +++++++++++++++++++++++++=
++++
arch/powerpc/include/asm/xilinx_pci.h | 21 ++
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/44x/Kconfig | 13 +-
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex.c | 2 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 ++
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/xilinx_intc.c | 81 ++++--
arch/powerpc/sysdev/xilinx_pci.c | 132 ++++++++
drivers/video/xilinxfb.c | 290 ++++++++++---------
12 files changed, 883 insertions(+), 158 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
On Sat, Jun 6, 2009 at 10:39 AM, Grant Likely<grant.likely@secretlab.ca> wr=
ote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> If anything goes wrong when copying images into the install path, then
> the install script should exit with an error code so that 'make' knows
> about it and tells the user.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> =A0arch/powerpc/boot/install.sh | =A0 =A03 +++
> =A01 files changed, 3 insertions(+), 0 deletions(-)
>
>
> diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
> index 51b2387..98312d1 100644
> --- a/arch/powerpc/boot/install.sh
> +++ b/arch/powerpc/boot/install.sh
> @@ -18,6 +18,9 @@
> =A0# =A0 $5 and more - kernel boot files; zImage*, uImage, cuImage.*, etc=
.
> =A0#
>
> +# Bail with error code if anything goes wrong
> +set -e
> +
> =A0# User may have a custom install script
>
> =A0if [ -x ~/bin/${CROSS_COMPILE}installkernel ]; then exec ~/bin/${CROSS=
_COMPILE}installkernel "$@"; fi
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc/install: Bail with error code on error in install script
From: Grant Likely @ 2009-06-06 16:39 UTC (permalink / raw)
To: linuxppc-dev, benh
From: Grant Likely <grant.likely@secretlab.ca>
If anything goes wrong when copying images into the install path, then
the install script should exit with an error code so that 'make' knows
about it and tells the user.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/install.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
index 51b2387..98312d1 100644
--- a/arch/powerpc/boot/install.sh
+++ b/arch/powerpc/boot/install.sh
@@ -18,6 +18,9 @@
# $5 and more - kernel boot files; zImage*, uImage, cuImage.*, etc.
#
+# Bail with error code if anything goes wrong
+set -e
+
# User may have a custom install script
if [ -x ~/bin/${CROSS_COMPILE}installkernel ]; then exec ~/bin/${CROSS_COMPILE}installkernel "$@"; fi
^ permalink raw reply related
* [PATCH] Remove machine_is(chrp) from 64-bit kernel
From: David Woodhouse @ 2009-06-06 16:38 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
The CHRP platform type only exists in a 32-bit build. Don't bother
checking machine_is(chrp) if we're in 64-bit mode.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 45936c9..c22f7e8 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -518,9 +518,10 @@ static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
+#ifdef CONFIG_PPC32
if (machine_is(chrp))
return -1;
-
+#endif
np = of_find_node_by_name(NULL, "valkyrie");
if (np)
of_platform_device_create(np, "valkyrie", NULL);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply related
* Please pull -next branch from git.secretlab.ca
From: Grant Likely @ 2009-06-06 16:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Roderick Colenbrander, linuxppc-dev
Hi Ben,
Here are some new commits to support the Xilinx ML507 board for 2.6.31
The following changes since commit baf75b0a42a1b3f6fca80f8949b6141eaff61b0d:
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next
Grant Likely (1):
powerpc/virtex: refactor intc driver and add support for i8259 cascading
Roderick Colenbrander (3):
powerpc/virtex: Add support for Xilinx PCI host bridge
powerpc/virtex: Add Xilinx ML510 reference design support
powerpc/virtex: Add ml510 reference design device tree
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +++++++++++++++++++++++++++++
arch/powerpc/include/asm/xilinx_pci.h | 21 ++
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/44x/Kconfig | 13 +-
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex.c | 2 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 ++
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/xilinx_intc.c | 81 ++++--
arch/powerpc/sysdev/xilinx_pci.c | 132 ++++++++
11 files changed, 732 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v2] Add MSI interrupts to DTS of MPC8315E-RDB
From: leon.woestenberg @ 2009-06-06 16:15 UTC (permalink / raw)
To: linuxppc-dev, galak, linux-kernel, Leon Woestenberg
The PCIe MSI interrupts are missing from the device tree source, and
thus were not enabled. This patch adds them.
v2 of the patch fixes inconsistent white space, reported by David Gibson.
Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
Tested-by: Leon Woestenberg <leon@sidebranch.com>
Index: git/arch/powerpc/boot/dts/mpc8315erdb.dts
===================================================================
--- git.orig/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-05-23 20:49:40.000000000 +0200
+++ git/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-06-06 10:35:14.000000000 +0200
@@ -322,6 +322,21 @@
reg = <0x700 0x100>;
device_type = "ipic";
};
+
+ ipic-msi@7c0 {
+ compatible = "fsl,ipic-msi";
+ reg = <0x7c0 0x40>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8>;
+ interrupt-parent = < &ipic >;
+ };
};
pci0: pci@e0008500 {
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Albrecht Dreß @ 2009-06-06 16:16 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linuxppc-dev, linux-mtd, Ben Dooks,
David Woodhouse
In-Reply-To: <fa686aa40906060905y1d39dce1j87d993ceb94273be@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
Am 06.06.09 18:05 schrieb(en) Grant Likely:
> > + - bank-width : Width (in bytes) of the RAM bank.
>
> Question: why is bank-width even relevant for a RAM device?
At least if the RAM is attached to the 5200's Local Plus Bus in 16-bit
mode, no byte write accesses are allowed (byte /reads/ work, though).
I have a tweak (which I will post next week) to address this case,
which depends upon this setting. No idea if the same happens on other
chips and/or on 5200 in 32-bit (muxed) mode, but I guess similar
effects will pop up there, too.
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-06-06 16:05 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, albrecht.dress, linuxppc-dev, linux-mtd,
Ben Dooks, David Woodhouse
In-Reply-To: <1244203514-12516-3-git-send-email-w.sang@pengutronix.de>
On Fri, Jun 5, 2009 at 6:05 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> diff --git a/Documentation/powerpc/dts-bindings/mtd-ram.txt b/Documentati=
on/powerpc/dts-bindings/mtd-ram.txt
> new file mode 100644
> index 0000000..a2e9932
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/mtd-ram.txt
> @@ -0,0 +1,18 @@
> +RAM emulating an MTD
> +
> +An external RAM like SRAM or FRAM can also be treated as an MTD.
> +
> + - compatible : should contain the specific model of the RAM chip
> + =A0 used, if known, followed by "mtd-ram".
> + - reg : Address range of the RAM chip
> + - bank-width : Width (in bytes) of the RAM bank.
Question: why is bank-width even relevant for a RAM device?
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: SD card over (xilinx_)SPI, timeout error while CID
From: Peter Korsgaard @ 2009-06-06 15:14 UTC (permalink / raw)
To: Joachim Foerster; +Cc: joachim, linuxppc-dev, dbrownell, john.linn, lorenz
In-Reply-To: <1244216069.21470.12.camel@localhost>
>>>>> "Joachim" == Joachim Foerster <JOFT@gmx.de> writes:
Hi,
Joachim> Any hints? Does anybody use SD card support with
Joachim> mmc_spi+xilinx_spi ?
I don't, but have you compared the spi signals on a scope in the 2
setups? Is timing significantly different?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Frank Mori Hess @ 2009-06-06 13:36 UTC (permalink / raw)
To: Greg KH
Cc: sachinp, Frank Mori Hess, sfr, linux-kernel, Linuxppc-dev,
Ian Abbott, linux-next, paulus, Geert.Uytterhoeven, geert,
subrata, David Miller
In-Reply-To: <20090606055103.GA9446@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Saturday 06 June 2009, Greg KH wrote:
> Frank and Ian, any thoughts about the vmap call in the
> comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
> is the prealloc_buf buffer used for?
It is a circular buffer used to hold data streaming either to or from a
board (for example when producing an analog output waveform). Reads and
writes to the device files read/write to the circular buffer, plus a few
drivers do dma directly to/from it. I personally don't have a problem
with requiring drivers to have their own dma buffers and making them copy
data between their private dma buffers and the main circular buffer. I
guess the original design wanted to support zero-copy dma.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Missing some interrupts
From: Jon Smirl @ 2009-06-06 13:34 UTC (permalink / raw)
To: wael showair; +Cc: linuxppc-dev
In-Reply-To: <23901807.post@talk.nabble.com>
On Sat, Jun 6, 2009 at 9:17 AM, wael showair<showair2003@yahoo.com> wrote:
>
> Hi All,
> i have a freescale board, that contains MPC8555 processor & DSP-core
> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of
> the MPC8555 processor.
>
> i test one interrupt from the DSP-core to the MPC8555 processor where i
> configure this interrupt line to be edge-triggered (falling edge) & i
> receive it successfully
> but
> when i generate this interrupt 10 successive times using for loop
> i just receive 2 interrupts?
>
> why can't i receive the 8 other interrupts?
> i print the value of every irq number inside do_IRQ & i found that i receive
> the DSP-interrupt just only twice.
>
> do u have any suggestions to solve this problem?
> i want to make sure that i can receive 10 interrupts
Don't do a printk() with interrupts disabled. A printk() takes 1.5ms
on a mpc5200.
> --
> View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23901807.html
> Sent from the linuxppc-dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Missing some interrupts
From: wael showair @ 2009-06-06 13:17 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
i have a freescale board, that contains MPC8555 processor & DSP-core
there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of
the MPC8555 processor.
i test one interrupt from the DSP-core to the MPC8555 processor where i
configure this interrupt line to be edge-triggered (falling edge) & i
receive it successfully
but
when i generate this interrupt 10 successive times using for loop
i just receive 2 interrupts?
why can't i receive the 8 other interrupts?
i print the value of every irq number inside do_IRQ & i found that i receive
the DSP-interrupt just only twice.
do u have any suggestions to solve this problem?
i want to make sure that i can receive 10 interrupts
--
View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23901807.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Wolfram Sang @ 2009-06-06 11:19 UTC (permalink / raw)
To: David Woodhouse
Cc: devicetree-discuss, albrecht.dress, linuxppc-dev, linux-mtd,
Ben Dooks
In-Reply-To: <1244276049.3751.1176.camel@macbook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
On Sat, Jun 06, 2009 at 09:14:08AM +0100, David Woodhouse wrote:
> On Fri, 2009-06-05 at 14:05 +0200, Wolfram Sang wrote:
> > Create an of-aware driver using the now exported generic functions from
> > plat-ram.c. Also add the documentation for the binding. Partitions are
> > not yet supported. Tested on a phyCORE-MPC5200B-IO.
>
> Do we have an ack for the device-tree bindings?
>
> It _would_ be possible to hook up RAM through the existing of_physmap
> driver, I think -- although it would be slightly less efficient that
> way.
>
> Maybe cleaner from the device-tree POV though. And if we want to put a
> special case in the _code_ to make it more efficient, we can do that.
During development, I also checked physmap_of.c and found this binding:
{
.type = "rom",
.compatible = "direct-mapped"
},
which made some sense to me and I thought about .type = "ram". However, I then
found this in the code:
/* Helper function to handle probing of the obsolete "direct-mapped"
* compatible binding, which has an extra "probe-type" property
* describing the type of flash probe necessary. */
static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
struct map_info *map)
{
[...]
dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
"flash binding\n");
My conclusion was then that a mtd-ram binding wouldn't belong here, but I have
maybe misinterpreted things...
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: mailing list moving
From: Michael Ellerman @ 2009-06-06 8:37 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, linuxppc-dev-owner
In-Reply-To: <20090605190831.c5d59095.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
On Fri, 2009-06-05 at 19:08 +1000, Stephen Rothwell wrote:
> Hi Michael,
>
> On Fri, 05 Jun 2009 17:38:40 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > On Fri, 2009-06-05 at 17:26 +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > On Sun, 31 May 2009 15:09:50 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > The archives on lists.ozlabs.org (and ozlabs.org) have unfortunately not
> > > retained their URLs (the basename of the article URLs changed).
> >
> > Would a rewrite rule fix it? It'd be nice for them to keep working.
>
> No, because the actual article numbers changed when I rebuilt the archive
> on the new server.
>
> Sorry.
>
> I do, however, have the old archives, so maybe we can do something ...
We could use the old archive to work out the mapping between old and new
and write a billion rewrite rules, but it'd probably crash the rewrite
code - and if not slow the server to a crawl.
So into the too hard basket I think :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: David Woodhouse @ 2009-06-06 8:14 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, albrecht.dress, linuxppc-dev, linux-mtd,
Ben Dooks
In-Reply-To: <1244203514-12516-3-git-send-email-w.sang@pengutronix.de>
On Fri, 2009-06-05 at 14:05 +0200, Wolfram Sang wrote:
> Create an of-aware driver using the now exported generic functions from
> plat-ram.c. Also add the documentation for the binding. Partitions are
> not yet supported. Tested on a phyCORE-MPC5200B-IO.
Do we have an ack for the device-tree bindings?
It _would_ be possible to hook up RAM through the existing of_physmap
driver, I think -- although it would be slightly less efficient that
way.
Maybe cleaner from the device-tree POV though. And if we want to put a
special case in the _code_ to make it more efficient, we can do that.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: David Woodhouse @ 2009-06-06 7:25 UTC (permalink / raw)
To: dedekind; +Cc: linuxppc-dev, Stefan Roese, linux-mtd, devicetree-discuss
In-Reply-To: <1239956778.3390.262.camel@localhost.localdomain>
On Fri, 2009-04-17 at 11:26 +0300, Artem Bityutskiy wrote:
>
> I'm going to try to help you. I've just created a git tree where
> I'll push patches I consider OK and I approve. Here it is:
> git://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>
> My hope is that you would look at that tree from time to time
> and pull it. At least you may be sure I looked at the patches and
> did some validation. This should save your time and help MTD
> users.
This was _really_ useful. Thank you very much.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Greg KH @ 2009-06-06 5:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Ian Abbott, Frank Mori Hess
Cc: sachinp, sfr, linux-kernel, Linuxppc-dev, linux-next, paulus,
Geert.Uytterhoeven, geert, subrata, David Miller
In-Reply-To: <1244261806.31984.36.camel@pasglop>
On Sat, Jun 06, 2009 at 02:16:46PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote:
> > >
> > > Read my reply to Greg. Why the heck are you trying to map memory
> > > non-cacheable in the first place ?
> >
> > I agree, this is extremely fishy.
> >
> > I guess the issue is that the driver wants consistent DMA memory
> > but wants to allocate a huge area vmap() style.
>
> That's my guess too, and I suppose we should be able to provide an
> appropriate interface for that... There are two aspects that
> are completely separate here:
>
> - One is the allocation of the pages themselves which much match
> the various criteria for DMA'bility to the target device (fit the
> DMA mask, etc...)
>
> - One is the creation of the virtual mapping in kernel space for which
> appropriate pgprot for DMA must be provided.
>
> For the first one, I don't know how legit it would be to allocate the
> pages using dma_alloc_coherent one page at a time and try to figure out
> the struct page * out of it. Sounds fishy and possibly non-portable. So
> appart from using normal GFP and crossing fingers I'm not sure what
> would be the right way to obtain the pages in the first place. Maybe we
> should provide something.
>
> The second could be as simple as having a pgprot_dma_coherent() like we
> have a pgprot_uncached() for example, which would be either uncached or
> cached depending on the consistency of DMA on the platform. But we need
> to run that through things like MIPS which may have additional virtual
> address space requirements.
All good questions. So, let's ask the original authors :)
Frank and Ian, any thoughts about the vmap call in the
comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
is the prealloc_buf buffer used for?
The problem is that PAGE_KERNEL_NOCACHE isn't a "standard" interface,
and not all architectures support it.
thanks,
greg k-h
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Benjamin Herrenschmidt @ 2009-06-06 4:16 UTC (permalink / raw)
To: David Miller
Cc: sachinp, sfr, greg, linux-kernel, Linuxppc-dev, linux-next,
paulus, Geert.Uytterhoeven, geert, subrata
In-Reply-To: <20090605.175656.95336229.davem@davemloft.net>
On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote:
> >
> > Read my reply to Greg. Why the heck are you trying to map memory
> > non-cacheable in the first place ?
>
> I agree, this is extremely fishy.
>
> I guess the issue is that the driver wants consistent DMA memory
> but wants to allocate a huge area vmap() style.
That's my guess too, and I suppose we should be able to provide an
appropriate interface for that... There are two aspects that
are completely separate here:
- One is the allocation of the pages themselves which much match
the various criteria for DMA'bility to the target device (fit the
DMA mask, etc...)
- One is the creation of the virtual mapping in kernel space for which
appropriate pgprot for DMA must be provided.
For the first one, I don't know how legit it would be to allocate the
pages using dma_alloc_coherent one page at a time and try to figure out
the struct page * out of it. Sounds fishy and possibly non-portable. So
appart from using normal GFP and crossing fingers I'm not sure what
would be the right way to obtain the pages in the first place. Maybe we
should provide something.
The second could be as simple as having a pgprot_dma_coherent() like we
have a pgprot_uncached() for example, which would be either uncached or
cached depending on the consistency of DMA on the platform. But we need
to run that through things like MIPS which may have additional virtual
address space requirements.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-06-06 3:59 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev, devicetree-discuss, David Woodhouse
In-Reply-To: <200904161549.44841.sr@denx.de>
On Thursday 16 April 2009 15:49:44 Stefan Roese wrote:
> > Okay. It will be good to get this one into -next for some testing
> > exposure. Unless he asks me to do otherwise, I'll leave this one to
> > David to pick up.
>
> Understood. Thanks Grant.
David, just checking on the status of this patch. Is it in your queue for the
next merge window?
Thanks,
Stefan
^ 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