* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Sam Ravnborg @ 2009-09-25 19:45 UTC (permalink / raw)
To: Yuri Frolov; +Cc: rep.dot.nop, linuxppc-dev, linux-kbuild
In-Reply-To: <4ABB57CB.3000409@ru.mvista.com>
On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> 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.
Hi Yuri.
I like the way you do the extra link in Makefile.modpost.
But you need to redo some parts as per comments below.
>
>
> Fix linking modules against crtsavres.o
Please elaborate more on what this commit does.
>
> 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
Always good to include error messages.
> * 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.
But this GNUism can go - we do not use it in the kernel.
>
> 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
The naming sucks.
How about:
KBUILD_MODULE_LINK_SOURCE
This would tell the reader that this is source to be linked on a module.
And this is an arch specific thing so no need to preset it in top-level
Makefile.
But it is mandatory to include a description in Documentation/kbuild/kbuild.txt
> --- 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 $@ $<
Align this so cmd_as_o_S is under each other - as we do for cmd_cc_o_c
> +
> +$(LDFLAGS_MODULE_PREREQ): %.o: %.S FORCE
> + $(Q)mkdir -p $(dir $@)
> + $(call if_changed_dep,as_o_S)
Good catch with the mkdir - needed for O= builds.
I think we shall wrap this in
ifdef KBUILD_MODULE_LINK_SOURCE
...
endif
So we do not have an empty rule when it is not defined.
Please fix up these things and resubmit.
Thanks,
Sam
^ permalink raw reply
* RE: PCI HotPlug and Adding Resources after Linux Boots
From: Morrison, Tom @ 2009-09-25 20:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1253698927.7103.312.camel@pasglop>
Ben/all,
I have had some luck reserving some memory (via in this autoscan
(which reserves the resources)) which in this hack code - I reserve
an appropriate amount of resources for the bridge (by detecting=20
this special type of port).
The problem comes later on - when the Hotplug event comes - and it
still can't allocate the resources...
A member of this group (who is away from the office right now) had=20
the following comments:
>> In your case, if the only problem that you are running into is=20
>> that the resources cannot be assigned to the FPGA, it may be=20
>> sufficient to hardcode the forwarding addresses and subordinate=20
>> bridge number for port 6 of your 8616. The reason you are seeing=20
>> that error message is because the parent bridge device for the=20
>> detected FPGA (port 6 of the 8616) does not have forwarded=20
>> resource regions that match what the FPGA is trying to claim.
I guess the question I am asking is my friend's statement possibly
true. And, if he is correct - I am a little confused as to exactly=20
where/how do I determine and configure this forwarding=20
addresses/subordinate bridge number (I'm really a newbie at this
level of PCI configuration).
Thank you in advance to any/all who can help me figure this out!
Tom
>> -----Original Message-----
[Morrison, Tom]=20
>>=20
>> There's a few things you can do, though I don't have time just right now
>> to give you a detailed answer. I'll try again later.
>>=20
>> In the meantime, some of the answers could be around not using full
>> automatic resource assignment, but instead, pre-initializing the top
>> bridge with some resources that are going to be enough for the device.
>>=20
>> You can also try to get the bridge to re-allocate. There's various funky
>> locking issues with doing that though as long as it's during boot time,
>> it's not too much of a problem.
>>=20
>> There are other more or less hackish ways to do it, but I'll have to
>> give it more thought.
>>=20
>> I'm quite stretched at the moment so if you don't hear back from me in
>> the upcoming few days, don't hesitate to ping me again.
>>=20
>> Cheers,
>> Ben.
>>=20
>> >
>> > I am running Linux (2.6.23x (and 2.6.27.x)) on a MPC8572 based system.
>> >
>> >
>> >
>> > I have an 8616 switch that has a Port (6) connected to a FPGA that is
>> >
>> > NOT loaded at before Linux boots (note: this port is configured for
>> > HOTPLUG
>> >
>> > events - which we do get after FPGA is loaded). We are NOT using a
>> >
>> > static device tree map (because the devices in the system are very
>> > dynamic).
>> >
>> >
>> > We use instead the pci auto scan mechanism(s) to scan/assign
>> > resources
>> >
>> > (including into the BAR registers) at bootup to all of the devices
>> > that are
>> >
>> > attached to this MPC8572...
>> >
>> >
>> >
>> > Here is the port that is attached to the device (note: there are NO
>> >
>> > resources assigned at this point this port):
>> >
>> >
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> > 02:06.0 PCI bridge: PLX Technology, Inc.: Unknown device 8616 (rev bb)
>> > (prog-if 00 [Normal decode])
>> >
>> > Flags: bus master, fast devsel, latency 0
>> >
>> > Bus: primary=3D02, secondary=3D05, subordinate=3D05, sec-laten=
cy=3D0
>> >
>> > Capabilities: [40] Power Management version 3
>> >
>> > Capabilities: [48] Message Signalled Interrupts: 64bit+
>> > Queue=3D0/2 Enable+
>> >
>> > Capabilities: [68] #10 [0162]
>> >
>> > Capabilities: [a4] #0d [0000]
>> >
>> >
>> >
>> > root@slave7 ~ # lspci -t
>> >
>> > -+-[01]---00.0-[02-05]--+-01.0
>> >
>> > | +-04.0-[03]--
>> >
>> > | +-05.0-[04]--
>> >
>> > | \-06.0-[05]-
>> >
>> >
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> >
>> >
>> > Later, after I detect there is an FPGA to load - I load it. At
>> > completion of the
>> >
>> > loading of the FPGA - the 8616 detects the FPGA - and creates a
>> > HotPlug
>> >
>> > event that the PCI Express HotPlug Driver handles:
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> >
>> >
>> > root@slave7 ~ # pciehp: pcie_isr: intr_loc 8
>> >
>> > pciehp: pciehp: Presence/Notify input change.
>> >
>> > pciehp: Card present on Slot(0005_0070)
>> >
>> > pciehp: Surprise Removal
>> >
>> > pciehp: hpc_get_power_status: SLOTCTRL 80 value read 8
>> >
>> > pciehp: hpc_get_attention_status: SLOTCTRL 80, value read 8
>> >
>> > pciehp: board_added: slot device, slot offset, hp slot =3D 0, 0 ,0
>> >
>> > pciehp: hpc_check_lnk_status: lnk_status =3D 2021
>> >
>> > PCI: Found 0000:05:00.0 [1172/0004] 00ff00 00
>> >
>> > PCI: Calling quirk c0012d3c for 0000:05:00.0
>> >
>> > program_fw_provided_values: Could not get hotplug parameters
>> >
>> > entering assign resources (size: 2000000)
>> >
>> > PCI: Failed to allocate mem resource #0:2000000@0 for 0000:05:00.0
>> >
>> > bus pci: add device 0000:05:00.0
>> >
>> > entering uevent
>> >
>> > pci: Trying to Match Device 0000:05:00.0 with Driver pcieport-driver
>> >
>> > pci: Trying to Match Device 0000:05:00.0 with Driver serial
>> >
>> > pci: Trying to Match Device 0000:05:00.0 with Driver pexntb
>> >
>> > pciehp: hpc_get_power_status: SLOTCTRL 80 value read 8
>> >
>> > pciehp: hpc_get_attention_status: SLOTCTRL 80, value read 8
>> >
>> >
>> >
>> > 02:06.0 PCI bridge: PLX Technology, Inc.: Unknown device 8616 (rev bb)
>> > (prog-if 00 [Normal decode])
>> >
>> > Flags: bus master, fast devsel, latency 0
>> >
>> > Bus: primary=3D02, secondary=3D05, subordinate=3D05, sec-laten=
cy=3D0
>> >
>> > Capabilities: [40] Power Management version 3
>> >
>> > Capabilities: [48] Message Signalled Interrupts: 64bit+
>> > Queue=3D0/2 Enable+
>> >
>> > Capabilities: [68] #10 [0162]
>> >
>> > Capabilities: [a4] #0d [0000]
>> >
>> >
>> >
>> > 05:00.0 Class ff00: Altera Corporation: Unknown device 0004 (rev 01)
>> >
>> > Subsystem: Altera Corporation: Unknown device 0004
>> >
>> > Flags: fast devsel
>> >
>> > Capabilities: [50] Message Signalled Interrupts: 64bit+
>> > Queue=3D0/5 Enable-
>> >
>> > Capabilities: [78] Power Management version 3
>> >
>> > Capabilities: [80] #10 [0001]
>> >
>> >
>> >
>> > root@slave7 ~ # lspci -t
>> >
>> > -+-[01]---00.0-[02-05]--+-01.0
>> >
>> > | +-04.0-[03]--
>> >
>> > | +-05.0-[04]--
>> >
>> > | \-06.0-[05]----00.0
>> >
>> > \-[00]---00.0
>> >
>> >
>> >
>> > ----------------------------------------------------------------------=
-
>> --------------------------
>> >
>> >
>> >
>> > So, as you can see - the device has been read - and it requires 32M of
>> > resources, but
>> >
>> > because its parent doesn't have any resources allocated - it seemingly
>> > can't allocate and
>> >
>> > use any additional resources.
>> >
>> >
>> >
>> > How do I 'customize' and/or add resources at this point for this
>> > device (using semi-standard mechanisms)?
>> >
>> >
>> >
>> > Thanks in advance for any/all ideas...
>> >
>> >
>> >
>> >
>> >
>> > I
>> >
>> >
>> >
>> > Tom Morrison
>> > Principal Software Engineer
>> >
>> > EMPIRIX
>> > 20 Crosby Drive - Bedford, MA 01730
>> > p: 781.266.3567 f: 781.266.3670
>> > email: tmorrison@empirix.com
>> > www.empirix.com
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Linuxppc-dev mailing list
>> > Linuxppc-dev@lists.ozlabs.org
>> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>>=20
^ permalink raw reply
* warning: allocated section `.data_nosave' not in segment
From: Sean MacLennan @ 2009-09-25 20:54 UTC (permalink / raw)
To: linuxppc-dev
Anybody else getting these? They just started popping up with the
recent changes for 2.6.32.
ppc_4xxFP-ld: .tmp_vmlinux1: warning: allocated section `.data_nosave'
not in segment KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
ppc_4xxFP-ld: .tmp_vmlinux2: warning: allocated section `.data_nosave' not in segment
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
ppc_4xxFP-ld: vmlinux: warning: allocated section `.data_nosave' not in segment
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Benjamin Herrenschmidt @ 2009-09-25 21:12 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, linux-kernel, Venkatesh Pallipadi,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253890120.18939.189.camel@laptop>
On Fri, 2009-09-25 at 16:48 +0200, Peter Zijlstra wrote:
> On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote:
> > > I still think its a layering violation... its the hypervisor manager
> > > that should be bothered in what state an off-lined cpu is in.
> > >
> > That's not how our hypervisor works.
>
> Then fix it?
Are you serious ? :-)
> CPU hotplug is terribly invasive and expensive to the kernel, doing
> hotplug on a minute basis is just plain crazy.
>
> If you want a CPU in a keep it near and don't hand it back to the HV
> state, why not use cpusets to isolate it and simply not run tasks on it?
>
> cpusets don't use stopmachine and are much nicer to the rest of the
> kernel over-all.
Gautham, what is the different in term of power saving between having
it idle for long periods of time (which could do H_CEDE and with NO_HZ,
probably wouln't need to wake up that often) and having it unplugged in
a H_CEDE loop ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Rex Feany @ 2009-09-25 21:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1253847827.7103.504.camel@pasglop>
Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> > I think there's more finishyness to 8xx than we thought. IE. That
> > tlbil_va might have more reasons to be there than what the comment
> > seems to advertize. Can you try to move it even higher up ? IE.
> > Unconditionally at the beginning of set_pte_filter ?
> >
> > Also, if that doesn't help, can you try putting one in
> > set_access_flags_filter() just below ?
>
> Ok, I got a refresher on the whole concept of "unpopulated TLB entries"
> on 8xx, and that's damn scary. I think what mislead me initially is that
> the comment around the workaround is simply not properly describing the
> extent of the problem :-)
Oh boy, that sounds bad. Where is a good place to read about this?
> So I'm not going to make the 8xx TLB miss code sane, that's beyond what
> I'm prepare to do with it, but I suspect that this should fix it (on top
> of upstream). Let me know if that's enough or if we also need to put
> one of these in ptep_set_access_flags().
>
> Please let me know if that works for you.
Putting the tlbil_va() in the top of set_pte_filter() doesn't work - it
hangs on boot before it even prints any messages to the console.
However, adding tlbil_va() to ptep_set_access_flags() as you suggested
makes everything happy. I need to test it some more, but it looks good
so far. Below is what I am testing now.
thanks!
/rex.
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 5304093..aef552a 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -176,18 +176,19 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
struct page *pg = maybe_pte_to_page(pte);
if (!pg)
return pte;
- if (!test_bit(PG_arch_1, &pg->flags)) {
#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
- * "dcbst" from flush_dcache_icache) fault as write
- * operation if there is an unpopulated TLB entry
- * for the address in question. To workaround that,
- * we invalidate the TLB here, thus avoiding dcbst
- * misbehaviour.
- */
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
+ /* On 8xx, cache control instructions (particularly
+ * "dcbst" from flush_dcache_icache) fault as write
+ * operation if there is an unpopulated TLB entry
+ * for the address in question. To workaround that,
+ * we invalidate the TLB here, thus avoiding dcbst
+ * misbehaviour.
+ */
+ /* 8xx doesn't care about PID, size or ind args */
+ _tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */
+
+ if (!test_bit(PG_arch_1, &pg->flags)) {
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
@@ -308,6 +309,12 @@ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
int changed;
entry = set_access_flags_filter(entry, vma, dirty);
changed = !pte_same(*(ptep), entry);
+
+#ifdef CONFIG_8xx
+ /* 8xx doesn't care about PID, size or ind args */
+ _tlbil_va(address, 0, 0, 0);
+#endif /* CONFIG_8xx */
+
if (changed) {
if (!(vma->vm_flags & VM_HUGETLB))
assert_pte_locked(vma->vm_mm, address);
^ permalink raw reply related
* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Benjamin Herrenschmidt @ 2009-09-25 21:57 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: rep.dot.nop, Yuri Frolov, linuxppc-dev, linux-kbuild
In-Reply-To: <20090925194557.GA3323@merkur.ravnborg.org>
On Fri, 2009-09-25 at 21:45 +0200, Sam Ravnborg wrote:
> On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> > 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.
>
> Hi Yuri.
>
> I like the way you do the extra link in Makefile.modpost.
> But you need to redo some parts as per comments below.
> >
> > Fix linking modules against crtsavres.o
>
> Please elaborate more on what this commit does.
It's a support file that needs to be linked against every module
(aka libgcc like) and thus needs to be built before any module.
Cheers,
Ben.
^ permalink raw reply
* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Sam Ravnborg @ 2009-09-25 22:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: rep.dot.nop, Yuri Frolov, linuxppc-dev, linux-kbuild
In-Reply-To: <1253915852.7103.531.camel@pasglop>
On Sat, Sep 26, 2009 at 07:57:32AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-25 at 21:45 +0200, Sam Ravnborg wrote:
> > On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> > > 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.
> >
> > Hi Yuri.
> >
> > I like the way you do the extra link in Makefile.modpost.
> > But you need to redo some parts as per comments below.
>
> > >
> > > Fix linking modules against crtsavres.o
> >
> > Please elaborate more on what this commit does.
>
> It's a support file that needs to be linked against every module
> (aka libgcc like) and thus needs to be built before any module.
Yes.
My point was that the next version of the changelog should
include this information - as well as kbuild.txt.
Sam
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Pavel Machek @ 2009-09-26 9:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253016701.5506.73.camel@laptop>
On Tue 2009-09-15 14:11:41, Peter Zijlstra wrote:
> On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote:
> > This patchset contains the offline state driver implemented for
> > pSeries. For pSeries, we define three available_hotplug_states. They are:
> >
> > online: The processor is online.
> >
> > offline: This is the the default behaviour when the cpu is offlined
> > even in the absense of this driver. The CPU would call make an
> > rtas_stop_self() call and hand over the CPU back to the resource pool,
> > thereby effectively deallocating that vCPU from the LPAR.
> > NOTE: This would result in a configuration change to the LPAR
> > which is visible to the outside world.
> >
> > inactive: This cedes the vCPU to the hypervisor with a cede latency
> > specifier value 2.
> > NOTE: This option does not result in a configuration change
> > and the vCPU would be still entitled to the LPAR to which it earlier
> > belong to.
> >
> > Any feedback on the patchset will be immensely valuable.
>
> I still think its a layering violation... its the hypervisor manager
> that should be bothered in what state an off-lined cpu is in.
Agreed. Proposed interface is ugly.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Market research for new PowerPC system
From: Konstantinos Margaritis @ 2009-09-26 11:38 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc, opensuse-ppc; +Cc: Konstantinos Margaritis
(Sorry for the cross-posting, please ignore if you are not interested
in this, CC me as I'm not subscribed)
Hi,
First some introductions. I'm Konstantinos Margaritis, a long time
Amiga/BeOS/Linux user/developer and a PowerPC fan, former Debian
Developer, also a SIMD/AltiVec fanatic and the author of libfreevec.
I've posted this on the following sites:
http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29594&forum=33&start=0&viewmode=flat&order=0
http://www.amiga.org/forums/showthread.php?t=49424
http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=6465&forum=11
http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=3768&forum=4
http://www.haiku-os.org/community/forum/market_research_new_powerpc_system#comment-12604
To anyone who is not a PowerPC user, it might seem like crazy, but
here it goes:
I'm considering funding the design & production of a new PowerPC
system (well, the motherboard, the rest are typical pc stuff and a
case). No this is not a joke, I've been wanting to do this for a long
time, and perhaps the chance will be given to me now. But before I
spend any money on this, I want to do a little market research first.
I know the market is literally "dying" for a new powerpc motherboard,
but exactly how many are there that want to buy one?
Ok, let's give some rough specs first. I'm considering 3 choices -not
in order of probability/importance:
1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
frequencies are much more expensive and the cost of the final board
would be prohibitive.
2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and
includes a 2D DIU display unit -quite fast, but no 3D unfortunately.
3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise).
Apart from the much lower chip price, this one includes dual gigabit
ethernet, dual SATA, USB 2.0 and a 2D DIU display unit (same as the
MPC8610). So this one would lower the cost of the board quite much.
Disadvantages: No AltiVec unit (it sucks I know), though it includes
an SPE unit which is not that bad, and availability will be in Q3/Q4
2010, so that's a long wait.
Now, the end motherboard will probably be MicroATX (in the 8640D/8610
case) or PicoITX (in the P1022 case), and it will definitely include:
* SATA connectors
* USB (possibly 2 back and 2 front, but that's discussable)
* Dual gigabit (at least one will be there, in the case of the
MPC8640D we might even have 4!!!)
* Sound (of course, SPDIF support will definitely be there)
* 1 PCI-e slot 1x
* 1 PCI-e slot (4x in the P1022 case, 8x in the MPC86xx cases)
Ok, what I want to know is if people would really really buy one of
these. End price is estimated to be ~around~ 350EUR for the P1022
board or ~500EUR (definitely more in the case of 8640D) in the case of
the other boards. Besides being more expensive, the MPC86xx chips,
don't include SATA, USB and only one of ethernet/sound (quad-gige in
MPC8640D case, or sound in the case of MPC8610). I know this sounds a
lot, but it's the reality, there is not enough funding to build
enormous amounts of units and bring the prices down substantially, we
have to start low and build up from there. In case you are wondering,
yes, the boards will be designed/produced by bPlan and funded by my
company (Codex).
Support for OSes: Linux definitely, Haiku most probably and there is a
possibility of supporting AmigaOS/MorphOS, which will depend on the
actual feedback I get from those users.
I would like to make a list of everyone that is really interested in
such a system, so it would really help me make a decision sooner
rather than later if you would send me a few personal details to markos@codex.gr
with subject "PowerPC board":
* Name
* Country
* email (definitely, I'd have to reach you back!)
* Phone/Skype (optional, please include international prefix)
* Forum you saw this post (ok, Morphzone in this case)
* OS of preference
* board you would be most interested in (MPC8610/MPC8640D/P1022)
* preferred price (please have in mind the estimated price quotes I
mentioned, it might be lower but that's not very probable)
* Other notes/comments
Also, I found out that I had to state my case on many forums to prove
that this is not vapourware. Well, it will not be vapourware, if I get
feedback. So far the feedback I got can be summarized here:
http://www.codex.gr/index.php?pageID=&blogItem=60
Thanks a lot for your time and I hope this system becomes a reality.
Konstantinos Margaritis
Codex
^ permalink raw reply
* Problem with futex call on 8xx
From: Frank Svendsbøe @ 2009-09-26 12:00 UTC (permalink / raw)
To: linuxppc-dev
Hi
I'm having a problem with ~100% CPU load on MPC8xx when calling
pthread_cond_wait.
Running strace, I get:
futex(0x10040d5c, FUTEX_WAIT, 1, NULL) = -1 ENOSYS (Function not implemented)
.. and this call is inifinitely repeating, which explains the high load.
I'm running Linux 2.6.26-rc2 (not newer due to the slowdown problem
introduced by commit
8d30c14cab30d405a05f2aaceda1e9ad57800f36, as pointed out by Rex Feany
this week), and
glibc v2.6 (part of ELDK 4.2).
Is this a problem due to an error in the futex implementation in
glibc, or a kernel problem?
Best regards,
Frank
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Stephen Rothwell @ 2009-09-26 12:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <0046254A-432D-4AE3-9B9F-C0D30311B7D7@codex.gr>
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
Just in case anyone feels like flaming about this post, I allowed it
because I thought some of you may feel inclined to provide some technical
advise, enthusiasm for someone else building PowerPC systems. If you
object, then just ignore the post ...
On Sat, 26 Sep 2009 14:38:38 +0300 Konstantinos Margaritis <markos@codex.gr> wrote:
>
> (Sorry for the cross-posting, please ignore if you are not interested
> in this, CC me as I'm not subscribed)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=
From: Yuri Frolov @ 2009-09-26 12:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: rep.dot.nop, linuxppc-dev, linux-kbuild
In-Reply-To: <20090925194557.GA3323@merkur.ravnborg.org>
Hello, here is a fixed version.
Compile and export arch/powerpc/lib/crtsavres.o in order to fix the
"arch/powerpc/lib/crtsavres.o not found" error when "O=" option
is employed for external module compilation.
crtsavres.o is a support file, containing save/restore code from gcc,
simplified down for powerpc architecture needs.
This file needs to be linked against every module and thus to be built
before any module.
Documentation/kbuild/kbuild.txt | 8 ++++++++
Makefile | 2 +-
arch/powerpc/Makefile | 2 +-
scripts/Makefile.modpost | 14 ++++++++++++--
4 files changed, 22 insertions(+), 4 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-26 13:35:32.000000000 +0400
@@ -93,7 +93,7 @@ else
KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
endif
else
-LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
+KBUILD_MODULE_LINK_SOURCE += arch/powerpc/lib/crtsavres.o
endif
ifeq ($(CONFIG_TUNE_CELL),y)
diff -urpN -X linux-2.6/Documentation/dontdiff linux-2.6/Documentation/kbuild/kbuild.txt linux-2.6-powerpc-crtsavres/Documentation/kbuild/kbuild.txt
--- linux-2.6/Documentation/kbuild/kbuild.txt 2009-09-17 20:04:30.000000000 +0400
+++ linux-2.6-powerpc-crtsavres/Documentation/kbuild/kbuild.txt 2009-09-26 16:03:50.000000000 +0400
@@ -132,3 +132,11 @@ For tags/TAGS/cscope targets, you can sp
to be included in the databases, separated by blank space. E.g.:
$ make ALLSOURCE_ARCHS="x86 mips arm" tags
+
+KBUILD_MODULE_LINK_SOURCE
+--------------------------------------------------
+Compile and export arch/powerpc/lib/crtsavres.o
+when "O=" option is employed for powerpc external module compilation.
+This file needs to be linked against every module and thus to be built
+before any module.
+
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-26 14:23:27.000000000 +0400
@@ -354,7 +354,7 @@ KERNELVERSION = $(VERSION).$(PATCHLEVEL)
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
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 CHECK CHECKFLAGS KBUILD_MODULE_LINK_SOURCE
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-26 14:34:28.000000000 +0400
@@ -122,14 +122,24 @@ 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 $@ $<
+
+ifdef KBUILD_MODULE_LINK_SOURCE
+$(KBUILD_MODULE_LINK_SOURCE): %.o: %.S FORCE
+ $(Q)mkdir -p $(dir $@)
+ $(call if_changed_dep,as_o_S)
+endif
+
+$(modules:.ko=.mod.o): %.mod.o: %.mod.c $(KBUILD_MODULE_LINK_SOURCE) 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) $(KBUILD_MODULE_LINK_SOURCE) \
+ $(LDFLAGS_MODULE) -o $@ \
$(filter-out FORCE,$^)
$(modules): %.ko :%.o %.mod.o FORCE
On 09/25/2009 11:45 PM, Sam Ravnborg wrote:
> On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
>> 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.
>
> Hi Yuri.
>
> I like the way you do the extra link in Makefile.modpost.
> But you need to redo some parts as per comments below.
>
>>
>> Fix linking modules against crtsavres.o
>
> Please elaborate more on what this commit does.
>
>> 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
>
> Always good to include error messages.
>
>> * 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.
> But this GNUism can go - we do not use it in the kernel.
>
>> 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
>
> The naming sucks.
> How about:
>
> KBUILD_MODULE_LINK_SOURCE
>
> This would tell the reader that this is source to be linked on a module.
>
> And this is an arch specific thing so no need to preset it in top-level
> Makefile.
> But it is mandatory to include a description in Documentation/kbuild/kbuild.txt
>
>
>> --- 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 $@ $<
>
> Align this so cmd_as_o_S is under each other - as we do for cmd_cc_o_c
>
>
>> +
>> +$(LDFLAGS_MODULE_PREREQ): %.o: %.S FORCE
>> + $(Q)mkdir -p $(dir $@)
>> + $(call if_changed_dep,as_o_S)
> Good catch with the mkdir - needed for O= builds.
> I think we shall wrap this in
> ifdef KBUILD_MODULE_LINK_SOURCE
> ...
> endif
>
> So we do not have an empty rule when it is not defined.
>
> Please fix up these things and resubmit.
>
> Thanks,
> Sam
^ permalink raw reply
* Re: Problem with futex call on 8xx
From: Frank Svendsbøe @ 2009-09-26 12:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Detlev Zundel
In-Reply-To: <1ba63b520909260500k3b7a0ed1l2d75116053ae5522@mail.gmail.com>
I'll answer myself, since I just found the solution to the problem -
with help from 'kos_tom'
at #uclibc on freenode.
The problem is caused by a missing 'CONFIG_FUTEX=3Dy' in the defconfig
for our target.
The system we're developing is based on the Adder port by Scott Wood, which=
is
also missing this, so a patch should be committed for this and
possible other 8xx targets
as well.
Best regards,
Frank
On Sat, Sep 26, 2009 at 2:00 PM, Frank Svendsb=F8e
<frank.svendsboe@gmail.com> wrote:
> Hi
> I'm having a problem with ~100% CPU load on MPC8xx when calling
> pthread_cond_wait.
> Running strace, I get:
>
> futex(0x10040d5c, FUTEX_WAIT, 1, NULL) =A0=3D -1 ENOSYS (Function not imp=
lemented)
>
> .. and this call is inifinitely repeating, which explains the high load.
>
> I'm running Linux 2.6.26-rc2 (not newer due to the slowdown problem
> introduced by commit
> 8d30c14cab30d405a05f2aaceda1e9ad57800f36, as pointed out by Rex Feany
> this week), and
> glibc v2.6 (part of ELDK 4.2).
>
> Is this a problem due to an error in the futex implementation in
> glibc, or a kernel problem?
>
> Best regards,
> Frank
>
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Guennadi Liakhovetski @ 2009-09-26 17:58 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: debian-powerpc, linuxppc-dev, opensuse-ppc
In-Reply-To: <0046254A-432D-4AE3-9B9F-C0D30311B7D7@codex.gr>
On Sat, 26 Sep 2009, Konstantinos Margaritis wrote:
> (Sorry for the cross-posting, please ignore if you are not interested in this,
> CC me as I'm not subscribed)
> Hi,
>
> First some introductions. I'm Konstantinos Margaritis, a long time
> Amiga/BeOS/Linux user/developer and a PowerPC fan, former Debian Developer,
> also a SIMD/AltiVec fanatic and the author of libfreevec. I've posted this on
> the following sites:
>
> http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29594&forum=33&start=0&viewmode=flat&order=0
>
> http://www.amiga.org/forums/showthread.php?t=49424
>
> http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=6465&forum=11
>
> http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=3768&forum=4
>
> http://www.haiku-os.org/community/forum/market_research_new_powerpc_system#comment-12604
>
> To anyone who is not a PowerPC user, it might seem like crazy, but here it
> goes:
>
> I'm considering funding the design & production of a new PowerPC system (well,
> the motherboard, the rest are typical pc stuff and a case). No this is not a
> joke, I've been wanting to do this for a long time, and perhaps the chance
> will be given to me now. But before I spend any money on this, I want to do a
> little market research first. I know the market is literally "dying" for a new
> powerpc motherboard, but exactly how many are there that want to buy one?
Ok, just a short comment. In principle I like diversity, competition, etc.
And it was somewhat sad when Apple abandoned ppc. But honestly - why
should I be buying a ppc desktop system? If we restrict our comparison to
Linux, because that's what I'm using, what advantages would a ppc system
give me over a comparable in price ix86 system? This is not meant
negatively, I just have not followed recent ppc CPUs from the "desktop"
range, so, this is a real honest question. Would such a system provide
more MIPS per Watt at the same price? Or more periferals? Or some specific
hardware blocks unavailable or unsupported om ix86?
Thanks
Guennadi
>
> Ok, let's give some rough specs first. I'm considering 3 choices -not in order
> of probability/importance:
>
> 1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
> frequencies are much more expensive and the cost of the final board would be
> prohibitive.
> 2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and includes a
> 2D DIU display unit -quite fast, but no 3D unfortunately.
> 3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise). Apart
> from the much lower chip price, this one includes dual gigabit ethernet, dual
> SATA, USB 2.0 and a 2D DIU display unit (same as the MPC8610). So this one
> would lower the cost of the board quite much. Disadvantages: No AltiVec unit
> (it sucks I know), though it includes an SPE unit which is not that bad, and
> availability will be in Q3/Q4 2010, so that's a long wait.
>
> Now, the end motherboard will probably be MicroATX (in the 8640D/8610 case) or
> PicoITX (in the P1022 case), and it will definitely include:
>
> * SATA connectors
> * USB (possibly 2 back and 2 front, but that's discussable)
> * Dual gigabit (at least one will be there, in the case of the MPC8640D we
> might even have 4!!!)
> * Sound (of course, SPDIF support will definitely be there)
> * 1 PCI-e slot 1x
> * 1 PCI-e slot (4x in the P1022 case, 8x in the MPC86xx cases)
>
> Ok, what I want to know is if people would really really buy one of these. End
> price is estimated to be ~around~ 350EUR for the P1022 board or ~500EUR
> (definitely more in the case of 8640D) in the case of the other boards.
> Besides being more expensive, the MPC86xx chips, don't include SATA, USB and
> only one of ethernet/sound (quad-gige in MPC8640D case, or sound in the case
> of MPC8610). I know this sounds a lot, but it's the reality, there is not
> enough funding to build enormous amounts of units and bring the prices down
> substantially, we have to start low and build up from there. In case you are
> wondering, yes, the boards will be designed/produced by bPlan and funded by my
> company (Codex).
>
> Support for OSes: Linux definitely, Haiku most probably and there is a
> possibility of supporting AmigaOS/MorphOS, which will depend on the actual
> feedback I get from those users.
>
> I would like to make a list of everyone that is really interested in such a
> system, so it would really help me make a decision sooner rather than later if
> you would send me a few personal details to markos@codex.gr with subject
> "PowerPC board":
>
> * Name
> * Country
> * email (definitely, I'd have to reach you back!)
> * Phone/Skype (optional, please include international prefix)
> * Forum you saw this post (ok, Morphzone in this case)
> * OS of preference
> * board you would be most interested in (MPC8610/MPC8640D/P1022)
> * preferred price (please have in mind the estimated price quotes I mentioned,
> it might be lower but that's not very probable)
> * Other notes/comments
>
> Also, I found out that I had to state my case on many forums to prove that
> this is not vapourware. Well, it will not be vapourware, if I get feedback. So
> far the feedback I got can be summarized here:
>
> http://www.codex.gr/index.php?pageID=&blogItem=60
>
> Thanks a lot for your time and I hope this system becomes a reality.
>
> Konstantinos Margaritis
>
> Codex
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Leon Woestenberg @ 2009-09-26 18:15 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: debian-powerpc, linuxppc-dev, opensuse-ppc
In-Reply-To: <0046254A-432D-4AE3-9B9F-C0D30311B7D7@codex.gr>
Hello,
first off, I like your idea. This is my public reply, I'll give a
personal reply later.
On Sat, Sep 26, 2009 at 1:38 PM, Konstantinos Margaritis
<markos@codex.gr> wrote:
> I'm considering funding the design & production of a new PowerPC system
> (well, the motherboard, the rest are typical pc stuff and a case). No this
>
What makes the system stand out, from say a Atom based PC?
(I know, playing devil's advocate here)
> 1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
> frequencies are much more expensive and the cost of the final board would be
> prohibitive.
> 2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and includes
> a 2D DIU display unit -quite fast, but no 3D unfortunately.
> 3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise). Apart
> from the much lower chip price, this one includes dual gigabit ethernet,
> dual SATA, USB 2.0 and a 2D DIU display unit (same as the MPC8610). So this
>
Go for QorIQ P1022, it's the ideal SoC for many applications.
Alternatively, it's predecessor MPC8536E available now, ~same specs,
but higher power. But not the two you mention please.
> End price is estimated to be ~around~ 350EUR for the P1022 board or ~500EUR
>
Pico P1022 or Pico MPC8536E pls.
and throw PCI Express (x4) in the party!
(hint: I haven't seen an Intel board with Atom and PCI Express yet).
Will the board be open hardware? I.e. an open sourced design?
Regards,
--
Leon
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Konstantinos Margaritis @ 2009-09-26 19:08 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <c384c5ea0909261115t361e019auadf3b76a312ff2d1@mail.gmail.com>
> What makes the system stand out, from say a Atom based PC?
As you said, PCI Express, *actual* low power and probably higher speed
-all cpus mention are faster than the Atom at least in relative terms.
The SoC design means less components on the board, so smaller sizes
might be achieved.
> Go for QorIQ P1022, it's the ideal SoC for many applications.
>
I know, I like the chip very much, the thing is that it won't be
available till Q4/2010, so it will take quite a bit more thinking.
> Alternatively, it's predecessor MPC8536E available now, ~same specs,
> but higher power. But not the two you mention please.
Why not? I mean seriously, why would you dislike them?
>> End price is estimated to be ~around~ 350EUR for the P1022 board or
>> ~500EUR
>>
> Pico P1022 or Pico MPC8536E pls.
> and throw PCI Express (x4) in the party!
definetely PCI Express for all CPUs anyway.
> (hint: I haven't seen an Intel board with Atom and PCI Express yet).
>
> Will the board be open hardware? I.e. an open sourced design?
I don't know yet, to be frank, I haven't thought about it, though I've
worked with open source software for years, I have no experience
whatsoever with open source hardware, I don't know the dangers,
pitfalls, advantages, etc.
Konstantinos
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Konstantinos Margaritis @ 2009-09-26 19:15 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0909261949240.4273@axis700.grange>
On Sep 26, 2009, at 8:58 PM, Guennadi Liakhovetski wrote:
>
> Ok, just a short comment. In principle I like diversity,
> competition, etc.
> And it was somewhat sad when Apple abandoned ppc. But honestly - why
> should I be buying a ppc desktop system? If we restrict our
> comparison to
> Linux, because that's what I'm using, what advantages would a ppc
> system
> give me over a comparable in price ix86 system? This is not meant
> negatively, I just have not followed recent ppc CPUs from the
> "desktop"
> range, so, this is a real honest question. Would such a system provide
> more MIPS per Watt at the same price? Or more periferals? Or some
> specific
> hardware blocks unavailable or unsupported om ix86?
Ok, I remember a few years back when we had Alpha, MIPS, x86, SPARC,
PowerPC, etc all viable platforms to use and work on. Now it's only
x86. I'm sorry,
I just don't like it. I cannot answer your question, no more than I
can answer why
a car lover buys an old Jaguar antique for the price he could buy a
new Audi S8
for example. Well, ok the analogy is not exactly the same, but you get
the point.
If not, well, the ppc board would just lessen the current gap between
x86/ppc in
favour of the -admittedly very small- ppc desktop/hobbyist market.
Nevertheless,
I'm pretty sure the system would find itself in many ppc developers'
desks, just
because they can't really buy something *new* with those specs, at
this price range.
Ok, perhaps I will fail and just add my name to the list of failed
hardware projects.
Perhaps not. I really don't know if I can convince you if you don't
want to be convinced.
Deliver a super ppc system that beats all x86 systems at the same or
better price? No,
I'm sorry I cannot do that, and I never implied I could. Only IBM/
Freescale could do that
and even then the game would not be in their favour.
Regards
Konstantinos
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Guennadi Liakhovetski @ 2009-09-26 20:49 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <95FC0E0B-F6FE-45FD-A84E-AC4AF477F786@codex.gr>
On Sat, 26 Sep 2009, Konstantinos Margaritis wrote:
>
> On Sep 26, 2009, at 8:58 PM, Guennadi Liakhovetski wrote:
> >
> > Ok, just a short comment. In principle I like diversity, competition, etc.
> > And it was somewhat sad when Apple abandoned ppc. But honestly - why
> > should I be buying a ppc desktop system? If we restrict our comparison to
> > Linux, because that's what I'm using, what advantages would a ppc system
> > give me over a comparable in price ix86 system? This is not meant
> > negatively, I just have not followed recent ppc CPUs from the "desktop"
> > range, so, this is a real honest question. Would such a system provide
> > more MIPS per Watt at the same price? Or more periferals? Or some specific
> > hardware blocks unavailable or unsupported om ix86?
>
> Ok, I remember a few years back when we had Alpha, MIPS, x86, SPARC,
> PowerPC, etc all viable platforms to use and work on. Now it's only x86. I'm sorry,
> I just don't like it. I cannot answer your question, no more than I can answer why
> a car lover buys an old Jaguar antique for the price he could buy a new Audi S8
> for example. Well, ok the analogy is not exactly the same, but you get the point.
> If not, well, the ppc board would just lessen the current gap between x86/ppc in
> favour of the -admittedly very small- ppc desktop/hobbyist market. Nevertheless,
> I'm pretty sure the system would find itself in many ppc developers' desks, just
> because they can't really buy something *new* with those specs, at this price range.
> Ok, perhaps I will fail and just add my name to the list of failed hardware projects.
> Perhaps not. I really don't know if I can convince you if you don't want to be convinced.
> Deliver a super ppc system that beats all x86 systems at the same or better price? No,
> I'm sorry I cannot do that, and I never implied I could. Only IBM/Freescale could do that
> and even then the game would not be in their favour.
Ok, fair enough, as I said, that wasn't meant as a pun. I'd really love to
see non-x86 desktops _successful_ on the market, and I don't mean just
ARM-based netbooks, nettops, tablets, etc.:-) So, good luck to you, and I
really mean it! Interestingly, ppc competes on embedded, competes on
servers, but practically absent on desktops (apart from a couple of
hackintosh manufacturers:-)), so, maybe indeed there's still something
that ppc can offer us that x86 cannot - as a self-contained system, and
not just a development platform for ppc professionals?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: lite5200b kernel not booting
From: Albrecht Dreß @ 2009-09-27 12:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <9e4733910909250515p60e0b0e0v8c10063326fe882c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
Am 25.09.09 14:15 schrieb(en) Jon Smirl:
> No one has tried the Macraigor USB wiggler on the mpc5200 and
> reported back if it works.
I'm working on a self-designed, roughly Lite5200B based board, and
first thought about buying this device. However, I tried to contact
their support several times (as to get a confirmation that it will work
with our flash and board-specific design), but never got a reply. So
we ended up with the Abatron BDI3000, which is rather expensive, but
works really flawlessly, and Abatron's (and their German distributor's)
support is just *excellent* (fast and professional).
> uboot 1.2 is very old. That may be the cause of your problems. For
> example old u-boots don't initialize the PCI hardware correctly on
> systems that don't have PCI implemented.
U-Boot 2009.03 together with ELDK 4.2 work flawlessly on both the
Lite5200B and on our design.
> In general the current powerpc kernel works fine on the mpc5200b. We
> are running it on four different CPU boards but I don't have a
> lite5200b.
I can only confirm that the stock (from kernel.org) kernels run
flawlessly on our boards (the latest I tried was 2.6.30.3, though, but
I don't expect any issues with 2.6.31.1).
Hope this helps,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-09-27 13:22 UTC (permalink / raw)
To: Rex Feany; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20090925211848.GA3371@compile2.chatsunix.int.mrv.com>
>
> Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> >
> > > I think there's more finishyness to 8xx than we thought. IE. That
> > > tlbil_va might have more reasons to be there than what the comment
> > > seems to advertize. Can you try to move it even higher up ? IE.
> > > Unconditionally at the beginning of set_pte_filter ?
> > >
> > > Also, if that doesn't help, can you try putting one in
> > > set_access_flags_filter() just below ?
> >
> > Ok, I got a refresher on the whole concept of "unpopulated TLB entries"
> > on 8xx, and that's damn scary. I think what mislead me initially is that
> > the comment around the workaround is simply not properly describing the
> > extent of the problem :-)
>
> Oh boy, that sounds bad. Where is a good place to read about this?
>
> > So I'm not going to make the 8xx TLB miss code sane, that's beyond what
> > I'm prepare to do with it, but I suspect that this should fix it (on top
> > of upstream). Let me know if that's enough or if we also need to put
> > one of these in ptep_set_access_flags().
> >
> > Please let me know if that works for you.
>
> Putting the tlbil_va() in the top of set_pte_filter() doesn't work - it
> hangs on boot before it even prints any messages to the console.
>
> However, adding tlbil_va() to ptep_set_access_flags() as you suggested
> makes everything happy. I need to test it some more, but it looks good
> so far. Below is what I am testing now.
8xx, is getting very hacky and I suspect that the only long term fix is
add code to trap the cache instructions in TLB error/miss and fixup the
exception in page fault handler. This will also have the added benefit on being able
to use the cache instructions in both kernel and user space like any other
ppc arch.
Jocke
^ permalink raw reply
* Re: [PATCH] i2c-mpc: Do not generate STOP after read.
From: Joakim Tjernlund @ 2009-09-27 22:26 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, linux-i2c, Esben Haabendal
In-Reply-To: <4ABC94ED.6070508@grandegger.com>
Jean, I just noticed you pull request for i2c on LKML but I didn't see this
patch nor have I got any feedback from you. What is your view?
Jocke
Wolfgang Grandegger <wg@grandegger.com> wrote on 25/09/2009 12:01:17:
>
> Joakim Tjernlund wrote:
> > The driver always ends a read with a STOP condition which
> > breaks subsequent I2C reads/writes in the same transaction as
> > these expect to do a repeated START(ReSTART).
> >
> > This will also help I2C multimaster as the bus will not be released
> > after the first read, but when the whole transaction ends.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Tested-by: Wolfgang Grandegger <wg@grandegger.com>
>
> on a MPC8548 board with an up-to-date kernel. I did not realize any
> problems.
>
> Wolfgang.
>
^ permalink raw reply
* Re: GPIO driver for MPC8313.
From: Johnny Hung @ 2009-09-28 2:43 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, linux-embedded
In-Reply-To: <cb9ecdfa0909230820k6ebbd589o409e58e2d9b6740c@mail.gmail.com>
The kerne source I used now is 2.6.23 with MPC8313-erdb pached. I
think I should port 2.6.28 gpio function back to 2.6.23. Is it a
common way to implement it in the kernel I used or I should port
MPC8313-erdb pached to 2.6.28 opposite?
BRs, H. Johnny
2009/9/23 Johnny Hung <johnny.hacking@gmail.com>:
> Many thanks for your help. I will try it.
>
> 2009/9/23 Peter Korsgaard <jacmet@sunsite.dk>:
>>>>>>> "Johnny" =3D=3D Johnny Hung <johnny.hacking@gmail.com> writes:
>>
>> =A0Johnny> Thanks, got it. BTW, how to trigger GPIO level in user space
>> =A0Johnny> application? I also found
>> =A0Johnny> arch/powerpc/platforms/52xx/mpc52xx_gpio.c is a good
>> =A0Johnny> example. Any reply is appreciate.
>>
>> Through sysfs. See 'Sysfs Interface for Userspace' section of
>> Documentation/gpio.txt
>>
>> --
>> Bye, Peter Korsgaard
>>
>
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Benjamin Herrenschmidt @ 2009-09-28 3:21 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OFEC38184A.A376E71D-ONC125763E.0048F581-C125763E.00497FD3@transmode.se>
On Sun, 2009-09-27 at 15:22 +0200, Joakim Tjernlund wrote:
> > However, adding tlbil_va() to ptep_set_access_flags() as you suggested
> > makes everything happy. I need to test it some more, but it looks good
> > so far. Below is what I am testing now.
>
> 8xx, is getting very hacky and I suspect that the only long term fix is
> add code to trap the cache instructions in TLB error/miss and fixup the
> exception in page fault handler. This will also have the added benefit on being able
> to use the cache instructions in both kernel and user space like any other
> ppc arch.
First I'd like to understand exactly what's happening today, since
it makes little sense :-) I suppose I'll have to get myself some
8xx doco and understand how the bloody MMU works.
Then, I saw your old patch and it's -very- invasive. If we can get away
with a one liner just adding tlbil_va in the right place, I think I'm
happy to stick with it until somebody comes up with a real good reason
to do more :-) 8xx is on life support and has been around for long
enough without people feeling the need overall to work around that
problem so I'm tempted to keep the status-quo here.
Cheers,
Ben
^ permalink raw reply
* [0/5] Assorted hugepage cleanups (v3)
From: David Gibson @ 2009-09-28 4:39 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Currently, ordinary pages use one pagetable layout, and each different
hugepage size uses a slightly different variant layout. A number of
places which need to walk the pagetable must first check the slice map
to see what the pagetable layout then handle the various different
forms. New hardware, like Book3E is liable to introduce more possible
variants.
This patch series, therefore, is designed to simplify the matter by
limiting knowledge of the pagetable layout to only the allocation
path. With this patch, ordinary pages are handled as ever, with a
fixed 4 (or 3) level tree. All other variants branch off from some
layer of that with a specially marked PGD/PUD/PMD pointer which also
contains enough information to interpret the directories below that
point. This means that things walking the pagetables (without
allocating) don't need to look up the slice map, they can just step
down the tree in the usual way, branching off to the "non-standard
layout" path for hugepages, which uses the embdded information to
interpret the tree from that point on.
This reduces the source size in a number of places, and means that
newer variants on the pagetable layout to handle new hardware and new
features will need to alter the existing code in less places.
In addition we split out the hash / classic MMU specific code into a
separate hugetlbpage-hash64.c file. This will make adding support for
other MMUs (like 440 and/or Book3E) easier.
I've used the libhugetlbfs testsuite to test these patches on a
Power5+ machine, but they could certainly do with more testing. In
particular, I don't have any suitable hardware to test 16G pages.
V2: Made the tweaks that BenH suggested to patch 2 of the original
series. Some corresponding tweaks in patch 3 to match.
V3: Fix several small bugs.
* We had a BUILD_BUG_ON() which is broken by the recent
problems with BUILD_BUG_ON(). Since it's not a hot path, use a
runtime BUG_ON() instead.
* The ifdef logic was inverted for the test against
CONFIG_SPU_FS_64K_LS.
* That in turn masked a compile bug (using a non-existent
constant) in the CONFIG_SPU_FS_64K_LS path.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [2/5] Cleanup management of kmem_caches for pagetables
From: David Gibson @ 2009-09-28 4:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <20090928043902.GA6302@yookeroo.seuss>
Currently we have a fair bit of rather fiddly code to manage the
various kmem_caches used to store page tables of various levels. We
generally have two caches holding some combination of PGD, PUD and PMD
tables, plus several more for the special hugepage pagetables.
This patch cleans this all up by taking a different approach. Rather
than the caches being designated as for PUDs or for hugeptes for 16M
pages, the caches are simply allocated to be a specific size. Thus
sharing of caches between different types/levels of pagetables happens
naturally. The pagetable size, where needed, is passed around encoded
in the same way as {PGD,PUD,PMD}_INDEX_SIZE; that is n where the
pagetable contains 2^n pointers.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
---
arch/powerpc/include/asm/pgalloc-64.h | 51 ++++++++++++++---------------
arch/powerpc/include/asm/pgalloc.h | 30 ++---------------
arch/powerpc/include/asm/pgtable-ppc64.h | 1
arch/powerpc/mm/hugetlbpage.c | 45 ++++++-------------------
arch/powerpc/mm/init_64.c | 54 ++++++++++++++++++-------------
arch/powerpc/mm/pgtable.c | 25 +++++++++-----
6 files changed, 92 insertions(+), 114 deletions(-)
Index: working-2.6/arch/powerpc/mm/init_64.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/init_64.c 2009-09-28 12:50:46.000000000 +1000
+++ working-2.6/arch/powerpc/mm/init_64.c 2009-09-28 14:19:03.000000000 +1000
@@ -119,30 +119,42 @@ static void pmd_ctor(void *addr)
memset(addr, 0, PMD_TABLE_SIZE);
}
-static const unsigned int pgtable_cache_size[2] = {
- PGD_TABLE_SIZE, PMD_TABLE_SIZE
-};
-static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
-#ifdef CONFIG_PPC_64K_PAGES
- "pgd_cache", "pmd_cache",
-#else
- "pgd_cache", "pud_pmd_cache",
-#endif /* CONFIG_PPC_64K_PAGES */
-};
-
-#ifdef CONFIG_HUGETLB_PAGE
-/* Hugepages need an extra cache per hugepagesize, initialized in
- * hugetlbpage.c. We can't put into the tables above, because HPAGE_SHIFT
- * is not compile time constant. */
-struct kmem_cache *pgtable_cache[ARRAY_SIZE(pgtable_cache_size)+MMU_PAGE_COUNT];
-#else
-struct kmem_cache *pgtable_cache[ARRAY_SIZE(pgtable_cache_size)];
-#endif
+struct kmem_cache *pgtable_cache[MAX_PGTABLE_INDEX_SIZE];
+
+void pgtable_cache_add(unsigned shift, void (*ctor)(void *))
+{
+ char *name;
+ unsigned long table_size = sizeof(void *) << shift;
+ unsigned long align = table_size;
+ /* When batching pgtable pointers for RCU freeing, we store
+ * the index size in the low bits. Table alignment must be
+ * big enough to fit it */
+ unsigned long minalign = MAX_PGTABLE_INDEX_SIZE + 1;
+ struct kmem_cache *new;
+
+ /* It would be nice if this was a BUILD_BUG_ON(), but at the
+ * moment, gcc doesn't seem to recognize is_power_of_2 as a
+ * constant expression, so so much for that. */
+ BUG_ON(!is_power_of_2(minalign));
+ BUG_ON((shift < 1) || (shift > MAX_PGTABLE_INDEX_SIZE));
+
+ if (PGT_CACHE(shift))
+ return; /* Already have a cache of this size */
+ align = max_t(unsigned long, align, minalign);
+ name = kasprintf(GFP_KERNEL, "pgtable-2^%d", shift);
+ new = kmem_cache_create(name, table_size, table_size, 0, ctor);
+ PGT_CACHE(shift) = new;
+ pr_debug("Allocated pgtable cache for order %d\n", shift);
+}
+
void pgtable_cache_init(void)
{
- pgtable_cache[0] = kmem_cache_create(pgtable_cache_name[0], PGD_TABLE_SIZE, PGD_TABLE_SIZE, SLAB_PANIC, pgd_ctor);
- pgtable_cache[1] = kmem_cache_create(pgtable_cache_name[1], PMD_TABLE_SIZE, PMD_TABLE_SIZE, SLAB_PANIC, pmd_ctor);
+ pgtable_cache_add(PGD_INDEX_SIZE, pgd_ctor);
+ pgtable_cache_add(PMD_INDEX_SIZE, pmd_ctor);
+ if (!PGT_CACHE(PGD_INDEX_SIZE) || !PGT_CACHE(PMD_INDEX_SIZE))
+ panic("Couldn't allocate pgtable caches");
+ BUG_ON(PUD_INDEX_SIZE && !PGT_CACHE(PUD_INDEX_SIZE));
}
#ifdef CONFIG_SPARSEMEM_VMEMMAP
Index: working-2.6/arch/powerpc/include/asm/pgalloc-64.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/pgalloc-64.h 2009-08-03 16:00:45.000000000 +1000
+++ working-2.6/arch/powerpc/include/asm/pgalloc-64.h 2009-09-28 13:53:42.000000000 +1000
@@ -11,27 +11,30 @@
#include <linux/cpumask.h>
#include <linux/percpu.h>
+/*
+ * This needs to be big enough to allow any pagetable sizes we need,
+ * but small enough to fit in the low bits of any page table pointer.
+ * In other words all pagetables, even tiny ones, must be aligned to
+ * allow at least enough low 0 bits to contain this value.
+ */
+#define MAX_PGTABLE_INDEX_SIZE 0xf
+
#ifndef CONFIG_PPC_SUBPAGE_PROT
static inline void subpage_prot_free(pgd_t *pgd) {}
#endif
extern struct kmem_cache *pgtable_cache[];
-
-#define PGD_CACHE_NUM 0
-#define PUD_CACHE_NUM 1
-#define PMD_CACHE_NUM 1
-#define HUGEPTE_CACHE_NUM 2
-#define PTE_NONCACHE_NUM 7 /* from GFP rather than kmem_cache */
+#define PGT_CACHE(shift) (pgtable_cache[(shift)-1])
static inline pgd_t *pgd_alloc(struct mm_struct *mm)
{
- return kmem_cache_alloc(pgtable_cache[PGD_CACHE_NUM], GFP_KERNEL);
+ return kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE), GFP_KERNEL);
}
static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
subpage_prot_free(pgd);
- kmem_cache_free(pgtable_cache[PGD_CACHE_NUM], pgd);
+ kmem_cache_free(PGT_CACHE(PGD_INDEX_SIZE), pgd);
}
#ifndef CONFIG_PPC_64K_PAGES
@@ -40,13 +43,13 @@ static inline void pgd_free(struct mm_st
static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return kmem_cache_alloc(pgtable_cache[PUD_CACHE_NUM],
+ return kmem_cache_alloc(PGT_CACHE(PUD_INDEX_SIZE),
GFP_KERNEL|__GFP_REPEAT);
}
static inline void pud_free(struct mm_struct *mm, pud_t *pud)
{
- kmem_cache_free(pgtable_cache[PUD_CACHE_NUM], pud);
+ kmem_cache_free(PGT_CACHE(PUD_INDEX_SIZE), pud);
}
static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
@@ -78,13 +81,13 @@ static inline void pmd_populate_kernel(s
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return kmem_cache_alloc(pgtable_cache[PMD_CACHE_NUM],
+ return kmem_cache_alloc(PGT_CACHE(PMD_INDEX_SIZE),
GFP_KERNEL|__GFP_REPEAT);
}
static inline void pmd_free(struct mm_struct *mm, pmd_t *pmd)
{
- kmem_cache_free(pgtable_cache[PMD_CACHE_NUM], pmd);
+ kmem_cache_free(PGT_CACHE(PMD_INDEX_SIZE), pmd);
}
static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
@@ -107,24 +110,22 @@ static inline pgtable_t pte_alloc_one(st
return page;
}
-static inline void pgtable_free(pgtable_free_t pgf)
+static inline void pgtable_free(void *table, unsigned index_size)
{
- void *p = (void *)(pgf.val & ~PGF_CACHENUM_MASK);
- int cachenum = pgf.val & PGF_CACHENUM_MASK;
-
- if (cachenum == PTE_NONCACHE_NUM)
- free_page((unsigned long)p);
- else
- kmem_cache_free(pgtable_cache[cachenum], p);
+ if (!index_size)
+ free_page((unsigned long)table);
+ else {
+ BUG_ON(index_size > MAX_PGTABLE_INDEX_SIZE);
+ kmem_cache_free(PGT_CACHE(index_size), table);
+ }
}
-#define __pmd_free_tlb(tlb, pmd,addr) \
- pgtable_free_tlb(tlb, pgtable_free_cache(pmd, \
- PMD_CACHE_NUM, PMD_TABLE_SIZE-1))
+#define __pmd_free_tlb(tlb, pmd, addr) \
+ pgtable_free_tlb(tlb, pmd, PMD_INDEX_SIZE)
#ifndef CONFIG_PPC_64K_PAGES
#define __pud_free_tlb(tlb, pud, addr) \
- pgtable_free_tlb(tlb, pgtable_free_cache(pud, \
- PUD_CACHE_NUM, PUD_TABLE_SIZE-1))
+ pgtable_free_tlb(tlb, pud, PUD_INDEX_SIZE)
+
#endif /* CONFIG_PPC_64K_PAGES */
#define check_pgt_cache() do { } while (0)
Index: working-2.6/arch/powerpc/include/asm/pgalloc.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/pgalloc.h 2009-08-14 16:07:54.000000000 +1000
+++ working-2.6/arch/powerpc/include/asm/pgalloc.h 2009-09-28 13:53:42.000000000 +1000
@@ -24,25 +24,6 @@ static inline void pte_free(struct mm_st
__free_page(ptepage);
}
-typedef struct pgtable_free {
- unsigned long val;
-} pgtable_free_t;
-
-/* This needs to be big enough to allow for MMU_PAGE_COUNT + 2 to be stored
- * and small enough to fit in the low bits of any naturally aligned page
- * table cache entry. Arbitrarily set to 0x1f, that should give us some
- * room to grow
- */
-#define PGF_CACHENUM_MASK 0x1f
-
-static inline pgtable_free_t pgtable_free_cache(void *p, int cachenum,
- unsigned long mask)
-{
- BUG_ON(cachenum > PGF_CACHENUM_MASK);
-
- return (pgtable_free_t){.val = ((unsigned long) p & ~mask) | cachenum};
-}
-
#ifdef CONFIG_PPC64
#include <asm/pgalloc-64.h>
#else
@@ -50,12 +31,12 @@ static inline pgtable_free_t pgtable_fre
#endif
#ifdef CONFIG_SMP
-extern void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf);
+extern void pgtable_free_tlb(struct mmu_gather *tlb, void *table, unsigned shift);
extern void pte_free_finish(void);
#else /* CONFIG_SMP */
-static inline void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
+static inline void pgtable_free_tlb(struct mmu_gather *tlb, void *table, unsigned shift)
{
- pgtable_free(pgf);
+ pgtable_free(table, shift);
}
static inline void pte_free_finish(void) { }
#endif /* !CONFIG_SMP */
@@ -63,12 +44,9 @@ static inline void pte_free_finish(void)
static inline void __pte_free_tlb(struct mmu_gather *tlb, struct page *ptepage,
unsigned long address)
{
- pgtable_free_t pgf = pgtable_free_cache(page_address(ptepage),
- PTE_NONCACHE_NUM,
- PTE_TABLE_SIZE-1);
tlb_flush_pgtable(tlb, address);
pgtable_page_dtor(ptepage);
- pgtable_free_tlb(tlb, pgf);
+ pgtable_free_tlb(tlb, page_address(ptepage), 0);
}
#endif /* __KERNEL__ */
Index: working-2.6/arch/powerpc/mm/pgtable.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/pgtable.c 2009-08-28 13:46:31.000000000 +1000
+++ working-2.6/arch/powerpc/mm/pgtable.c 2009-09-28 13:53:42.000000000 +1000
@@ -47,12 +47,12 @@ struct pte_freelist_batch
{
struct rcu_head rcu;
unsigned int index;
- pgtable_free_t tables[0];
+ unsigned long tables[0];
};
#define PTE_FREELIST_SIZE \
((PAGE_SIZE - sizeof(struct pte_freelist_batch)) \
- / sizeof(pgtable_free_t))
+ / sizeof(unsigned long))
static void pte_free_smp_sync(void *arg)
{
@@ -62,13 +62,13 @@ static void pte_free_smp_sync(void *arg)
/* This is only called when we are critically out of memory
* (and fail to get a page in pte_free_tlb).
*/
-static void pgtable_free_now(pgtable_free_t pgf)
+static void pgtable_free_now(void *table, unsigned shift)
{
pte_freelist_forced_free++;
smp_call_function(pte_free_smp_sync, NULL, 1);
- pgtable_free(pgf);
+ pgtable_free(table, shift);
}
static void pte_free_rcu_callback(struct rcu_head *head)
@@ -77,8 +77,12 @@ static void pte_free_rcu_callback(struct
container_of(head, struct pte_freelist_batch, rcu);
unsigned int i;
- for (i = 0; i < batch->index; i++)
- pgtable_free(batch->tables[i]);
+ for (i = 0; i < batch->index; i++) {
+ void *table = (void *)(batch->tables[i] & ~MAX_PGTABLE_INDEX_SIZE);
+ unsigned shift = batch->tables[i] & MAX_PGTABLE_INDEX_SIZE;
+
+ pgtable_free(table, shift);
+ }
free_page((unsigned long)batch);
}
@@ -89,25 +93,28 @@ static void pte_free_submit(struct pte_f
call_rcu(&batch->rcu, pte_free_rcu_callback);
}
-void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
+void pgtable_free_tlb(struct mmu_gather *tlb, void *table, unsigned shift)
{
/* This is safe since tlb_gather_mmu has disabled preemption */
struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
+ unsigned long pgf;
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpumask_equal(mm_cpumask(tlb->mm), cpumask_of(smp_processor_id()))){
- pgtable_free(pgf);
+ pgtable_free(table, shift);
return;
}
if (*batchp == NULL) {
*batchp = (struct pte_freelist_batch *)__get_free_page(GFP_ATOMIC);
if (*batchp == NULL) {
- pgtable_free_now(pgf);
+ pgtable_free_now(table, shift);
return;
}
(*batchp)->index = 0;
}
+ BUG_ON(shift > MAX_PGTABLE_INDEX_SIZE);
+ pgf = (unsigned long)table | (shift - 1);
(*batchp)->tables[(*batchp)->index++] = pgf;
if ((*batchp)->index == PTE_FREELIST_SIZE) {
pte_free_submit(*batchp);
Index: working-2.6/arch/powerpc/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/hugetlbpage.c 2009-09-28 13:53:42.000000000 +1000
+++ working-2.6/arch/powerpc/mm/hugetlbpage.c 2009-09-28 14:17:38.000000000 +1000
@@ -43,26 +43,14 @@ static unsigned nr_gpages;
unsigned int mmu_huge_psizes[MMU_PAGE_COUNT] = { }; /* initialize all to 0 */
#define hugepte_shift mmu_huge_psizes
-#define PTRS_PER_HUGEPTE(psize) (1 << hugepte_shift[psize])
-#define HUGEPTE_TABLE_SIZE(psize) (sizeof(pte_t) << hugepte_shift[psize])
+#define HUGEPTE_INDEX_SIZE(psize) (mmu_huge_psizes[(psize)])
+#define PTRS_PER_HUGEPTE(psize) (1 << mmu_huge_psizes[psize])
#define HUGEPD_SHIFT(psize) (mmu_psize_to_shift(psize) \
- + hugepte_shift[psize])
+ + HUGEPTE_INDEX_SIZE(psize))
#define HUGEPD_SIZE(psize) (1UL << HUGEPD_SHIFT(psize))
#define HUGEPD_MASK(psize) (~(HUGEPD_SIZE(psize)-1))
-/* Subtract one from array size because we don't need a cache for 4K since
- * is not a huge page size */
-#define HUGE_PGTABLE_INDEX(psize) (HUGEPTE_CACHE_NUM + psize - 1)
-#define HUGEPTE_CACHE_NAME(psize) (huge_pgtable_cache_name[psize])
-
-static const char *huge_pgtable_cache_name[MMU_PAGE_COUNT] = {
- [MMU_PAGE_64K] = "hugepte_cache_64K",
- [MMU_PAGE_1M] = "hugepte_cache_1M",
- [MMU_PAGE_16M] = "hugepte_cache_16M",
- [MMU_PAGE_16G] = "hugepte_cache_16G",
-};
-
/* Flag to mark huge PD pointers. This means pmd_bad() and pud_bad()
* will choke on pointers to hugepte tables, which is handy for
* catching screwups early. */
@@ -114,15 +102,15 @@ static inline pte_t *hugepte_offset(huge
static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
unsigned long address, unsigned int psize)
{
- pte_t *new = kmem_cache_zalloc(pgtable_cache[HUGE_PGTABLE_INDEX(psize)],
- GFP_KERNEL|__GFP_REPEAT);
+ pte_t *new = kmem_cache_zalloc(PGT_CACHE(hugepte_shift[psize]),
+ GFP_KERNEL|__GFP_REPEAT);
if (! new)
return -ENOMEM;
spin_lock(&mm->page_table_lock);
if (!hugepd_none(*hpdp))
- kmem_cache_free(pgtable_cache[HUGE_PGTABLE_INDEX(psize)], new);
+ kmem_cache_free(PGT_CACHE(hugepte_shift[psize]), new);
else
hpdp->pd = (unsigned long)new | HUGEPD_OK;
spin_unlock(&mm->page_table_lock);
@@ -271,9 +259,7 @@ static void free_hugepte_range(struct mm
hpdp->pd = 0;
tlb->need_flush = 1;
- pgtable_free_tlb(tlb, pgtable_free_cache(hugepte,
- HUGEPTE_CACHE_NUM+psize-1,
- PGF_CACHENUM_MASK));
+ pgtable_free_tlb(tlb, hugepte, hugepte_shift[psize]);
}
static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
@@ -698,8 +684,6 @@ static void __init set_huge_psize(int ps
if (mmu_huge_psizes[psize] ||
mmu_psize_defs[psize].shift == PAGE_SHIFT)
return;
- if (WARN_ON(HUGEPTE_CACHE_NAME(psize) == NULL))
- return;
hugetlb_add_hstate(mmu_psize_defs[psize].shift - PAGE_SHIFT);
switch (mmu_psize_defs[psize].shift) {
@@ -769,16 +753,11 @@ static int __init hugetlbpage_init(void)
for (psize = 0; psize < MMU_PAGE_COUNT; ++psize) {
if (mmu_huge_psizes[psize]) {
- pgtable_cache[HUGE_PGTABLE_INDEX(psize)] =
- kmem_cache_create(
- HUGEPTE_CACHE_NAME(psize),
- HUGEPTE_TABLE_SIZE(psize),
- HUGEPTE_TABLE_SIZE(psize),
- 0,
- NULL);
- if (!pgtable_cache[HUGE_PGTABLE_INDEX(psize)])
- panic("hugetlbpage_init(): could not create %s"\
- "\n", HUGEPTE_CACHE_NAME(psize));
+ pgtable_cache_add(hugepte_shift[psize], NULL);
+ if (!PGT_CACHE(hugepte_shift[psize]))
+ panic("hugetlbpage_init(): could not create "
+ "pgtable cache for %d bit pagesize\n",
+ mmu_psize_to_shift(psize));
}
}
Index: working-2.6/arch/powerpc/include/asm/pgtable-ppc64.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/pgtable-ppc64.h 2009-08-28 13:46:31.000000000 +1000
+++ working-2.6/arch/powerpc/include/asm/pgtable-ppc64.h 2009-09-28 14:17:38.000000000 +1000
@@ -354,6 +354,7 @@ static inline void __ptep_set_access_fla
#define pgoff_to_pte(off) ((pte_t) {((off) << PTE_RPN_SHIFT)|_PAGE_FILE})
#define PTE_FILE_MAX_BITS (BITS_PER_LONG - PTE_RPN_SHIFT)
+void pgtable_cache_add(unsigned shift, void (*ctor)(void *));
void pgtable_cache_init(void);
/*
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox