* Re: Bunch of fixes for upstream
From: Kumar Gala @ 2009-09-24 16:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1253775919.7103.428.camel@pasglop>
On Sep 24, 2009, at 12:05 AM, Benjamin Herrenschmidt wrote:
> Here's what I'll ask Linus to pull tomorrow, currently sitting in
> powerpc merge branch:
I need to send you a pull request. However being at plumbers finding
time to get the tree is proving difficult :)
- k
^ permalink raw reply
* Problem when loading initrd
From: wilbur.chan @ 2009-09-24 16:33 UTC (permalink / raw)
To: linuxppc-dev
I got some problems when starting a kernel withCONFIG_BLK_DEV_RAM and
using initrd-image (not cpio) (mpc85xx)
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 4096KiB [1 disk] into ram disk... RAMDISK: Loading
4096KiB [1 d
isk] into ram disk... done.
No filesystem could mount root, tried: No filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
kernel boot param: bootargs root=/dev/ram console=ttyS0,115200
I guess the problem lie in :
mount_root-->mount_block_root--->do_mount_root--->
sys_mount(name, "/root")
but I don't know where the problem is . Any suggestions? Thank you very much.
^ permalink raw reply
* lite5200b kernel not booting
From: Asier Llano Palacios @ 2009-09-24 14:41 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, Aitor Arzuaga
Hi Grant,
We've been working with a lite5200b for a while, we have been working
with the ppc platform in linux 2.6.x for 5 years and it worked properly
until 2.6.25 included. We want to switch to the powerpc platform but it
doesn't seem to work.
After the bootloader (tested with the uboot 1.2.0 and 2009.08) starts
the cuImage.lite5200 it doesn't show anything in the console.
I'd like to know if the lite5200b is still supported and which version
is known to work with it and what is the default configuration. I want
to test it like the developers do, until I configure it myself.
I've managed to do some debugging in assembler, to know that it works
properly until DCACHE is enabled in setup_common_caches of
arch/powerpc/kernel/cpu_setup_6xx.S. If I skip enabling the DCACHE it
continues properly until the MMU is enabled.
I'm only debugging it writing to the serial port registers in assembler,
so I'm not very sure if it continues properly or if I am not able to
debug it after the DCACHE is enabled or the MMU is enabled. I want to
debug it with a JTAG debugger, but I still don't have one (do you
recommend me anyone?).
Kind regards and thank you for the help,
Asier
^ permalink raw reply
* [PATCH v2 09/11] powerpc: Cleanup linker script using new linker script macros.
From: Tim Abbott @ 2009-09-24 14:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tim Abbott, Linux Kernel Mailing List, linuxppc-dev,
Paul Mackerras, Sam Ravnborg
In-Reply-To: <1253802986-8132-1-git-send-email-tabbott@ksplice.com>
Signed-off-by: Tim Abbott <tabbott@ksplice.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Acked-by: Sam Ravnborg <sam@ravnborg.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 69 ++++++++-----------------------------
1 files changed, 15 insertions(+), 54 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 58da407..f564293 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -6,6 +6,7 @@
#include <asm/page.h>
#include <asm-generic/vmlinux.lds.h>
#include <asm/cache.h>
+#include <asm/thread_info.h>
ENTRY(_stext)
@@ -71,12 +72,7 @@ SECTIONS
/* Read-only data */
RODATA
- /* Exception & bug tables */
- __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
- __start___ex_table = .;
- *(__ex_table)
- __stop___ex_table = .;
- }
+ EXCEPTION_TABLE(0)
NOTES :kernel :notes
@@ -93,12 +89,7 @@ SECTIONS
*/
. = ALIGN(PAGE_SIZE);
__init_begin = .;
-
- .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
- _sinittext = .;
- INIT_TEXT
- _einittext = .;
- } :kernel
+ INIT_TEXT_SECTION(PAGE_SIZE) :kernel
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
@@ -122,23 +113,16 @@ SECTIONS
#endif
}
- . = ALIGN(16);
.init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
- __setup_start = .;
- *(.init.setup)
- __setup_end = .;
+ INIT_SETUP(16)
}
.initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
- __initcall_start = .;
- INITCALLS
- __initcall_end = .;
- }
+ INIT_CALLS
+ }
.con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
- __con_initcall_start = .;
- *(.con_initcall.init)
- __con_initcall_end = .;
+ CON_INITCALL
}
SECURITY_INIT
@@ -169,14 +153,10 @@ SECTIONS
__stop___fw_ftr_fixup = .;
}
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
- . = ALIGN(PAGE_SIZE);
.init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
- __initramfs_start = .;
- *(.init.ramfs)
- __initramfs_end = .;
+ INIT_RAM_FS
}
-#endif
+
PERCPU(PAGE_SIZE)
. = ALIGN(8);
@@ -240,36 +220,24 @@ SECTIONS
#endif
/* The initial task and kernel stack */
-#ifdef CONFIG_PPC32
- . = ALIGN(8192);
-#else
- . = ALIGN(16384);
-#endif
.data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
- *(.data.init_task)
+ INIT_TASK_DATA(THREAD_SIZE)
}
- . = ALIGN(PAGE_SIZE);
.data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
- *(.data.page_aligned)
+ PAGE_ALIGNED_DATA(PAGE_SIZE)
}
- . = ALIGN(L1_CACHE_BYTES);
.data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
- *(.data.cacheline_aligned)
+ CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES)
}
- . = ALIGN(L1_CACHE_BYTES);
.data.read_mostly : AT(ADDR(.data.read_mostly) - LOAD_OFFSET) {
- *(.data.read_mostly)
+ READ_MOSTLY_DATA(L1_CACHE_BYTES)
}
- . = ALIGN(PAGE_SIZE);
.data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
- __nosave_begin = .;
- *(.data.nosave)
- . = ALIGN(PAGE_SIZE);
- __nosave_end = .;
+ NOSAVE_DATA
}
. = ALIGN(PAGE_SIZE);
@@ -280,14 +248,7 @@ SECTIONS
* And finally the bss
*/
- .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
- __bss_start = .;
- *(.sbss) *(.scommon)
- *(.dynbss)
- *(.bss)
- *(COMMON)
- __bss_stop = .;
- }
+ BSS_SECTION(0, 0, 0)
. = ALIGN(PAGE_SIZE);
_end = . ;
--
1.6.3.3
^ permalink raw reply related
* RE: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: John Linn @ 2009-09-24 13:42 UTC (permalink / raw)
To: Richard Röjfors
Cc: spi-devel-general, Andrew Morton, dbrownell, linuxppc-dev
In-Reply-To: <4ABB217D.9070708@mocean-labs.com>
> -----Original Message-----
> From: Richard R=F6jfors [mailto:richard.rojfors@mocean-labs.com]
> Sent: Thursday, September 24, 2009 1:36 AM
> To: John Linn
> Cc: spi-devel-general@lists.sourceforge.net; linuxppc-dev@ozlabs.org; And=
rew Morton;
> dbrownell@users.sourceforge.net
> Subject: Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platfor=
m driver, added support for
> DS570
> =
> Hi again,
> =
> John Linn wrote:
> >> -----Original Message-----
> >> From: Richard R=F6jfors [mailto:richard.rojfors@mocean-labs.com]
> >> Sent: Tuesday, September 22, 2009 3:59 PM
> >> To: John Linn
> >> Cc: spi-devel-general@lists.sourceforge.net; linuxppc-dev@ozlabs.org; =
Andrew Morton;
> >> dbrownell@users.sourceforge.net
> >> Subject: Re: [PATCH v3] xilinx_spi: Splitted into generic, of and plat=
form driver, added support
> for
> >> DS570
> >>
> >> John Linn wrote:
> >>>> -----Original Message-----
> >>>> From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@lists.ozlabs.org [=
mailto:linuxppc-dev-
> >>>> bounces+john.linn=3Dxilinx.com@lists.ozlabs.org] On Behalf Of Richar=
d R=F6jfors
> >>>> Sent: Tuesday, September 22, 2009 6:55 AM
> >>>> To: spi-devel-general@lists.sourceforge.net
> >>>> Cc: linuxppc-dev@ozlabs.org; Andrew Morton; dbrownell@users.sourcefo=
rge.net
> >>>> Subject: [PATCH v3] xilinx_spi: Splitted into generic, of and platfo=
rm driver, added support for
> >>>> DS570
> >>>>
> >>>> This patch splits xilinx_spi into three parts, an OF and a platform
> >>>> driver and generic part.
> >>>>
> >>>> The generic part now also works on X86 and also supports the Xilinx
> >>>> SPI IP DS570
> >>> Hi Richard,
> >> Hi John,
> >>
> >>> The current driver (without this change) works for the newer XPS SPI =
device already as I run
> tests
> >> on it each day using an SPI EEPROM.
> >>
> >> I'm not an expert of the Xilinx SPI blocks, I have only used one, the =
DS570.
> >>
> >> I don't think you use the DS570. I don't have the datasheet of the old=
er one, but the register
> >> offsets of the DS570 don't match the driver you are using. All the reg=
isters of the DS570 are at 4
> >> bytes boundries.
> >>
> >
> > I just verified that I am using the same IP block as you are, the DS570=
. But I'm not testing on the
> other IP you mention, the DS464.
> =
> Hi,
> =
> I have now verified the differences. Actually the blocks are register off=
set compatible. Since the
> DS464 is 8 bit only, the driver is made to do only 8 bit accesses to some=
registers, for instance
> TXD. On the 570 we have to do 32 bit (or at least 16) as the driver now s=
upport more than 8bit SPI.
> We test against some SPI devices that are 16 bit.
> The offsets in the code differs from the datasheet because since the devi=
ce is big endian -> an 8
> bit access to must happen 3 bytes up from the register base.
> =
> For instance the TXD register is defined at 0x6b, while the spec says 0x6=
8. 0x68 + 0x3 =3D 0x6b. To
> support more than 8 bit, we must do 16 bit access at 0x6a or 32 bit at 0x=
68.
> =
> To summarize;
> You are completely right you can use the "old" driver on the DS570 as wel=
l, but _only_ for 8bit SPI.
> My patch allows to run on X86 and with 16 or 32bit SPI.
Hi Richard,
When I look at the IP block I see that the transfers can be 16 or 32 bits a=
nd allowing that would probably be more efficient for transfers. That seems=
like the primary benefit to me.
I don't personally see a benefit of running on X86 but that's not my domain=
for sure. I don't know of many users using Xilinx IP with an X86, but may=
be they're out there.
A simpler driver is definitely better IMHO.
Thanks for investigating further,
John
> =
> Thanks to the observation from you, I got aware of the differences. I can=
simplify the code by
> automatically increase registers offsets when doing 8 or 16 bits accesses=
.
> I will come back with an updated patch.
> =
> Hope I made the situation clearer.
> =
> --Richard
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename
From: Michael Ellerman @ 2009-09-24 13:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, linux-kernel, linuxppc-dev, Paul Mackerras,
Linus Torvalds, David S. Miller
In-Reply-To: <20090924121423.GB12262@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]
On Thu, 2009-09-24 at 14:14 +0200, Ingo Molnar wrote:
> * Michael Ellerman <michael@ellerman.id.au> wrote:
>
> > On Wed, 2009-09-23 at 14:44 +0200, Ingo Molnar wrote:
> > > * Michael Ellerman <michael@ellerman.id.au> wrote:
> > >
> > > > On Tue, 2009-09-22 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> > > > > On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > > > > >
> > > > > > Nevertheless you are right that i should have caught this particular
> > > > > > PowerPC build bug - i missed it - sorry about that!
> > > > > >
> > > > > Allright. Well, to help in general, we are setting up a build-bot
> > > > > here too that will build -tip HEAD for at least powerpc daily with
> > > > > a few configs too.
> > > >
> > > > Results here:
> > > >
> > > > http://kisskb.ellerman.id.au/kisskb/branch/12/
> > >
> > > ok, seems green for today - the two failures are: one a powerpc
> > > toolchain problem it appears, plus a mainline warning.
> >
> > Yep that looks more or less normal.
> >
> > > Btw., for me to be able to notice failures there it would have to
> > > email me automatically if there's any -tip build failures that do
> > > not occur with the upstream branch. Does it have such a feature?
> >
> > Not really, it sends mails to me, but it doesn't have a way to filter
> > them by branch. I think the plan is we'll keep an eye on it and either
> > send you patches or at least let you know that it's broken.
>
> how many mails are those per day, typically? If there's not too many and
> if there's a way to send all of them to me i could post-filter them for
> -tip relevance. If that is feasible. You bouncing it to me later is
> certainly also a solution. (but lengthens the latency of fixes,
> obviously.)
Lots of mails - there are an insane number of arm configs for
starters :)
Give me a day or two, I should be able to add a per-branch setting for
who to send mails to without too much trouble.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: 2.6.31-git5 kernel boot hangs on powerpc
From: Sachin Sant @ 2009-09-24 13:23 UTC (permalink / raw)
To: Tejun Heo; +Cc: Linux/PPC Development, David Miller
In-Reply-To: <4ABB6D33.6060706@kernel.org>
Tejun Heo wrote:
> Sachin Sant wrote:
>
>> Tejun Heo wrote:
>>
>>> Can you please apply the attached patch and see whether anything
>>> interesting shows up in the kernel log?
>>>
>>>
>> Thanks Tejun for the debug patch. Attached here are the relevant logs.
>> The only messages related to percpu in the logs are
>>
>> <6>PERCPU: Embedded 2 pages/cpu @c000000001200000 s100232 r0 d30840 u524288
>> <7>pcpu-alloc: s100232 r0 d30840 u524288 alloc=1*1048576
>> <7>pcpu-alloc: [0] 0 1
>> The captured logs are with latest git.
>>
>
> Hmm... that means it wasn't caused by rogue percpu pointer access.
> Pleast wait a bit. I'll try to reproduce it.
>
I was able to reproduce the hang in a different way. (I still had
IPV6 disabled in my config). I executed the network namespace container
tests from LTP and could reproduce a similar hang. The top three
function calls were the same as with IPV6. Here are the traces
using xmon debugger.
Oops: System Reset, sig: 6 [#4]
SMP NR_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries
Modules linked in: quota_v2 quota_tree fuse loop dm_mod sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c00000000003c310 LR: c0000000000055d0 CTR: 0000000000000040
REGS: c0000000fc90f340 TRAP: 0100 Tainted: G D (2.6.31-git13-autotest)
MSR: 8000000000081032 <ME,IR,DR> CR: 28004420 XER: 20000001
TASK = c00000002c408890[8753] 'check_netns_ena' THREAD: c0000000fc90c000 CPU: 2
GPR00: 00000fffffffffff c0000000fc90f5c0 c000000000b8c2a8 d00007fffff00000
GPR04: 0000000000000201 0000000000000300 d00007fffff00000 d00007fffff00000
GPR08: 0000000000000000 000007fffff00000 0000000000000000 0000000000000000
GPR12: 8000000000009032 c000000000c82a00 0000000000000001 c0000000fc90f924
GPR16: 0000000000000300 0000000000000001 c0000000fa8e2380 0000000000000000
GPR20: 0000000000010000 0000000000000001 0000000000000000 0000000000000000
GPR24: c0000000fa9c09c8 0000000000000001 0000000000000001 c0000000faef6f60
GPR28: c000000000c6b620 0000000000000000 c000000000af2aa0 c000000000c6d1b0
NIP [c00000000003c310] .hash_page+0x24/0x4bc
LR [c0000000000055d0] .do_hash_page+0x50/0x6c
Call Trace:
[c0000000fc90f5c0] [c0000000000055d0] .do_hash_page+0x50/0x6c (unreliable)
--- Exception: 301 at .memset+0x60/0xfc
LR = .pcpu_alloc+0x718/0x8fc
[c0000000fc90f8b0] [c0000000001700dc] .pcpu_alloc+0x6a8/0x8fc (unreliable)
[c0000000fc90f9d0] [c000000000614648] .snmp_mib_init+0x54/0x9c
[c0000000fc90fa60] [c000000000614764] .ipv4_mib_init_net+0xd4/0x1e0
[c0000000fc90fb10] [c0000000005a839c] .setup_net+0x68/0x124
[c0000000fc90fbb0] [c0000000005a8ad0] .copy_net_ns+0x88/0x130
[c0000000fc90fc40] [c0000000000bd5ac] .create_new_namespaces+0x110/0x1d0
[c0000000fc90fce0] [c0000000000bd874] .unshare_nsproxy_namespaces+0x6c/0xe8
[c0000000fc90fd80] [c000000000091ee8] .SyS_unshare+0x13c/0x318
[c0000000fc90fe30] [c0000000000085b4] syscall_exit+0x0/0x40
Instruction dump:
7c0803a6 ebe1fff8 4e800020 78690100 7c0802a6 f8010010 3800ffff fa01ff80
7cb02b78 78000500 fa21ff88 fb61ffd8 <7c912378> fa41ff90 7c7b1b78 fa61ff98
As you can see the call trace is same as far as top three function calls
are concerned [snmp_mib_init(), pcpu_alloc() and memset()].
The snmp_mib_init() function is :
int snmp_mib_init(void *ptr[2], size_t mibsize)
{
BUG_ON(ptr == NULL);
ptr[0] = __alloc_percpu(mibsize, __alignof__(unsigned long long));
if (!ptr[0])
goto err0;
ptr[1] = __alloc_percpu(mibsize, __alignof__(unsigned long long));
if (!ptr[1])
goto err1;
return 0;
.....
May be this might help..
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: 2.6.31-git5 kernel boot hangs on powerpc
From: Tejun Heo @ 2009-09-24 12:59 UTC (permalink / raw)
To: Sachin Sant; +Cc: Linux/PPC Development, David Miller
In-Reply-To: <4ABB269F.6020309@in.ibm.com>
Sachin Sant wrote:
> Tejun Heo wrote:
>> Can you please apply the attached patch and see whether anything
>> interesting shows up in the kernel log?
>>
> Thanks Tejun for the debug patch. Attached here are the relevant logs.
> The only messages related to percpu in the logs are
>
> <6>PERCPU: Embedded 2 pages/cpu @c000000001200000 s100232 r0 d30840 u524288
> <7>pcpu-alloc: s100232 r0 d30840 u524288 alloc=1*1048576
> <7>pcpu-alloc: [0] 0 1
> The captured logs are with latest git.
Hmm... that means it wasn't caused by rogue percpu pointer access.
Pleast wait a bit. I'll try to reproduce it.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH, RFC] powerpc, pci: fix MODPOST warning
From: Heiko Schocher @ 2009-09-24 12:45 UTC (permalink / raw)
To: linuxppc-dev
making a powerpc target with PCI support, shows the
following warning:
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x10430): Section mismatch in reference from the function pcibios_allocate_bus_resources() to the function .init.text:reparent_resources()
The function pcibios_allocate_bus_resources() references
the function __init reparent_resources().
This is often because pcibios_allocate_bus_resources lacks a __init
annotation or the annotation of reparent_resources is wrong.
This patch fix this warning by removing the __init
annotation before reparent_resources.
Signed-off-by: Heiko Schocher <hs@denx.de>
---
arch/powerpc/kernel/pci-common.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index e9f4840..48acf63 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1190,7 +1190,7 @@ EXPORT_SYMBOL(pcibios_align_resource);
* Reparent resource children of pr that conflict with res
* under res, and make res replace those children.
*/
-static int __init reparent_resources(struct resource *parent,
+static int reparent_resources(struct resource *parent,
struct resource *res)
{
struct resource *p, **pp;
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* Re: [v6 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce cpuidle to POWER.
From: Arjan van de Ven @ 2009-09-24 12:22 UTC (permalink / raw)
To: arun
Cc: Peter Zijlstra, Gautham R Shenoy, Venkatesh Pallipadi,
linux-kernel, linux-acpi, Paul Mackerras, Shaohua Li, Ingo Molnar,
linuxppc-dev, Len Brown
In-Reply-To: <20090924051238.GA5963@linux.vnet.ibm.com>
On Thu, 24 Sep 2009 10:42:41 +0530
Arun R Bharadwaj <arun@linux.vnet.ibm.com> wrote:
> * Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-09-22 16:55:27]:
>
> Hi Len, (or other acpi folks),
>
> I had a question regarding ACPI-cpuidle interaction in the current
> implementation.
>
> Currently, every cpu (i.e. acpi_processor) registers to cpuidle as
> a cpuidle_device. So every cpu has to go through the process of
> setting up the idle states and then registering as a cpuidle device.
>
> What exactly is the reason behind this?
>
technically a BIOS can opt to give you C states via ACPI on some cpus,
but not on others.
in practice when this happens it tends to be a bug.. but it's
technically a valid configuration
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename
From: Ingo Molnar @ 2009-09-24 12:14 UTC (permalink / raw)
To: Michael Ellerman
Cc: Peter Zijlstra, linux-kernel, linuxppc-dev, Paul Mackerras,
Linus Torvalds, David S. Miller
In-Reply-To: <1253747995.6110.5.camel@concordia>
* Michael Ellerman <michael@ellerman.id.au> wrote:
> On Wed, 2009-09-23 at 14:44 +0200, Ingo Molnar wrote:
> > * Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > > On Tue, 2009-09-22 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> > > > On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > > > >
> > > > > Nevertheless you are right that i should have caught this particular
> > > > > PowerPC build bug - i missed it - sorry about that!
> > > > >
> > > > Allright. Well, to help in general, we are setting up a build-bot
> > > > here too that will build -tip HEAD for at least powerpc daily with
> > > > a few configs too.
> > >
> > > Results here:
> > >
> > > http://kisskb.ellerman.id.au/kisskb/branch/12/
> >
> > ok, seems green for today - the two failures are: one a powerpc
> > toolchain problem it appears, plus a mainline warning.
>
> Yep that looks more or less normal.
>
> > Btw., for me to be able to notice failures there it would have to
> > email me automatically if there's any -tip build failures that do
> > not occur with the upstream branch. Does it have such a feature?
>
> Not really, it sends mails to me, but it doesn't have a way to filter
> them by branch. I think the plan is we'll keep an eye on it and either
> send you patches or at least let you know that it's broken.
how many mails are those per day, typically? If there's not too many and
if there's a way to send all of them to me i could post-filter them for
-tip relevance. If that is feasible. You bouncing it to me later is
certainly also a solution. (but lengthens the latency of fixes,
obviously.)
Ingo
^ permalink raw reply
* Re: [PATCH v2 0/2] cpu: pseries: Offline state framework.
From: Arjan van de Ven @ 2009-09-24 11:41 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <1253791987.7695.153.camel@twins>
On Thu, 24 Sep 2009 13:33:07 +0200
Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Thu, 2009-09-24 at 18:38 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-09-24 at 09:51 +0200, Peter Zijlstra wrote:
> > > > I don't quite follow your logic here. This is useful for more
> > > > than just hypervisors. For example, take the HV out of the
> > > > picture for a moment and imagine that the HW has the ability to
> > > > offline CPU in various power levels, with varying latencies to
> > > > bring them back.
> > >
> > > cpu-hotplug is an utter slow path, anybody saying latency and
> > > hotplug in the same sentence doesn't seem to grasp either or both
> > > concepts.
> >
> > Let's forget about latency then. Let's imagine I want to set a CPU
> > offline to save power, vs. setting it offline -and- opening the back
> > door of the machine to actually physically replace it :-)
>
> If the hardware is capable of physical hotplug, then surely powering
> the socket down saves most power and is the preferred mode?
btw just to take away a perception that generally powering down sockets
help; it does not help for all cpus. Some cpus are so efficient in idle
that the incremental gain one would get by "offlining" a core is just
not worth it
(in fact, in x86, it's the same thing)
I obviously can't speak for p-series cpus, just wanted to point out
that there is no universal truth about "offlining saves power".
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: [PATCH v2 0/2] cpu: pseries: Offline state framework.
From: Peter Zijlstra @ 2009-09-24 11:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <1253781508.7103.437.camel@pasglop>
On Thu, 2009-09-24 at 18:38 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-24 at 09:51 +0200, Peter Zijlstra wrote:
> > > I don't quite follow your logic here. This is useful for more than just
> > > hypervisors. For example, take the HV out of the picture for a moment
> > > and imagine that the HW has the ability to offline CPU in various power
> > > levels, with varying latencies to bring them back.
> >
> > cpu-hotplug is an utter slow path, anybody saying latency and hotplug in
> > the same sentence doesn't seem to grasp either or both concepts.
>
> Let's forget about latency then. Let's imagine I want to set a CPU
> offline to save power, vs. setting it offline -and- opening the back
> door of the machine to actually physically replace it :-)
If the hardware is capable of physical hotplug, then surely powering the
socket down saves most power and is the preferred mode?
> In any case, I don't see the added feature as being problematic, and
> not such a "layering violation" as you seem to imply it is. It's a
> convenient way to atomically take the CPU out -and- convey some
> information about the "intent" to the hypervisor, and I really fail
> to see why you have so strong objections about it.
Ignorance on my part probably :-)
I'm simply not seeing a use case for it, except for the virt case, which
I think we should bug the virt interface with and not the cpu-hotplug
interface.
^ permalink raw reply
* [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Yuri Frolov @ 2009-09-24 11:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rep.dot.nop, linux-kbuild
Hello,
here is a corresponding bug: http://bugzilla.kernel.org/show_bug.cgi?id=11143
This patch should correctly export crtsavres.o in order to make O= option working.
Please, consider to apply.
Fix linking modules against crtsavres.o
Previously we got
CC drivers/char/hw_random/rng-core.mod.o
LD [M] drivers/char/hw_random/rng-core.ko
/there/src/buildroot.git.ppc/build_powerpc_nofpu/staging_dir/usr/bin/powerpc-linux-uclibc-ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
* Makefile (LDFLAGS_MODULE_PREREQ): New variable to hold prerequisite
files for modules.
* arch/powerpc/Makefile: add crtsavres.o to LDFLAGS_MODULE_PREREQ.
* scripts/Makefile.modpost (cmd_as_o_S): Copy from Makefile.build.
(cmd_ld_ko_o): Also link LDFLAGS_MODULE_PREREQ.
Provide rule to build objects from assembler.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off by: Yuri Frolov <yfrolov@ru.mvista.com>
Makefile | 2 ++
arch/powerpc/Makefile | 2 +-
scripts/Makefile.modpost | 12 ++++++++++--
3 files changed, 13 insertions(+), 3 deletions(-)
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/arch/powerpc/Makefile linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile
--- linux-2.6/arch/powerpc/Makefile 2009-09-17 20:04:31.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/arch/powerpc/Makefile 2009-09-23 22:08:03.000000000 +0400
@@ -93,7 +93,7 @@ else
KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
endif
else
-LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
+LDFLAGS_MODULE_PREREQ += arch/powerpc/lib/crtsavres.o
endif
ifeq ($(CONFIG_TUNE_CELL),y)
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/Makefile linux-2.6-powerpc-crtsavres/Makefile
--- linux-2.6/Makefile 2009-09-17 20:04:30.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/Makefile 2009-09-23 21:41:16.000000000 +0400
@@ -326,6 +326,7 @@ MODFLAGS = -DMODULE
CFLAGS_MODULE = $(MODFLAGS)
AFLAGS_MODULE = $(MODFLAGS)
LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds
+LDFLAGS_MODULE_PREREQ =
CFLAGS_KERNEL =
AFLAGS_KERNEL =
CFLAGS_GCOV = -fprofile-arcs -ftest-coverage
@@ -355,6 +356,7 @@ export VERSION PATCHLEVEL SUBLEVEL KERNE
export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
+export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE LDFLAGS_MODULE_PREREQ CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/scripts/Makefile.modpost linux-2.6-powerpc-crtsavres/scripts/Makefile.modpost
--- linux-2.6/scripts/Makefile.modpost 2009-09-17 20:04:42.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/scripts/Makefile.modpost 2009-09-23 22:15:00.000000000 +0400
@@ -122,14 +122,22 @@ quiet_cmd_cc_o_c = CC $@
cmd_cc_o_c = $(CC) $(c_flags) $(CFLAGS_MODULE) \
-c -o $@ $<
-$(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
+quiet_cmd_as_o_S = AS $(quiet_modtag) $@
+cmd_as_o_S = $(CC) $(a_flags) $(AFLAGS_MODULE) -c -o $@ $<
+
+$(LDFLAGS_MODULE_PREREQ): %.o: %.S FORCE
+ $(Q)mkdir -p $(dir $@)
+ $(call if_changed_dep,as_o_S)
+
+$(modules:.ko=.mod.o): %.mod.o: %.mod.c $(LDFLAGS_MODULE_PREREQ) FORCE
$(call if_changed_dep,cc_o_c)
targets += $(modules:.ko=.mod.o)
# Step 6), final link of the modules
quiet_cmd_ld_ko_o = LD [M] $@
- cmd_ld_ko_o = $(LD) -r $(LDFLAGS) $(LDFLAGS_MODULE) -o $@ \
+ cmd_ld_ko_o = $(LD) -r $(LDFLAGS) $(LDFLAGS_MODULE_PREREQ) \
+ $(LDFLAGS_MODULE) -o $@ \
$(filter-out FORCE,$^)
$(modules): %.ko :%.o %.mod.o FORCE
^ permalink raw reply
* [PATCH 4/4] powerpc/fsl: 85xx: add cache-sram support
From: Vivek Mahajan @ 2009-09-24 9:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1253783426-11978-3-git-send-email-vivek.mahajan@freescale.com>
This adds QorIQ based Cache-SRAM support as under:-
* A small abstraction over powerpc's remote heap allocator
* Exports mpc85xx_cache_sram_alloc()/free() APIs
* Supports only one contiguous SRAM window
* Defines FSL_85XX_CACHE_SRAM and its base address
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
Resending it to linuxppc-dev@ozlabs.org
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 48 ++++++
arch/powerpc/platforms/85xx/Kconfig | 9 ++
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 95 ++++++++++++
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 141 ++++++++++++++++++
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 184 ++++++++++++++++++++++++
6 files changed, 478 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_85xx_cache_sram.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_sram.c
create mode 100644 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
new file mode 100644
index 0000000..2af2bdc
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Cache SRAM handling for QorIQ platform
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+
+ * This file is derived from the original work done
+ * by Sylvain Munaut for the Bestcomm SRAM allocator.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+#define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+
+#include <asm/rheap.h>
+#include <linux/spinlock.h>
+
+/*
+ * Cache-SRAM
+ */
+
+struct mpc85xx_cache_sram {
+ phys_addr_t base_phys;
+ void *base_virt;
+ unsigned int size;
+ rh_info_t *rh;
+ spinlock_t lock;
+};
+
+extern void mpc85xx_cache_sram_free(void *ptr);
+extern void *mpc85xx_cache_sram_alloc(unsigned int size,
+ phys_addr_t *phys, unsigned int align);
+
+#endif /* __AMS_POWERPC_FSL_85XX_CACHE_SRAM_H__ */
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index d3a975e..b6f23c3 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -144,6 +144,15 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default "0xfff00000"
+
endif # MPC85xx
config TQM85xx
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 9d4b174..745994c 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
+obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
new file mode 100644
index 0000000..8c4a4ac
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc
+ *
+ * QorIQ based Cache Controller Memory Mapped Registers
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __FSL_85XX_CACHE_CTLR_H__
+#define __FSL_85XX_CACHE_CTLR_H__
+
+#define L2CR_L2FI 0x40000000 /* L2 flash invalidate */
+#define L2CR_L2IO 0x00200000 /* L2 instruction only */
+#define L2CR_SRAM_ZERO 0x00000000 /* L2SRAM zero size */
+#define L2CR_SRAM_FULL 0x00010000 /* L2SRAM full size */
+#define L2CR_SRAM_HALF 0x00020000 /* L2SRAM half size */
+#define L2CR_SRAM_TWO_HALFS 0x00030000 /* L2SRAM two half sizes */
+#define L2CR_SRAM_QUART 0x00040000 /* L2SRAM one quarter size */
+#define L2CR_SRAM_TWO_QUARTS 0x00050000 /* L2SRAM two quarter size */
+#define L2CR_SRAM_EIGHTH 0x00060000 /* L2SRAM one eighth size */
+#define L2CR_SRAM_TWO_EIGHTH 0x00070000 /* L2SRAM two eighth size */
+
+#define L2SRAM_OPTIMAL_SZ_SHIFT 0x00000003 /* Optimum size for L2SRAM */
+
+#define L2SRAM_BAR_MSK_LO18 0xFFFFC000 /* Lower 18 bits */
+#define L2SRAM_BARE_MSK_HI4 0x0000000F /* Upper 4 bits */
+
+enum cache_sram_lock_ways {
+ LOCK_WAYS_ZERO,
+ LOCK_WAYS_EIGHTH,
+ LOCK_WAYS_TWO_EIGHTH,
+ LOCK_WAYS_HALF = 4,
+ LOCK_WAYS_FULL = 8,
+};
+
+struct mpc85xx_l2ctlr {
+ u32 ctl; /* 0x000 - L2 control */
+ u8 res1[0xC];
+ u32 ewar0; /* 0x010 - External write address 0 */
+ u32 ewarea0; /* 0x014 - External write address extended 0 */
+ u32 ewcr0; /* 0x018 - External write ctrl */
+ u8 res2[4];
+ u32 ewar1; /* 0x020 - External write address 1 */
+ u32 ewarea1; /* 0x024 - External write address extended 1 */
+ u32 ewcr1; /* 0x028 - External write ctrl 1 */
+ u8 res3[4];
+ u32 ewar2; /* 0x030 - External write address 2 */
+ u32 ewarea2; /* 0x034 - External write address extended 2 */
+ u32 ewcr2; /* 0x038 - External write ctrl 2 */
+ u8 res4[4];
+ u32 ewar3; /* 0x040 - External write address 3 */
+ u32 ewarea3; /* 0x044 - External write address extended 3 */
+ u32 ewcr3; /* 0x048 - External write ctrl 3 */
+ u8 res5[0xB4];
+ u32 srbar0; /* 0x100 - SRAM base address 0 */
+ u32 srbarea0; /* 0x104 - SRAM base addr reg ext address 0 */
+ u32 srbar1; /* 0x108 - SRAM base address 1 */
+ u32 srbarea1; /* 0x10C - SRAM base addr reg ext address 1 */
+ u8 res6[0xCF0];
+ u32 errinjhi; /* 0xE00 - Error injection mask high */
+ u32 errinjlo; /* 0xE04 - Error injection mask low */
+ u32 errinjctl; /* 0xE08 - Error injection tag/ecc control */
+ u8 res7[0x14];
+ u32 captdatahi; /* 0xE20 - Error data high capture */
+ u32 captdatalo; /* 0xE24 - Error data low capture */
+ u32 captecc; /* 0xE28 - Error syndrome */
+ u8 res8[0x14];
+ u32 errdet; /* 0xE40 - Error detect */
+ u32 errdis; /* 0xE44 - Error disable */
+ u32 errinten; /* 0xE48 - Error interrupt enable */
+ u32 errattr; /* 0xE4c - Error attribute capture */
+ u32 erradrrl; /* 0xE50 - Error address capture low */
+ u32 erradrrh; /* 0xE54 - Error address capture high */
+ u32 errctl; /* 0xE58 - Error control */
+ u8 res9[0x1A4];
+};
+
+extern int instantiate_cache_sram(struct of_device *dev, unsigned int size);
+extern void remove_cache_sram(struct of_device *dev);
+
+#endif /* __FSL_85XX_CACHE_CTLR_H__ */
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
new file mode 100644
index 0000000..6744083
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Simple memory allocator abstraction for QorIQ (P1/P2) based Cache-SRAM
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+ *
+ * This file is derived from the original work done
+ * by Sylvain Munaut for the Bestcomm SRAM allocator.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <asm/pgtable.h>
+#include <asm/fsl_85xx_cache_sram.h>
+
+struct mpc85xx_cache_sram *cache_sram;
+
+void *mpc85xx_cache_sram_alloc(unsigned int size,
+ phys_addr_t *phys, unsigned int align)
+{
+ unsigned long offset;
+ unsigned long flags;
+
+ if (!size || (size > cache_sram->size) || (align > cache_sram->size)) {
+ pr_err("%s(): size(=%x) or align(=%x) zero or too big\n",
+ __func__, size, align);
+ return NULL;
+ }
+
+ if ((align & (align - 1)) || align <= 1) {
+ pr_err("%s(): align(=%x) must be power of two and >1\n",
+ __func__, align);
+ return NULL;
+ }
+
+ spin_lock_irqsave(&cache_sram->lock, flags);
+ offset = rh_alloc_align(cache_sram->rh, size, align, NULL);
+ spin_unlock_irqrestore(&cache_sram->lock, flags);
+
+ if (IS_ERR_VALUE(offset))
+ return NULL;
+
+ *phys = cache_sram->base_phys + offset;
+
+ return (unsigned char *)cache_sram->base_virt + offset;
+}
+EXPORT_SYMBOL(mpc85xx_cache_sram_alloc);
+
+void mpc85xx_cache_sram_free(void *ptr)
+{
+ unsigned long flags;
+ BUG_ON(!ptr);
+
+ spin_lock_irqsave(&cache_sram->lock, flags);
+ rh_free(cache_sram->rh, ptr - cache_sram->base_virt);
+ spin_unlock_irqrestore(&cache_sram->lock, flags);
+}
+EXPORT_SYMBOL(mpc85xx_cache_sram_free);
+
+int __init instantiate_cache_sram(struct of_device *dev, unsigned int size)
+{
+ if (cache_sram) {
+ dev_err(&dev->dev, "Already initialized cache-sram\n");
+ return -EBUSY;
+ }
+
+ cache_sram = kzalloc(sizeof(struct mpc85xx_cache_sram), GFP_KERNEL);
+ if (!cache_sram) {
+ dev_err(&dev->dev, "Out of memory for cache_sram structure\n");
+ return -ENOMEM;
+ }
+
+ cache_sram->base_phys = CONFIG_FSL_85XX_CACHE_SRAM_BASE;
+ cache_sram->size = size;
+
+ if (!request_mem_region(cache_sram->base_phys, cache_sram->size,
+ "fsl_85xx_cache_sram")) {
+ dev_err(&dev->dev, "%s: request memory failed\n",
+ dev->node->full_name);
+ kfree(cache_sram);
+ return -ENXIO;
+ }
+
+ cache_sram->base_virt = ioremap_flags(cache_sram->base_phys,
+ cache_sram->size, _PAGE_COHERENT | PAGE_KERNEL);
+ if (!cache_sram->base_virt) {
+ dev_err(&dev->dev, "%s: ioremap_flags failed\n",
+ dev->node->full_name);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+ kfree(cache_sram);
+ return -ENOMEM;
+ }
+
+ cache_sram->rh = rh_create(sizeof(unsigned int));
+ if (IS_ERR(cache_sram->rh)) {
+ dev_err(&dev->dev, "%s: Unable to create remote heap\n",
+ dev->node->full_name);
+ iounmap(cache_sram->base_virt);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+ kfree(cache_sram);
+ return PTR_ERR(cache_sram->rh);
+ }
+
+ rh_attach_region(cache_sram->rh, 0, cache_sram->size);
+ spin_lock_init(&cache_sram->lock);
+
+ dev_info(&dev->dev, "[base:0x%x, size:0x%x] configured and loaded\n",
+ cache_sram->base_phys, cache_sram->size);
+ return 0;
+}
+
+void remove_cache_sram(struct of_device *dev)
+{
+ BUG_ON(!cache_sram);
+
+ rh_detach_region(cache_sram->rh, 0, cache_sram->size);
+ rh_destroy(cache_sram->rh);
+
+ iounmap(cache_sram->base_virt);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+
+ kfree(cache_sram);
+ cache_sram = NULL;
+
+ dev_info(&dev->dev, "MPC85xx Cache-SRAM driver unloaded\n");
+}
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
new file mode 100644
index 0000000..1d36971
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -0,0 +1,184 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * QorIQ (P1/P2) L2 controller init for Cache-SRAM instantiation
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <asm/io.h>
+
+#include "fsl_85xx_cache_ctlr.h"
+
+static char *param;
+struct mpc85xx_l2ctlr __iomem *l2ctlr;
+
+static long get_cache_sram_size(void)
+{
+ unsigned long val;
+
+ if (!param || (strict_strtoul(param, 0, &val) < 0))
+ return -EINVAL;
+
+ return val;
+}
+
+static int __init get_cmdline_param(char *str)
+{
+ if (!str)
+ return 0;
+
+ param = str;
+ return 1;
+}
+
+__setup("cache-sram-size=", get_cmdline_param);
+
+static int __devinit mpc85xx_l2ctlr_of_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ long rval;
+ unsigned int rem;
+ unsigned char ways;
+ const unsigned int *prop;
+ unsigned int l2cache_size;
+ unsigned int sram_size;
+
+ if (!dev->node) {
+ dev_err(&dev->dev, "Device's OF-node is NULL\n");
+ return -EINVAL;
+ }
+
+ prop = of_get_property(dev->node, "cache-size", NULL);
+ if (!prop) {
+ dev_err(&dev->dev, "Missing L2 cache-size\n");
+ return -EINVAL;
+ }
+ l2cache_size = *prop;
+
+ rval = get_cache_sram_size();
+ if (rval <= 0) {
+ dev_err(&dev->dev,
+ "Entire L2 as cache, Aborting Cache-SRAM stuff\n");
+ return -EINVAL;
+ }
+
+ rem = l2cache_size % (unsigned int)rval;
+ ways = l2cache_size / (unsigned int)rval;
+ if (rem || (ways & (ways - 1))) {
+ dev_err(&dev->dev, "Illegal cache-sram-size in command line\n");
+ return -EINVAL;
+ }
+
+ sram_size = (unsigned int)rval;
+
+ l2ctlr = of_iomap(dev->node, 0);
+ if (!l2ctlr) {
+ dev_err(&dev->dev, "Can't map L2 controller\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Write bits[0-17] to srbar0
+ */
+ out_be32(&l2ctlr->srbar0,
+ CONFIG_FSL_85XX_CACHE_SRAM_BASE & L2SRAM_BAR_MSK_LO18);
+
+ /*
+ * Write bits[18-21] to srbare0
+ */
+ out_be32(&l2ctlr->srbarea0,
+ (CONFIG_FSL_85XX_CACHE_SRAM_BASE >> 10) & L2SRAM_BARE_MSK_HI4);
+
+ clrsetbits_be32(&l2ctlr->ctl, L2CR_L2E, L2CR_L2FI);
+
+ switch (ways) {
+ case LOCK_WAYS_EIGHTH:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_EIGHTH);
+ break;
+
+ case LOCK_WAYS_TWO_EIGHTH:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_TWO_EIGHTH);
+ break;
+
+ case LOCK_WAYS_HALF:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_HALF);
+ break;
+
+ case LOCK_WAYS_FULL:
+ default:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_FULL);
+ break;
+ }
+ mbar(1);
+
+ rval = instantiate_cache_sram(dev, sram_size);
+ if (rval < 0) {
+ dev_err(&dev->dev, "Can't instantiate Cache-SRAM\n");
+ iounmap(l2ctlr);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int __devexit mpc85xx_l2ctlr_of_remove(struct of_device *dev)
+{
+ BUG_ON(!l2ctlr);
+
+ iounmap(l2ctlr);
+ remove_cache_sram(dev);
+ dev_info(&dev->dev, "MPC85xx L2 controller unloaded\n");
+
+ return 0;
+}
+
+static struct of_device_id mpc85xx_l2ctlr_of_match[] = {
+ {
+ .compatible = "fsl,p2020-l2-cache-controller",
+ },
+ {},
+};
+
+static struct of_platform_driver mpc85xx_l2ctlr_of_platform_driver = {
+ .name = "fsl-l2ctlr",
+ .match_table = mpc85xx_l2ctlr_of_match,
+ .probe = mpc85xx_l2ctlr_of_probe,
+ .remove = __devexit_p(mpc85xx_l2ctlr_of_remove),
+};
+
+static __init int mpc85xx_l2ctlr_of_init(void)
+{
+ return of_register_platform_driver(&mpc85xx_l2ctlr_of_platform_driver);
+}
+
+static void __exit mpc85xx_l2ctlr_of_exit(void)
+{
+ of_unregister_platform_driver(&mpc85xx_l2ctlr_of_platform_driver);
+}
+
+subsys_initcall(mpc85xx_l2ctlr_of_init);
+module_exit(mpc85xx_l2ctlr_of_exit);
+
+MODULE_DESCRIPTION("Freescale MPC85xx L2 controller init");
+MODULE_LICENSE("GPL v2");
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/4] powerpc/fsl: 85xx: add mbar()
From: Vivek Mahajan @ 2009-09-24 9:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1253783426-11978-2-git-send-email-vivek.mahajan@freescale.com>
Adds e500/85xx based memory barrier
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
Resending it to linuxppc-dev@ozlabs.org
arch/powerpc/include/asm/synch.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/synch.h b/arch/powerpc/include/asm/synch.h
index 28f6ddb..8298089 100644
--- a/arch/powerpc/include/asm/synch.h
+++ b/arch/powerpc/include/asm/synch.h
@@ -23,6 +23,11 @@ static inline void isync(void)
{
__asm__ __volatile__ ("isync" : : : "memory");
}
+
+static inline void mbar(int mo)
+{
+ __asm__ __volatile__ ("mbar %0" : : "i" (mo) : "memory");
+}
#endif /* __ASSEMBLY__ */
#if defined(__powerpc64__)
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/4] powerpc/fsl: 85xx: document cache-sram
From: Vivek Mahajan @ 2009-09-24 9:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1253783426-11978-1-git-send-email-vivek.mahajan@freescale.com>
Adds documentation for Freescale's QorIQ based cache-sram as under:-
* How to enable it from a low level driver
* How to set its size
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
Resending it to linuxppc-dev@ozlabs.org
Documentation/powerpc/fsl_85xx_cache_sram.txt | 31 +++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/fsl_85xx_cache_sram.txt
diff --git a/Documentation/powerpc/fsl_85xx_cache_sram.txt b/Documentation/powerpc/fsl_85xx_cache_sram.txt
new file mode 100644
index 0000000..628607d
--- /dev/null
+++ b/Documentation/powerpc/fsl_85xx_cache_sram.txt
@@ -0,0 +1,31 @@
+* Freescale QorIQ based Cache SRAM
+
+Freescale's QorIQ platforms provide an option of configuring
+a part of (or full) cache memory as SRAM. Any low level
+driver can use its APIs via selecting FSL_85XX_CACHE_SRAM as
+under for the case of gianfar ethernet driver:-
+
+In drivers/net/Kconfig:-
+
+config GIANFAR
+ ....
+ select FSL_85XX_CACHE_SRAM if MPC85xx
+ ....
+
+FSL_85XX_CACHE_SRAM and its base address are defined in
+arch/powerpc/platforms/85xx/Kconfig as under:-
+
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default "0xfff00000"
+
+The size of the above cache SRAM memory window is passed via the
+kernel command line as <cache-sram-size=....>
+
+Absence of the above parameter in the kernel command line is
+treated as no cache SRAM.
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/4] powerpc/fsl: 85xx: document cache-sram size as a kernel parametric option
From: Vivek Mahajan @ 2009-09-24 9:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
Adds documentation for the size parameter of Freescale's QorIQ
based cache-sram
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
Resending it to linuxppc-dev@ozlabs.org
Documentation/kernel-parameters.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 0f17d16..3213844 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -412,6 +412,9 @@ and is between 256 and 4096 characters. It is defined in the file
c101= [NET] Moxa C101 synchronous serial card
+ cache-sram-size= [PPC] Size of Freescale's QorIQ Cache SRAM
+ See Documentation/powerpc/fsl_85xx_cache_sram.txt.
+
cachesize= [BUGS=X86-32] Override level 2 CPU cache size detection.
Sometimes CPU hardware bugs make them report the cache
size incorrectly. The kernel will attempt work arounds
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v2 0/2] cpu: pseries: Offline state framework.
From: Benjamin Herrenschmidt @ 2009-09-24 8:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <1253778667.7695.130.camel@twins>
On Thu, 2009-09-24 at 09:51 +0200, Peter Zijlstra wrote:
> > I don't quite follow your logic here. This is useful for more than just
> > hypervisors. For example, take the HV out of the picture for a moment
> > and imagine that the HW has the ability to offline CPU in various power
> > levels, with varying latencies to bring them back.
>
> cpu-hotplug is an utter slow path, anybody saying latency and hotplug in
> the same sentence doesn't seem to grasp either or both concepts.
Let's forget about latency then. Let's imagine I want to set a CPU
offline to save power, vs. setting it offline -and- opening the back
door of the machine to actually physically replace it :-)
In any case, I don't see the added feature as being problematic, and
not such a "layering violation" as you seem to imply it is. It's a
convenient way to atomically take the CPU out -and- convey some
information about the "intent" to the hypervisor, and I really fail
to see why you have so strong objections about it.
Ben.
^ permalink raw reply
* RE: [PATCH 3/6] P2020DS: Fixup sdhc to use PIO mode
From: Gao Guanhua-B22826 @ 2009-09-24 8:28 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, sdhci-devel
In-Reply-To: <20090923115518.GB6425@oksana.dev.rtsoft.ru>
Thanks, I will add them.=20
> -----Original Message-----
> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]=20
> Sent: Wednesday, September 23, 2009 7:55 PM
> To: Gao Guanhua-B22826
> Cc: sdhci-devel@lists.ossman.eu; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 3/6] P2020DS: Fixup sdhc to use PIO mode
>=20
> On Wed, Sep 23, 2009 at 05:08:09PM +0800, Gao Guanhua wrote:
> > The SDHC can not work on DMA mode because of the hardware=20
> bug, so we=20
> > set a broken dma flag and use PIO mode. This patch applies=20
> to Rev1.0.
>=20
> Signed-off-by line is missing (in all patches).
>=20
> > ---
> > arch/powerpc/boot/dts/p2020ds.dts | 1 +
> > drivers/mmc/host/sdhci-of.c | 3 +++
> > 2 files changed, 4 insertions(+), 0 deletions(-)
> >=20
> > diff --git a/arch/powerpc/boot/dts/p2020ds.dts=20
> > b/arch/powerpc/boot/dts/p2020ds.dts
> > index be449ba..574ad4f 100644
> > --- a/arch/powerpc/boot/dts/p2020ds.dts
> > +++ b/arch/powerpc/boot/dts/p2020ds.dts
> > @@ -459,6 +459,7 @@
> > reg =3D <0x2e000 0x1000>;
> > interrupts =3D <72 0x2>;
> > interrupt-parent =3D <&mpic>;
> > + fsl,sdhci-dma-broken;
>=20
> You might want to update
> Documentation/powerpc/dts-bindings/fsl/esdhc.txt
>=20
> > clock-frequency =3D <0>;
> > };
> > =20
> > diff --git a/drivers/mmc/host/sdhci-of.c=20
> b/drivers/mmc/host/sdhci-of.c=20
> > index 01ab916..5879483 100644
> > --- a/drivers/mmc/host/sdhci-of.c
> > +++ b/drivers/mmc/host/sdhci-of.c
> > @@ -270,6 +270,9 @@ static int __devinit=20
> sdhci_of_probe(struct of_device *ofdev,
> > if (sdhci_of_wp_inverted(np))
> > host->quirks |=3D SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
> > =20
> > + if (of_get_property(np, "fsl,sdhci-dma-broken", NULL))
> > + host->quirks |=3D SDHCI_QUIRK_BROKEN_DMA;
> > +
> > clk =3D of_get_property(np, "clock-frequency", &size);
> > if (clk && size =3D=3D sizeof(*clk) && *clk)
> > of_host->clock =3D *clk;
> > --
> > 1.6.4
>=20
> Thanks,
>=20
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>=20
>=20
^ permalink raw reply
* RE: [PATCH 6/6] P2020DS: Remove sdhci-dma-broken and sdhci-ahb2mag-irq-bypass properties
From: Gao Guanhua-B22826 @ 2009-09-24 8:22 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, sdhci-devel
In-Reply-To: <20090923115954.GC6425@oksana.dev.rtsoft.ru>
=20
> -----Original Message-----
> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]=20
> Sent: Wednesday, September 23, 2009 8:00 PM
> To: Gao Guanhua-B22826
> Cc: sdhci-devel@lists.ossman.eu; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 6/6] P2020DS: Remove sdhci-dma-broken and=20
> sdhci-ahb2mag-irq-bypass properties
>=20
> On Wed, Sep 23, 2009 at 05:08:12PM +0800, Gao Guanhua wrote:
> > The SDHC on P2020DS board use DMA mode by default.
> > This patch remove the properties used in PIO mode.
>=20
> You just added the properties in 3/6 and 4/6, and now you=20
> instantly remove them?
Add them to support the PIO mode, the board has a hardware bug, sdhc can
only work in PIO mode.
Then the bug has been fixed. So remove those properties.
Yes, maybe I shouldnot add the property in the dts, and only support PIO
in driver.
Thanks.
>=20
> > ---
> > arch/powerpc/boot/dts/p2020ds.dts | 2 --
> > 1 files changed, 0 insertions(+), 2 deletions(-)
> >=20
> > diff --git a/arch/powerpc/boot/dts/p2020ds.dts=20
> > b/arch/powerpc/boot/dts/p2020ds.dts
> > index 29989fb..3263397 100644
> > --- a/arch/powerpc/boot/dts/p2020ds.dts
> > +++ b/arch/powerpc/boot/dts/p2020ds.dts
> > @@ -459,8 +459,6 @@
> > reg =3D <0x2e000 0x1000>;
> > interrupts =3D <72 0x2>;
> > interrupt-parent =3D <&mpic>;
> > - fsl,sdhci-dma-broken;
> > - fsl,sdhci-ahb2mag-irq-bypass;
> > fsl,sdhci-adjust-timeout;
> > clock-frequency =3D <0>;
> > };
> > --
> > 1.6.4
>=20
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>=20
>=20
^ permalink raw reply
* Re: 2.6.31-git5 kernel boot hangs on powerpc
From: Sachin Sant @ 2009-09-24 7:58 UTC (permalink / raw)
To: Tejun Heo; +Cc: Linux/PPC Development, David Miller
In-Reply-To: <4ABA2DE2.6000601@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
Tejun Heo wrote:
> Can you please apply the attached patch and see whether anything
> interesting shows up in the kernel log?
>
Thanks Tejun for the debug patch. Attached here are the relevant logs.
The only messages related to percpu in the logs are
<6>PERCPU: Embedded 2 pages/cpu @c000000001200000 s100232 r0 d30840 u524288
<7>pcpu-alloc: s100232 r0 d30840 u524288 alloc=1*1048576
<7>pcpu-alloc: [0] 0 1
The captured logs are with latest git.
Thanks
-Sachin
[-- Attachment #2: dmesg-log --]
[-- Type: text/plain, Size: 9259 bytes --]
<4>Crash kernel location must be 0x2000000
<6>Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB)
<6>Phyp-dump disabled at boot time
<6>Using pSeries machine description
<7>Page orders: linear mapping = 16, virtual = 16, io = 12
<6>Using 1TB segments
<4>Found initrd at 0xc000000003500000:0xc000000003ccdf60
<6>bootconsole [udbg0] enabled
<6>Partition configured for 2 cpus.
<6>CPU maps initialized for 2 threads per core
<7> (thread shift is 1)
<4>Starting Linux PPC64 #2 SMP Thu Sep 24 12:59:21 IST 2009
<4>-----------------------------------------------------
<4>ppc64_pft_size = 0x1a
<4>physicalMemorySize = 0x100000000
<4>htab_hash_mask = 0x7ffff
<4>-----------------------------------------------------
<6>Initializing cgroup subsys cpuset
<6>Initializing cgroup subsys cpu
<5>Linux version 2.6.31-git13-autotest (root@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #2 SMP Thu Sep 24 12:59:21 IST 2009
<4>[boot]0012 Setup Arch
<7>Node 0 Memory:
<7>Node 2 Memory: 0x0-0xe0000000
<7>Node 3 Memory: 0xe0000000-0x100000000
<4>EEH: No capable adapters found
<6>PPC64 nvram contains 15360 bytes
<7>Using shared processor idle loop
<4>Zone PFN ranges:
<4> DMA 0x00000000 -> 0x00010000
<4> Normal 0x00010000 -> 0x00010000
<4>Movable zone start PFN for each node
<4>early_node_map[2] active PFN ranges
<4> 2: 0x00000000 -> 0x0000e000
<4> 3: 0x0000e000 -> 0x00010000
<4>Could not find start_pfn for node 0
<7>On node 0 totalpages: 0
<7>On node 2 totalpages: 57344
<7> DMA zone: 56 pages used for memmap
<7> DMA zone: 0 pages reserved
<7> DMA zone: 57288 pages, LIFO batch:1
<7>On node 3 totalpages: 8192
<7> DMA zone: 8 pages used for memmap
<7> DMA zone: 0 pages reserved
<7> DMA zone: 8184 pages, LIFO batch:0
<4>[boot]0015 Setup Done
<6>PERCPU: Embedded 2 pages/cpu @c000000001200000 s100232 r0 d30840 u524288
<7>pcpu-alloc: s100232 r0 d30840 u524288 alloc=1*1048576
<7>pcpu-alloc: [0] 0 1
<4>Built 3 zonelists in Node order, mobility grouping on. Total pages: 65472
<4>Policy zone: DMA
<5>Kernel command line: root=/dev/sda3 sysrq=8 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M xmon=early
<6>PID hash table entries: 4096 (order: -1, 32768 bytes)
<4>freeing bootmem node 2
<4>freeing bootmem node 3
<6>Memory: 3896832k/4194304k available (9728k kernel code, 297472k reserved, 3072k data, 4291k bss, 576k init)
<6>SLUB: Genslabs=18, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=16
<6>Hierarchical RCU implementation.
<6>RCU-based detection of stalled CPUs is enabled.
<6>NR_IRQS:512
<4>[boot]0020 XICS Init
<4>[boot]0021 XICS Done
<7>pic: no ISA interrupt controller
<7>time_init: decrementer frequency = 512.000000 MHz
<7>time_init: processor frequency = 4704.000000 MHz
<6>clocksource: timebase mult[7d0000] shift[22] registered
<7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
<4>Console: colour dummy device 80x25
<6>console [hvc0] enabled, bootconsole disabled
<6>allocated 2621440 bytes of page_cgroup
<6>please try 'cgroup_disable=memory' option if you don't want memory cgroups
<6>Security Framework initialized
<6>SELinux: Disabled at boot.
<6>Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
<6>Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
<4>Mount-cache hash table entries: 4096
<6>Initializing cgroup subsys ns
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys memory
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<7>irq: irq 2 on host null mapped to virtual irq 16
<7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
<4>Processor 1 found.
<6>Brought up 2 CPUs
<7>Node 0 CPUs: 0-1
<7>Node 2 CPUs:
<7>Node 3 CPUs:
<7>CPU0 attaching sched-domain:
<7> domain 0: span 0-1 level SIBLING
<7> groups: 0 (cpu_power = 589) 1 (cpu_power = 589)
<7> domain 1: span 0-1 level CPU
<7> groups: 0-1 (cpu_power = 1178)
<7>CPU1 attaching sched-domain:
<7> domain 0: span 0-1 level SIBLING
<7> groups: 1 (cpu_power = 589) 0 (cpu_power = 589)
<7> domain 1: span 0-1 level CPU
<7> groups: 0-1 (cpu_power = 1178)
<6>NET: Registered protocol family 16
<6>IBM eBus Device Driver
<6>POWER6 performance monitor hardware support registered
<6>PCI: Probing PCI hardware
<7>PCI: Probing PCI hardware done
<4>bio: create slab <bio-0> at 0
<6>vgaarb: loaded
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Switching to clocksource timebase
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
<6>TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
<6>TCP bind hash table entries: 65536 (order: 5, 2097152 bytes)
<6>TCP: Hash tables configured (established 131072 bind 65536)
<6>TCP reno registered
<6>NET: Registered protocol family 1
<6>Unpacking initramfs...
<7>Switched to high resolution mode on CPU 0
<7>Switched to high resolution mode on CPU 1
<7>irq: irq 655360 on host null mapped to virtual irq 17
<7>irq: irq 655367 on host null mapped to virtual irq 18
<6>IOMMU table initialized, virtual merging enabled
<7>irq: irq 589825 on host null mapped to virtual irq 19
<7>RTAS daemon started
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(1253778214.210:1): initialized
<6>Kprobe smoke test started
<6>Kprobe smoke test passed successfully
<6>HugeTLB registered 16 MB page size, pre-allocated 0 pages
<6>HugeTLB registered 16 GB page size, pre-allocated 0 pages
<5>VFS: Disk quotas dquot_6.5.2
<4>Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
<6>Btrfs loaded
<6>msgmni has been set to 7608
<6>alg: No test for stdrng (krng)
<6>Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
<6>io scheduler noop registered
<6>io scheduler anticipatory registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<6>pci_hotplug: PCI Hot Plug PCI Core version: 0.5
<6>rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
<7>vio_register_driver: driver hvc_console registering
<7>HVSI: registered 0 devices
<6>Generic RTC Driver v1.07
<6>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
<6>pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
<6>input: Macintosh mouse button emulation as /devices/virtual/input/input0
<6>Uniform Multi-Platform E-IDE driver
<6>ide-gd driver 1.18
<6>IBM eHEA ethernet device driver (Release EHEA_0102)
<7>irq: irq 590088 on host null mapped to virtual irq 264
<6>ehea: eth0: Jumbo frames are disabled
<6>ehea: eth0 -> logical port id #2
<6>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<6>ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
<6>mice: PS/2 mouse device common for all mice
<6>EDAC MC: Ver: 2.1.0 Sep 24 2009
<6>usbcore: registered new interface driver hiddev
<6>usbcore: registered new interface driver usbhid
<6>usbhid: v2.6:USB HID core driver
<6>TCP cubic registered
<6>NET: Registered protocol family 15
<4>registered taskstats version 1
<4>Freeing unused kernel memory: 576k freed
<6>SysRq : Changing Loglevel
<4>Loglevel set to 8
<5>SCSI subsystem initialized
<7>vio_register_driver: driver ibmvscsi registering
<6>ibmvscsi 30000007: SRP_VERSION: 16.a
<6>scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
<6>ibmvscsi 30000007: partner initialization complete
<6>ibmvscsi 30000007: host srp version: 16.a, host partition VIO Server (1), OS 3, max io 1048576
<6>ibmvscsi 30000007: Client reserve enabled
<6>ibmvscsi 30000007: sent SRP login
<6>ibmvscsi 30000007: SRP_LOGIN succeeded
<5>scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3
<5>scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4
<6>udevd version 128 started
<5>sd 0:0:1:0: [sda] 146800640 512-byte logical blocks: (75.1 GB/70.0 GiB)
<5>sd 0:0:1:0: [sda] Write Protect is off
<7>sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08
<5>sd 0:0:1:0: [sda] Cache data unavailable
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through
<5>sd 0:0:1:0: [sda] Cache data unavailable
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through
<6> sda: sda1 sda2 sda3
<5>sd 0:0:1:0: [sda] Cache data unavailable
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through
<5>sd 0:0:1:0: [sda] Attached SCSI disk
<6>kjournald starting. Commit interval 5 seconds
<6>EXT3 FS on sda3, internal journal
<6>EXT3-fs: mounted filesystem with writeback data mode.
<6>udevd version 128 started
<5>sd 0:0:1:0: Attached scsi generic sg0 type 0
<5>scsi 0:0:2:0: Attached scsi generic sg1 type 5
<4>sr0: scsi-1 drive
<6>Uniform CD-ROM driver Revision: 3.20
<7>sr 0:0:2:0: Attached scsi CD-ROM sr0
<6>Adding 2096320k swap on /dev/sda2. Priority:-1 extents:1 across:2096320k
<6>device-mapper: uevent: version 1.0.3
<6>device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
<6>loop: module loaded
<6>fuse init (API version 7.13)
<7>irq: irq 33539 on host null mapped to virtual irq 259
<6>ehea: eth0: Physical port up
<6>ehea: External switch port is backup port
<7>irq: irq 33540 on host null mapped to virtual irq 260
<6>NET: Registered protocol family 10
<3>INFO: RCU detected CPU 0 stall (t=1000 jiffies)
^ permalink raw reply
* Re: [PATCH v2 0/2] cpu: pseries: Offline state framework.
From: Peter Zijlstra @ 2009-09-24 7:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <1253753307.7103.356.camel@pasglop>
On Thu, 2009-09-24 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-02 at 07:33 +0200, Peter Zijlstra wrote:
> >
> > I'm still thinking this is a bad idea.
> >
> > The OS should only know about online/offline.
> >
> > Use the hypervisor interface to deal with the cpu once its offline.
> >
> > That is, I think this interface you propose is a layering violation.
> >
> I don't quite follow your logic here. This is useful for more than just
> hypervisors. For example, take the HV out of the picture for a moment
> and imagine that the HW has the ability to offline CPU in various power
> levels, with varying latencies to bring them back.
cpu-hotplug is an utter slow path, anybody saying latency and hotplug in
the same sentence doesn't seem to grasp either or both concepts.
^ permalink raw reply
* Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: Richard Röjfors @ 2009-09-24 7:36 UTC (permalink / raw)
To: John Linn; +Cc: spi-devel-general, Andrew Morton, dbrownell, linuxppc-dev
In-Reply-To: <20090923224452.EAAFEB48046@mail109-sin.bigfish.com>
Hi again,
John Linn wrote:
>> -----Original Message-----
>> From: Richard Röjfors [mailto:richard.rojfors@mocean-labs.com]
>> Sent: Tuesday, September 22, 2009 3:59 PM
>> To: John Linn
>> Cc: spi-devel-general@lists.sourceforge.net; linuxppc-dev@ozlabs.org; Andrew Morton;
>> dbrownell@users.sourceforge.net
>> Subject: Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for
>> DS570
>>
>> John Linn wrote:
>>>> -----Original Message-----
>>>> From: linuxppc-dev-bounces+john.linn=xilinx.com@lists.ozlabs.org [mailto:linuxppc-dev-
>>>> bounces+john.linn=xilinx.com@lists.ozlabs.org] On Behalf Of Richard Röjfors
>>>> Sent: Tuesday, September 22, 2009 6:55 AM
>>>> To: spi-devel-general@lists.sourceforge.net
>>>> Cc: linuxppc-dev@ozlabs.org; Andrew Morton; dbrownell@users.sourceforge.net
>>>> Subject: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for
>>>> DS570
>>>>
>>>> This patch splits xilinx_spi into three parts, an OF and a platform
>>>> driver and generic part.
>>>>
>>>> The generic part now also works on X86 and also supports the Xilinx
>>>> SPI IP DS570
>>> Hi Richard,
>> Hi John,
>>
>>> The current driver (without this change) works for the newer XPS SPI device already as I run tests
>> on it each day using an SPI EEPROM.
>>
>> I'm not an expert of the Xilinx SPI blocks, I have only used one, the DS570.
>>
>> I don't think you use the DS570. I don't have the datasheet of the older one, but the register
>> offsets of the DS570 don't match the driver you are using. All the registers of the DS570 are at 4
>> bytes boundries.
>>
>
> I just verified that I am using the same IP block as you are, the DS570. But I'm not testing on the other IP you mention, the DS464.
Hi,
I have now verified the differences. Actually the blocks are register offset compatible. Since the
DS464 is 8 bit only, the driver is made to do only 8 bit accesses to some registers, for instance
TXD. On the 570 we have to do 32 bit (or at least 16) as the driver now support more than 8bit SPI.
We test against some SPI devices that are 16 bit.
The offsets in the code differs from the datasheet because since the device is big endian -> an 8
bit access to must happen 3 bytes up from the register base.
For instance the TXD register is defined at 0x6b, while the spec says 0x68. 0x68 + 0x3 = 0x6b. To
support more than 8 bit, we must do 16 bit access at 0x6a or 32 bit at 0x68.
To summarize;
You are completely right you can use the "old" driver on the DS570 as well, but _only_ for 8bit SPI.
My patch allows to run on X86 and with 16 or 32bit SPI.
Thanks to the observation from you, I got aware of the differences. I can simplify the code by
automatically increase registers offsets when doing 8 or 16 bits accesses.
I will come back with an updated patch.
Hope I made the situation clearer.
--Richard
^ permalink raw reply
* [PATCH-stable] powerpc: Fix incorrect setting of __HAVE_ARCH_PTE_SPECIAL
From: Benjamin Herrenschmidt @ 2009-09-24 7:16 UTC (permalink / raw)
To: stable; +Cc: linuxppc-dev list, bernhard.weirich, RFeany
From: Weirich, Bernhard <Bernhard.Weirich@riedel.net>
The test that decides whether to define __HAVE_ARCH_PTE_SPECIAL on
powerpc is bogus and will end up always defining it, even when
_PAGE_SPECIAL is not supported (in which case it's 0) such as on
8xx or 40x processors.
Signed-off-by: Bernhard Weirich <bernhard.weirich@riedel.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/pte-common.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Greg: I'm going to fix upstream differently, by having all CPU types
actually support _PAGE_SPECIAL, but I prefer the simple and obvious
fix for -stable.
This should apply to v2.6.30 and v2.6.31
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index a7e210b..0cd2e34 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -176,7 +176,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
#define HAVE_PAGE_AGP
/* Advertise support for _PAGE_SPECIAL */
-#ifdef _PAGE_SPECIAL
+#if _PAGE_SPECIAL != 0
#define __HAVE_ARCH_PTE_SPECIAL
#endif
^ 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