* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Michael Ellerman @ 2009-08-03 2:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249079342.1509.99.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
> > > /* XXX This clear should ultimately be part of
> > local_flush_tlb_mm */
> > > - __clear_bit(id, stale_map[cpu]);
> > > + for (cpu = cpu_first_thread_in_core(cpu);
> > > + cpu <= cpu_last_thread_in_core(cpu); cpu++)
> > > + __clear_bit(id, stale_map[cpu]);
> > > }
> >
> > This looks a bit dodgy. using 'cpu' as both the loop variable and
> > what you are computing to determine loop start/end..
> >
> Hrm... I would have thought that it was still correct... do you see any
> reason why the above code is wrong ? because if not we may be hitting a
> gcc issue...
>
> IE. At loop init, cpu gets clamped down to the first thread in the core,
> which should be fine. Then, we compare CPU to the last thread in core
> for the current CPU which should always return the same value.
>
> So I'm very interested to know what is actually wrong, ie, either I'm
> just missing something obvious, or you are just pushing a bug under the
> carpet which could come back and bit us later :-)
for (cpu = cpu_first_thread_in_core(cpu);
cpu <= cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu <= cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu = 0
cpu <= 1
cpu++ (1)
cpu <= 1
cpu++ (2)
cpu <= 3
...
:)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* How to setup a 1:1 mapping on E500 v2 ?
From: wilbur.chan @ 2009-08-02 23:59 UTC (permalink / raw)
To: linuxppc-dev
As we know, we can't turn off MMU on E500.
I want to setup a 1:1 mapping on SMP E500 v2, and I used 4 Entries of
256M to form a 1G mapping.
Here are my codes, but when I used rfi , it didn't jump to the
required instruction.
0---256M:
lis r6,FSL_BOOKE_MAS0(1, 14, 0)@h
ori r6,r6,FSL_BOOKE_MAS0(1, 14, 0)@l
lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@h
ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@l
lis r8,FSL_BOOKE_MAS2(0x00000000, (MAS2_I|MAS2_G))@h
ori r8,r8,FSL_BOOKE_MAS2(0x00000000, (MAS2_I|MAS2_G))@l
lis r9,FSL_BOOKE_MAS3(0x00000000, 0,
(MAS3_SX|MAS3_SW|MAS3_SR))@h
ori r9,r9,FSL_BOOKE_MAS3(0x00000000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
256---512M:
lis r6,FSL_BOOKE_MAS0(1, 13, 0)@h
ori r6,r6,FSL_BOOKE_MAS0(1, 13, 0)@l
lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@h
ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@l
lis r8,FSL_BOOKE_MAS2(0x10000000, (MAS2_I|MAS2_G))@h
ori r8,r8,FSL_BOOKE_MAS2(0x10000000, (MAS2_I|MAS2_G))@l
lis r9,FSL_BOOKE_MAS3(0x10000000, 0,
(MAS3_SX|MAS3_SW|MAS3_SR))@h
ori r9,r9,FSL_BOOKE_MAS3(0x10000000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
So are 512---768M, 768M----1GB...
#define FSL_BOOKE_MAS0(tlbsel,esel,nv) \
(MAS0_TLBSEL(tlbsel) | MAS0_ESEL(esel) | MAS0_NV(nv))
#define FSL_BOOKE_MAS1(v,iprot,tid,ts,tsize) \
((((v) << 31) & MAS1_VALID) |\
(((iprot) << 30) & MAS1_IPROT) |\
(MAS1_TID(tid)) |\
(((ts) << 12) & MAS1_TS) |\
(MAS1_TSIZE(tsize)))
#define FSL_BOOKE_MAS2(epn, wimge) \
(((epn) & MAS3_RPN) | (wimge))
#define FSL_BOOKE_MAS3(rpn, user, perms) \
(((rpn) & MAS3_RPN) | (user) | (perms))
I also setup a 1MB mapping for serial,so I can trap the codes,and it
works well.However, rfi doesn't:
Pseudo-code :
relocate_new_kernel:
setup_entry_for_serial();
print('x');
setup_entry(EPN=512M,RPN=512M,size=256M);
addi r8, r4, 1f - relocate_new_kernel
mtspr SPRN_SRR0, r8
rfi
1: print('y');
Here, x is printed, but y isn't.
Anyone please tell me why ?
Thank you very much.
regards,
wilbur
^ permalink raw reply
* Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
From: Benjamin Herrenschmidt @ 2009-08-02 23:13 UTC (permalink / raw)
To: Stef Simoens; +Cc: FUJITA Tomonori, James Bottomley, linuxppc-dev, linux-scsi
In-Reply-To: <4A7553E7.6030804@scarlet.be>
On Sun, 2009-08-02 at 10:52 +0200, Stef Simoens wrote:
> Hey Benjamin,
>
Thanks for the bisection. I'll have a look when I'm back from skiing :-)
In the meantime, maybe Fujita has an idea ?
Mesh is an old crappy piece of HW with an old driver full of dark
secrets that Paulus wrote eons ago, so I'd rather avoid cracking it
open :-)
Cheers,
Ben.
> Benjamin Herrenschmidt schreef:
> > On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
> >
> > > What would be the best approach?
> > > - if the kernel boots, it's obviously 'good'
> > > - but what if the kernel hits the 'BUG', should I apply your patch
> > > then? If it doesn't work with your patch, would it be 'bad' then?
> > >
> A few reboots later...
> As you said, during my bisecting, at a certain moment I needed your
> patch (I booted, got a problem, patched the tree with your patch,
> rebooted, it worked).
>
> Then, git says:
> f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit
> commit f078727b250c2653fc9a564f15547c17ebac3f99
> Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Date: Sun Dec 14 01:23:45 2008 +0900
>
> [SCSI] remove scsi_req_map_sg
>
> No one uses scsi_execute_async with data transfer now. We can
> remove
> scsi_req_map_sg.
>
> Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door
> doesn't handle sense and the callback. So we can remove
> scsi_io_context too.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Signed-off-by: James Bottomley
> <James.Bottomley@HansenPartnership.com>
>
> :040000 040000 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44
> 3ffca800399e52ef12f1001721c0c7ff431efafd M drivers
> :040000 040000 805c02c4ad3c63c45dffa18f413e92bfca99caf6
> 6fb58bb5fb19c4198fa7d626d6241086655c6307 M include
>
> At this moment, the reason for the crash is different then in v2.6.30
> I noted the following (I hope to have written the most important
> stuff).
> driver 'sd' needs update
> mesh: lost arbitration
> sd 0:0:0:0 sda read CAPACITY failed
> sd ...
> sd 0:0:0:0 sdb read CAPACITY failed
> sd ...
> mice
> sd ...
> mice: PS/2 ...
> TCP cubic ...
> Initializing XFRM ...
> NET ... protcol 17
> XFS ...
> VFS : unable to mount root FS
>
> If you want more input ... please let me know.
> --
> Kr,
> Stef Simoens
> plain text document attachment (git-bisect-log)
> git bisect start
> # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
> git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
> # bad: [577c9c456f0e1371cbade38eaf91ae8e8a308555] Linux 2.6.30-rc1
> git bisect bad 577c9c456f0e1371cbade38eaf91ae8e8a308555
> # bad: [5658ae9007490c18853fbf112f1b3516f5949e62] V4L/DVB (10342): gspca - stv06xx: Add ctrl caching to the vv6410.
> git bisect bad 5658ae9007490c18853fbf112f1b3516f5949e62
> # good: [08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
> git bisect good 08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6
> # good: [6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2
> git bisect good 6e15cf04860074ad032e88c306bea656bbdd0f22
> # bad: [eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30] Merge git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-for-30
> git bisect bad eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30
> # good: [0870352bc6e0dee485c86a0c99dd60e7089c8917] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
> git bisect good 0870352bc6e0dee485c86a0c99dd60e7089c8917
> # good: [febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
> git bisect good febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a
> # bad: [21283916322f579a580e413652cdefbfa3ec676f] [SCSI] zfcp: remove undefined subtype for status read response
> git bisect bad 21283916322f579a580e413652cdefbfa3ec676f
> # good: [6864abd8b730435d6ae9cb061095229a5a85153f] [SCSI] osd: Kconfig file for in-tree builds
> git bisect good 6864abd8b730435d6ae9cb061095229a5a85153f
> # bad: [b3f1f9aa082b2ab86dec4db3d8b1566af345387e] [SCSI] ses: code_set == 1 is tested twice
> git bisect bad b3f1f9aa082b2ab86dec4db3d8b1566af345387e
> # bad: [ea41e41588c248ee8b8162869c1e1c0565a4b3f6] [SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler
> git bisect bad ea41e41588c248ee8b8162869c1e1c0565a4b3f6
> # bad: [f078727b250c2653fc9a564f15547c17ebac3f99] [SCSI] remove scsi_req_map_sg
> git bisect bad f078727b250c2653fc9a564f15547c17ebac3f99
> # good: [78a42ce8fb2604c459e9ebb2a4f2d546b8250111] [SCSI] osst: make all the buffer the same size
> git bisect good 78a42ce8fb2604c459e9ebb2a4f2d546b8250111
> # good: [26243043f207b3faa00594a33e10b2103205f27b] [SCSI] osst: replace scsi_execute_async with the block layer API
> git bisect good 26243043f207b3faa00594a33e10b2103205f27b
^ permalink raw reply
* Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
From: Stef Simoens @ 2009-08-02 8:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1248915149.1509.29.camel@pasglop>
[-- Attachment #1.1: Type: text/plain, Size: 1877 bytes --]
Hey Benjamin,
Benjamin Herrenschmidt schreef:
> On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
>
>> What would be the best approach?
>> - if the kernel boots, it's obviously 'good'
>> - but what if the kernel hits the 'BUG', should I apply your patch
>> then? If it doesn't work with your patch, would it be 'bad' then?
>>
A few reboots later...
As you said, during my bisecting, at a certain moment I needed your
patch (I booted, got a problem, patched the tree with your patch,
rebooted, it worked).
Then, git says:
f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit
commit f078727b250c2653fc9a564f15547c17ebac3f99
Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Sun Dec 14 01:23:45 2008 +0900
[SCSI] remove scsi_req_map_sg
No one uses scsi_execute_async with data transfer now. We can remove
scsi_req_map_sg.
Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door
doesn't handle sense and the callback. So we can remove
scsi_io_context too.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
:040000 040000 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44
3ffca800399e52ef12f1001721c0c7ff431efafd M drivers
:040000 040000 805c02c4ad3c63c45dffa18f413e92bfca99caf6
6fb58bb5fb19c4198fa7d626d6241086655c6307 M include
At this moment, the reason for the crash is different then in v2.6.30
I noted the following (I hope to have written the most important stuff).
driver 'sd' needs update
mesh: lost arbitration
sd 0:0:0:0 sda read CAPACITY failed
sd ...
sd 0:0:0:0 sdb read CAPACITY failed
sd ...
mice
sd ...
mice: PS/2 ...
TCP cubic ...
Initializing XFRM ...
NET ... protcol 17
XFS ...
VFS : unable to mount root FS
If you want more input ... please let me know.
--
Kr,
Stef Simoens
[-- Attachment #1.2: Type: text/html, Size: 3005 bytes --]
[-- Attachment #2: git-bisect-log --]
[-- Type: text/plain, Size: 2477 bytes --]
git bisect start
# good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
# bad: [577c9c456f0e1371cbade38eaf91ae8e8a308555] Linux 2.6.30-rc1
git bisect bad 577c9c456f0e1371cbade38eaf91ae8e8a308555
# bad: [5658ae9007490c18853fbf112f1b3516f5949e62] V4L/DVB (10342): gspca - stv06xx: Add ctrl caching to the vv6410.
git bisect bad 5658ae9007490c18853fbf112f1b3516f5949e62
# good: [08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
git bisect good 08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6
# good: [6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2
git bisect good 6e15cf04860074ad032e88c306bea656bbdd0f22
# bad: [eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30] Merge git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-for-30
git bisect bad eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30
# good: [0870352bc6e0dee485c86a0c99dd60e7089c8917] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
git bisect good 0870352bc6e0dee485c86a0c99dd60e7089c8917
# good: [febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect good febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a
# bad: [21283916322f579a580e413652cdefbfa3ec676f] [SCSI] zfcp: remove undefined subtype for status read response
git bisect bad 21283916322f579a580e413652cdefbfa3ec676f
# good: [6864abd8b730435d6ae9cb061095229a5a85153f] [SCSI] osd: Kconfig file for in-tree builds
git bisect good 6864abd8b730435d6ae9cb061095229a5a85153f
# bad: [b3f1f9aa082b2ab86dec4db3d8b1566af345387e] [SCSI] ses: code_set == 1 is tested twice
git bisect bad b3f1f9aa082b2ab86dec4db3d8b1566af345387e
# bad: [ea41e41588c248ee8b8162869c1e1c0565a4b3f6] [SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler
git bisect bad ea41e41588c248ee8b8162869c1e1c0565a4b3f6
# bad: [f078727b250c2653fc9a564f15547c17ebac3f99] [SCSI] remove scsi_req_map_sg
git bisect bad f078727b250c2653fc9a564f15547c17ebac3f99
# good: [78a42ce8fb2604c459e9ebb2a4f2d546b8250111] [SCSI] osst: make all the buffer the same size
git bisect good 78a42ce8fb2604c459e9ebb2a4f2d546b8250111
# good: [26243043f207b3faa00594a33e10b2103205f27b] [SCSI] osst: replace scsi_execute_async with the block layer API
git bisect good 26243043f207b3faa00594a33e10b2103205f27b
^ permalink raw reply
* [PATCH 11/15] arch/powerpc: Use DIV_ROUND_CLOSEST
From: Julia Lawall @ 2009-08-02 8:48 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
but is perhaps more readable.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@haskernel@
@@
#include <linux/kernel.h>
@depends on haskernel@
expression x,__divisor;
@@
- (((x) + ((__divisor) / 2)) / (__divisor))
+ DIV_ROUND_CLOSEST(x,__divisor)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/kernel/time.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index eae4511..edb1edb 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -479,7 +479,8 @@ static int __init iSeries_tb_recal(void)
unsigned long tb_ticks = tb - iSeries_recal_tb;
unsigned long titan_usec = (titan - iSeries_recal_titan) >> 12;
unsigned long new_tb_ticks_per_sec = (tb_ticks * USEC_PER_SEC)/titan_usec;
- unsigned long new_tb_ticks_per_jiffy = (new_tb_ticks_per_sec+(HZ/2))/HZ;
+ unsigned long new_tb_ticks_per_jiffy =
+ DIV_ROUND_CLOSEST(new_tb_ticks_per_sec, HZ);
long tick_diff = new_tb_ticks_per_jiffy - tb_ticks_per_jiffy;
char sign = '+';
/* make sure tb_ticks_per_sec and tb_ticks_per_jiffy are consistent */
^ permalink raw reply related
* [PATCH 2/10] arch/powerpc: introduce missing kfree
From: Julia Lawall @ 2009-08-02 8:44 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/sysdev/ipic.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 69e2630..040144e 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -735,8 +735,10 @@ struct ipic * __init ipic_init(struct device_node *node, unsigned int flags)
ipic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_IPIC_INTS,
&ipic_host_ops, 0);
- if (ipic->irqhost == NULL)
+ if (ipic->irqhost == NULL) {
+ kfree(ipic);
return NULL;
+ }
ipic->regs = ioremap(res.start, res.end - res.start + 1);
^ permalink raw reply related
* Re: [PATCH] Fix perfctr oops on ppc32
From: Benjamin Herrenschmidt @ 2009-08-02 7:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1249133370.24204.3.camel@macbook.infradead.org>
On Sat, 2009-08-01 at 14:29 +0100, David Woodhouse wrote:
> This seems to be the reason why the Fedora rawhide 2.6.31-rc kernel
> doesn't boot. With some CPUs, cur_cpu_spec->oprofile_cpu_type can be
> NULL -- which makes strcmp() unhappy.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Thanks David !
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Paulus, do you want to put that in your new perfctr-powerpc tree or I'll
just stick that in my merge brange next week along with other fixes ?
Cheers,
Ben.
> ---
> At first glance, it looks like there are a bunch of other places which
> use cur_cpu_spec->oprofile_cpu_type without first checking if it's
> non-NULL, but maybe those are all 64-bit and all 64-bit cpu types have
> it set?
>
> diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/powerpc/kernel/mpc7450-pmu.c
> index 75ff47f..ea383c1 100644
> --- a/arch/powerpc/kernel/mpc7450-pmu.c
> +++ b/arch/powerpc/kernel/mpc7450-pmu.c
> @@ -408,7 +408,8 @@ struct power_pmu mpc7450_pmu = {
>
> static int init_mpc7450_pmu(void)
> {
> - if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
> + if (cur_cpu_spec->oprofile_cpu_type &&
> + strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
> return -ENODEV;
>
> return register_power_pmu(&mpc7450_pmu);
>
>
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: Benjamin Herrenschmidt @ 2009-08-02 7:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1249117220.20192.1083.camel@macbook.infradead.org>
On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
> I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
> doesn't seem ideal, and we'll want to make the no-iommu code DTRT
> _anyway_, surely?
>
> So we might as well let the DART keep its existing logic (which is
> only
> to bother if we have more than 1GiB of RAM;
Ah right, so when do we enable the DART ? Above 1G ? I though it was
above 2G but we may well have moved that down to 1G just for b43 indeed.
I definitely agree on the fix to the mask so it only compares to the
available RAM. I'll check that in when I'm back from the snow fields
on tuesday :-)
Cheers,
Ben,
^ permalink raw reply
* Re:[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
From: wilbur.chan @ 2009-08-02 1:25 UTC (permalink / raw)
To: bigeasy; +Cc: linuxppc-dev
Hi, Sebastian,
>From: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
>The relocate_new_kernel() code usually disables the MMU and the small code
>operates on physicall pages while moving the kernel to its final position.
>Book-E doesn't support this so a 1:1 mapping must be created.
>This patch adds support for FSL-BOOK-E implementation.
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
>+ xori r6,r4,1 /* Setup TMP mapping in the other A=
ddress space */
>+ slwi r6,r6,12
>+ oris r6,r6,(MAS1_VALID|MAS1_IPROT)@h
>+ ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_1GB))@l
>+ mtspr SPRN_MAS1,r6
>.........
>+ /* find our address */
>+ addi r7, r30, final_copy_code - relocate_new_kernel
>+
>+ mtspr SPRN_SRR0,r7
>+ mtspr SPRN_SRR1,r6
>+ rfi
...........................................................................=
.................................................................
In your patch of Booke support for kexec , it setup a 1GB TMP mapping
and jump to it.
But I saw that, the max size for an e500 entry is 256M=A3=ACso I changed
your code to setup 4*256M entries, and it works well on mpc8541.
Howerver,it didn't work on mpc8548(e500 v2) and
P2020ds(SMP,e500 v2) , and 'rfi' to final_copy_code failed.(I also
setup a 1:1 mapping for serial ,so I can trap the flowchart in
relocate_new_kernel)
Any suggestions about this ? Thank you very much.
regards,
wilbur
^ permalink raw reply
* Re: [PATCH 3/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:55 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, Richard Lary, Paul Mackerras, linux-pci
In-Reply-To: <4A7221DF.5040402@us.ibm.com>
2009/7/30 Mike Mason <mmlnx@us.ibm.com>:
> This is the third of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot rese=
t"
> during recovery of a PCI Express device. =C2=A0We've found a case where t=
he
> device needs a "fundamental reset" to recover properly. =C2=A0The current=
PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch makes changes to EEH to utilize the new bit field.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
>
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> Signed-off-by: Richard Lary <rlary@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
> + =C2=A0 =C2=A0 =C2=A0 /* Determine type of EEH reset required by device,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* default hot reset or fundamental reset
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 if (dev->needs_freset)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rtas_pci_slot_reset(pd=
n, 3);
> + =C2=A0 =C2=A0 =C2=A0 else
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rtas_pci_slot_reset(pd=
n, 1);
Gack! I remember deluges of emails and conference calls
where the hardware guys went on about this; and I admit I didn't
quite get it, which I guess is why this patch is showing up many
years late.
FWIW some of the variants of the IPR chipset almost surely
need the freset bit set.
--linas
^ permalink raw reply
* Re: [PATCH 2/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:17 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, Richard Lary, Paul Mackerras, linux-pci
In-Reply-To: <4A722121.4010307@us.ibm.com>
2009/7/30 Mike Mason <mmlnx@us.ibm.com>:
> This is the second of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot rese=
t"
> during recovery of a PCI Express device. =C2=A0We've found a case where t=
he
> device needs a "fundamental reset" to recover properly. =C2=A0The current=
PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch updates the Documentation/PCI/pci-error-recovery.txt f=
ile
> with changes related to this new bit field, as well a few unrelated updat=
es.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> Signed-off-by: Richard Lary <rlary@us.ibm.com>
FWIW,
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:43 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, Richard Lary, Paul Mackerras, linux-pci
In-Reply-To: <4A721FB1.4040903@us.ibm.com>
2009/7/30 Mike Mason <mmlnx@us.ibm.com>:
> This is the first of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot rese=
t"
> during recovery of a PCI Express device. =C2=A0We've found a case where t=
he
> device needs a "fundamental reset" to recover properly. =C2=A0The current=
PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev
> that indicates whether the device requires a fundamental reset during
> recovery.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> Signed-off-by: Richard Lary <rlary@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:40 UTC (permalink / raw)
To: Andi Kleen; +Cc: linuxppc-dev, Paul Mackerras, Richard Lary, linux-pci
In-Reply-To: <87hbws3jvx.fsf@basil.nowhere.org>
Hi Andi,
2009/7/31 Andi Kleen <andi@firstfloor.org>:
> Mike Mason <mmlnx@us.ibm.com> writes:
>>
>> These patches supersede the previously submitted patch that
>> implemented a fundamental reset bit field.
>>
>> Please review and let me know of any concerns.
>
> Any plans to implement that for x86 too? Right now it seems to be a PPC
> specific hack.
I've found the PCIE chipsepc somewhat daunting, but was under the
impression that much if not most of what was needed was specified
there.
See, for example:
Documentation/PCI/pcieaer-howto.txt
which states:
||| The PCI Express Advanced Error Reporting Driver Guide HOWTO
||| T. Long Nguyen <tom.l.nguyen@intel.com>
||| Yanmin Zhang <yanmin.zhang@intel.com>
||| 07/29/2006
[..]
||| The PCI Express AER driver provides the infrastructure to support PCI
||| Express Advanced Error Reporting capability. The PCI Express AER
||| driver provides three basic functions:
|||
||| - Gathers the comprehensive error information if errors occurred.
||| - Reports error to the users.
||| - Performs error recovery actions.
I presume the last bullet point means that the AER code works and
actually does more or less the same thing as the PPC EEH code,
but in a more architecture-independent way, as it only assumes
that PCI AER is there (and is correctly implemented in the CPI chipset)
The AER code uses the same core infrastructure as the EEH code,
at the time, I did exchange emails w/ the above authors discussing
this stuff.
As to whether the x86 server vendors are actually selling something
with AER in it, and whether any of them are actually testing this stuff
is unclear.
FWIW IBM has pretty much no incentive to lobby other server vendors
to get on the ball ...as this is viewed as one of those things that lets
IBM charge premium prices for PPC hardware.
--linas
^ permalink raw reply
* [PATCH] Fix perfctr oops on ppc32
From: David Woodhouse @ 2009-08-01 13:29 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
This seems to be the reason why the Fedora rawhide 2.6.31-rc kernel
doesn't boot. With some CPUs, cur_cpu_spec->oprofile_cpu_type can be
NULL -- which makes strcmp() unhappy.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
At first glance, it looks like there are a bunch of other places which
use cur_cpu_spec->oprofile_cpu_type without first checking if it's
non-NULL, but maybe those are all 64-bit and all 64-bit cpu types have
it set?
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/powerpc/kernel/mpc7450-pmu.c
index 75ff47f..ea383c1 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -408,7 +408,8 @@ struct power_pmu mpc7450_pmu = {
static int init_mpc7450_pmu(void)
{
- if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
+ if (cur_cpu_spec->oprofile_cpu_type &&
+ strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
return -ENODEV;
return register_power_pmu(&mpc7450_pmu);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply related
* Re: [PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree
From: Timur Tabi @ 2009-08-01 12:25 UTC (permalink / raw)
To: Julia Lawall; +Cc: linuxppc-dev, kernel-janitors, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0908011052290.23408@ask.diku.dk>
On Sat, Aug 1, 2009 at 3:52 AM, Julia Lawall<julia@diku.dk> wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Error handling code following a kzalloc should free the allocated data.
>
...
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
> ---
> =A0arch/powerpc/sysdev/qe_lib/qe_ic.c =A0| =A0 =A05 ++++-
> =A01 files changed, 4 insertions(+), 1 deletions(-)
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: David Woodhouse @ 2009-08-01 9:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249113656.1509.125.camel@pasglop>
On Sat, 2009-08-01 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 08:54 +0100, David Woodhouse wrote:
> > On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> > > > On an iMac G5, the b43 driver is failing to initialise because trying to
> > > > set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> > > > in the machine anyway:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=514787
> > > >
> > > > We should probably let it succeed if the available RAM in the system
> > > > doesn't exceed the requested limit.
> > > >
> > > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> > >
> > > Also, isn't our iommu code smart enough to clamp allocations to the DMA
> > > mask nowadays ? In that case, we could probably just force iommu on
> > > always...
> >
> > We're not using the IOMMU on this box:
> >
> > PowerMac motherboard: iMac G5
> > DART: table not allocated, using direct DMA
>
> I know, I was suggesting we do :-)
I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
doesn't seem ideal, and we'll want to make the no-iommu code DTRT
_anyway_, surely?
So we might as well let the DART keep its existing logic (which is only
to bother if we have more than 1GiB of RAM; a limit chosen specifically
because of the Broadcom brokenness).
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* [PATCH 2/10] arch/powerpc: introduce missing kfree
From: Julia Lawall @ 2009-08-01 8:53 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/sysdev/ipic.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 69e2630..040144e 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -735,8 +735,10 @@ struct ipic * __init ipic_init(struct device_node *node, unsigned int flags)
ipic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_IPIC_INTS,
&ipic_host_ops, 0);
- if (ipic->irqhost == NULL)
+ if (ipic->irqhost == NULL) {
+ kfree(ipic);
return NULL;
+ }
ipic->regs = ioremap(res.start, res.end - res.start + 1);
^ permalink raw reply related
* [PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree
From: Julia Lawall @ 2009-08-01 8:52 UTC (permalink / raw)
To: timur, linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/sysdev/qe_lib/qe_ic.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 074905c..3faa42e 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -339,8 +339,10 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags,
qe_ic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_QE_IC_INTS, &qe_ic_host_ops, 0);
- if (qe_ic->irqhost == NULL)
+ if (qe_ic->irqhost == NULL) {
+ kfree(qe_ic);
return;
+ }
qe_ic->regs = ioremap(res.start, res.end - res.start + 1);
@@ -352,6 +354,7 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags,
if (qe_ic->virq_low == NO_IRQ) {
printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
+ kfree(qe_ic);
return;
}
^ permalink raw reply related
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: Benjamin Herrenschmidt @ 2009-08-01 8:00 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1249113285.20192.961.camel@macbook.infradead.org>
On Sat, 2009-08-01 at 08:54 +0100, David Woodhouse wrote:
> On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> > > On an iMac G5, the b43 driver is failing to initialise because trying to
> > > set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> > > in the machine anyway:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=514787
> > >
> > > We should probably let it succeed if the available RAM in the system
> > > doesn't exceed the requested limit.
> > >
> > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> >
> > Also, isn't our iommu code smart enough to clamp allocations to the DMA
> > mask nowadays ? In that case, we could probably just force iommu on
> > always...
>
> We're not using the IOMMU on this box:
>
> PowerMac motherboard: iMac G5
> DART: table not allocated, using direct DMA
I know, I was suggesting we do :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: David Woodhouse @ 2009-08-01 7:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249079105.1509.95.camel@pasglop>
On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> > On an iMac G5, the b43 driver is failing to initialise because trying to
> > set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> > in the machine anyway:
> > https://bugzilla.redhat.com/show_bug.cgi?id=514787
> >
> > We should probably let it succeed if the available RAM in the system
> > doesn't exceed the requested limit.
> >
> > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
> Also, isn't our iommu code smart enough to clamp allocations to the DMA
> mask nowadays ? In that case, we could probably just force iommu on
> always...
We're not using the IOMMU on this box:
PowerMac motherboard: iMac G5
DART: table not allocated, using direct DMA
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Benjamin Herrenschmidt @ 2009-07-31 22:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6FD94305-B60D-4DAF-8296-88345D11187F@kernel.crashing.org>
On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
> > /* XXX This clear should ultimately be part of
> local_flush_tlb_mm */
> > - __clear_bit(id, stale_map[cpu]);
> > + for (cpu = cpu_first_thread_in_core(cpu);
> > + cpu <= cpu_last_thread_in_core(cpu); cpu++)
> > + __clear_bit(id, stale_map[cpu]);
> > }
>
> This looks a bit dodgy. using 'cpu' as both the loop variable and
> what you are computing to determine loop start/end..
>
Hrm... I would have thought that it was still correct... do you see any
reason why the above code is wrong ? because if not we may be hitting a
gcc issue...
IE. At loop init, cpu gets clamped down to the first thread in the core,
which should be fine. Then, we compare CPU to the last thread in core
for the current CPU which should always return the same value.
So I'm very interested to know what is actually wrong, ie, either I'm
just missing something obvious, or you are just pushing a bug under the
carpet which could come back and bit us later :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: Benjamin Herrenschmidt @ 2009-07-31 22:25 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1249069310.20192.220.camel@macbook.infradead.org>
On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> On an iMac G5, the b43 driver is failing to initialise because trying to
> set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> in the machine anyway:
> https://bugzilla.redhat.com/show_bug.cgi?id=514787
>
> We should probably let it succeed if the available RAM in the system
> doesn't exceed the requested limit.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Also, isn't our iommu code smart enough to clamp allocations to the DMA
mask nowadays ? In that case, we could probably just force iommu on
always...
Cheers,
Ben.
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index 20a60d6..1769a8e 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -90,11 +90,11 @@ static void dma_direct_unmap_sg(struct device *dev,
> struct scatterlist *sg,
> static int dma_direct_dma_supported(struct device *dev, u64 mask)
> {
> #ifdef CONFIG_PPC64
> - /* Could be improved to check for memory though it better be
> - * done via some global so platforms can set the limit in case
> + extern unsigned long highest_memmap_pfn;
> + /* Could be improved so platforms can set the limit in case
> * they have limited DMA windows
> */
> - return mask >= DMA_BIT_MASK(32);
> + return (mask >> PAGE_SHIFT) >= highest_memmap_pfn;
> #else
> return 1;
> #endif
>
^ permalink raw reply
* question on PPC64 relocatable kernel
From: Ming Lei @ 2009-07-31 20:36 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
Hi,
I am researching PPC64 code and try to come up a design for relocatable ker=
nel for ppc32. I noticed that the current ppc64 implementation only changes=
all the entries in RELA table to add the offset from compile load address =
to relocated address, but not for GOT table. Does GOT entry need the adjust=
ment as well?
The second question is: does PPC64 relocatable kernel still needs to copy t=
he whole kernel from running address to address 0?
Thanks
Ming
^ permalink raw reply
* Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
From: Albrecht Dreß @ 2009-07-31 19:47 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Vitaly Wool, Artem Bityutskiy, linuxppc-dev,
linux-mtd, Ken MacLeod, David Woodhouse
In-Reply-To: <1247834363-28198-1-git-send-email-w.sang@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
Am 17.07.09 14:39 schrieb(en) Wolfram Sang:
> Use physmap_of to access RAMs as mtd and add documenation for it.
> This approach is a lot less intrusive as adding an of-wrapper around
> plat-ram.c. As most extensions of plat-ram.c (e.g. custom
> map-functions) can't be mapped to the device tree anyhow, extending
> physmap_of seems to be the cleanest approach.
The patch works nicely on a custom (roughly Icecube) based 5200B board,
with a Renesas static ram, no partitions and a jffs2 file system on
it. I had to add some more tweaks to physmap_of.c as to work around
the 5200's limitations accessing chips in 16-bit mode through the local
bus, which is a lot easier and cleaner with this patch than with the
old one (of 05 June 09).
Acked-by: Albrecht Dreß <albrecht.dress@arcor.de>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: David Woodhouse @ 2009-07-31 19:41 UTC (permalink / raw)
To: linuxppc-dev
On an iMac G5, the b43 driver is failing to initialise because trying to
set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
in the machine anyway:
https://bugzilla.redhat.com/show_bug.cgi?id=514787
We should probably let it succeed if the available RAM in the system
doesn't exceed the requested limit.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 20a60d6..1769a8e 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -90,11 +90,11 @@ static void dma_direct_unmap_sg(struct device *dev,
struct scatterlist *sg,
static int dma_direct_dma_supported(struct device *dev, u64 mask)
{
#ifdef CONFIG_PPC64
- /* Could be improved to check for memory though it better be
- * done via some global so platforms can set the limit in case
+ extern unsigned long highest_memmap_pfn;
+ /* Could be improved so platforms can set the limit in case
* they have limited DMA windows
*/
- return mask >= DMA_BIT_MASK(32);
+ return (mask >> PAGE_SHIFT) >= highest_memmap_pfn;
#else
return 1;
#endif
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply related
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