* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Geert Uytterhoeven @ 2009-02-24 18:01 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev, Andrew Morton,
linux-ext4
In-Reply-To: <18850.31567.212454.514549@cargo.ozlabs.ibm.com>
On Mon, 23 Feb 2009, Paul Mackerras wrote:
> Andrew Morton writes:
> > It looks like we died in ext3_xattr_block_get():
> >
> > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> > size);
> >
> > Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> > corrupted and this snuck through the defenses.
> >
> > I also wonder if there is enough info in that trace for a ppc person to
> > be able to determine whether the faulting address is in the source or
> > destination of the memcpy() (please)?
>
> It appears to have faulted on a load, implicating the source. The
> address being referenced (0xc00000003f380000) doesn't look
> outlandish. I wonder if this kernel has CONFIG_DEBUG_PAGEALLOC turned
> on, and what page size is selected?
I'm seeing a similar thing on PS3, but not in ext3. During early userspace
setup (udevd), it crashes accessing a 0xc00* address in:
| NIP setup+0x20/0x130
| LR copy_user_page+0x18/0x6c
| Call trace:
| do_wp_page+0x5b4/0x89c
| do_page_fault+0x3a8/0x58c
| handle_page_fault+0x20/0x5c
I have CONFIG_DEBUG_PAGEALLOC=y. If I disable it, the system boots fine.
If needed, I can probably bisect this tomorrow. It definitely didn't happen in
2.6.29-rc5.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
From: Alessandro Zummo @ 2009-02-24 18:37 UTC (permalink / raw)
To: rtc-linux
Cc: Richard Zidlicky, linux-parisc, Linux Kernel Development, David,
Kyle McMartin, Linux/PPC Development, Linux/m68k,
Geert.Uytterhoeven, Woodhouse
In-Reply-To: <alpine.LRH.2.00.0902241848500.544@vixen.sonytel.be>
On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> On Mon, 23
> >
> > I'd start writing a working driver and then see how we should eventually
> > adapt the rtc subsystem to cope with your needs.
>
> OK, so here's a first example: rtc-ps3.
>
> Note that this single patch adds 100+ lines of code, while my previous patch
> series removed 500+ lines of code, while solving the autoloading problem for
> several ppc and m68k platforms.
This patch has a much cleaner approach, imho.
> Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
> class drivers would add ca. 100+ lines of code for each individual driver.
How different are all of those boards? It's simply a matter
of parameters and offsets? can we group them somehow?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [PATCH/RFC 0/5] Generic RTC class driver
From: Helge Deller @ 2009-02-24 18:46 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Alessandro Zummo, Richard Zidlicky, rtc-linux, linux-parisc,
linux-kernel, Kyle McMartin, linuxppc-dev, linux-m68k,
David Woodhouse, dann frazier
In-Reply-To: <1235144809-32468-1-git-send-email-Geert.Uytterhoeven@sonycom.com>
Geert Uytterhoeven wrote:
> I've been looking into problems with auto-loading the RTC driver on PPC (more
> specifically on PS3):
> - The recent "rtc-ppc" RTC class driver is not autoloaded by udev because
> it's an old style platform driver that contains its own platform device.
> - The alternative old "genrtc" driver is autoloaded on non-udev systems only
> because it contains the module alias char-major-10-135. However, it's not
> a new-style RTC class driver.
>
> Fortunately there already exists a generic RTC class driver: "rtc-parisc".
> Despite it's name, it's platform-independent, as it's build on top of the RTC
> abstraction used by "genrtc".
>
> This patch series
> - adds a missing module alias to rtc-parisc,
> - renames rtc-parisc to rtc-generic,
> - converts the architectures that currently have CONFIG_GEN_RTC enabled in
> their defconfig (m68k, parisc, powerpc) to rtc-generic,
> - removes the obsolete rtc-ppc driver,
> - removes the old genrtc driver.
>
> Note that genrtc may be used on other archictectures as well: at least alpha
> has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow
> genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa).
>
> Furthermore genrtc and rtc-generic are not 100% userspace compatible:
> - /dev/rtc provided by genrtc uses a misc character device (10:135),
> - /dev/rtc provided by rtc-generic uses a dynamic character device.
>
> So perhaps we don't want to kill gen-rtc yet?
>
> Any comments are welcomed!
Hi Geert,
FYI, I didn't followed any discussions or changes around the RTC drivers for parisc,
but Dann Frazier did some work on the parisc RTC driver as well.
His patches were merged (not upstream yet!) in Kyle's "rtc-parisc" branch at:
http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc
Not sure if they conflict (or are in sync) with your patches...
Helge
^ permalink raw reply
* Re: Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
From: Michael Bergandi @ 2009-02-24 18:55 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev, Eric Cottrell
In-Reply-To: <49A3EBFF.4030906@aimvalley.nl>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
Hi guys,
I have the Rev B board and I have it working quite well. I'll share what I
have
discovered so far.
In Eric's case, the board seems suspect. There is already a Rev C of this
board, but
I am not sure if it is actually available yet. You may want to check on
that.
Regarding U-Boot, mine shipped with v. 1.3.0. The LTIB provided dts files
follow
the original dts format. There is a new dts spec and if you ever intend to
use
a mainline kernel, you will need to use the newer dts provided in the kernel
source. Did I mention this board has at least basic support in 2.6.28 :). I
have
not determined the extent of the support though.
I have successfully used the provided U-Boot v1.3.0 to boot a 2.6.28 kernel
with
the dts-v1 device tree. Hence, I hope that will clear your speculation about
the
device tree being the problem.
I have seen the same problem that you guys have seen where U-Boot gets to
the "Uncompressing kernel ..." then reboots. This happened to me when I
passed the wrong device tree .dtb. I have also had this happen if I made
a change to the kernel config. I haven't been able to determine what exactly
that I changed that caused the problem though.
Also, if you are feeling adventurous, you can also get the latest U-Boot.
There
is a specifc branch for this board:
$ git clone git://git.denx.de/u-boot-mpc83xx.git
I haven't attempted this since I don't currently have a probe to recovery a
bad boot loader flash.
Hope this helps,
Mike
[-- Attachment #2: Type: text/html, Size: 1680 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
From: Serge E. Hallyn @ 2009-02-24 19:58 UTC (permalink / raw)
To: Nathan Lynch; +Cc: containers, Oren Laadan, linuxppc-dev
In-Reply-To: <20090217010355.58afd5cf@thinkcentre.lan>
Quoting Nathan Lynch (ntl@pobox.com):
> Nathan Lynch <ntl@pobox.com> wrote:
> >
> > Oren Laadan wrote:
> > >
> > > Nathan Lynch wrote:
> > > >
> > > > What doesn't work:
> > > > * restarting a 32-bit task from a 64-bit task and vice versa
> > >
> > > Is there a test to bail if we attempt to checkpoint such tasks ?
> >
> > No, but I'll add one if it looks too hard to fix for the next round.
>
> Unfortunately, adding a check for this is hard.
>
> The "point of no return" in the restart path is cr_read_mm, which tears
> down current's address space. cr_read_mm runs way before cr_read_cpu,
> which is the only restart method I've implemented for powerpc so far.
> So, checking for this condition in cr_read_cpu is too late if I want
> restart(2) to return an error and leave the caller's memory map
> intact. (And I do want this: restart should be as robust as execve.)
>
> Well okay then, cr_read_head_arch seems to be the right place in the
> restart sequence for the architecture code to handle this. However,
> cr_write_head_arch (which produces the buffer that cr_read_head_arch
> consumes) is not provided a reference to the task to be checkpointed,
> nor can it assume that it's operating on current. I need a reference
> to a task before I can determine whether it's running in 32- or 64-bit
> mode, or using the FPU, Altivec, SPE, whatever.
>
> In any case, mixing 32- and 64-bit tasks across restart is something I
> eventually want to support, not reject. But the problem I've outlined
> applies to FPU state and vector extensions (VMX, SPE), as well as
> sanity-checking debug register (DABR) contents. We'll need to be able
> to error out gracefully from restart when a checkpoint image specifies a
> feature unsupported by the current kernel or hardware. But I don't see
> how to do it with the current architecture. Am I missing something?
I suspect I can guess the response to this suggestion, but how about we
accept that if sys_restart() fails due to something like this, the
task is lost and can't exit gracefully? The end-user can then run
a user-space program to run through the checkpoint image ahead of
time (if they want) and verify whether restart can be expected to
succeed on the current hardware and os version?
If a minor difference is detected, the user-space program might
simply rewrite (a copy of) the checkpoint image into one which can
in fact succeed.
-serge
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
From: Nathan Lynch @ 2009-02-24 21:11 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: containers, Oren Laadan, linuxppc-dev
In-Reply-To: <20090224195826.GA25909@us.ibm.com>
On Tue, 24 Feb 2009 13:58:26 -0600
"Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Nathan Lynch (ntl@pobox.com):
> > Nathan Lynch <ntl@pobox.com> wrote:
> > >
> > > Oren Laadan wrote:
> > > >
> > > > Nathan Lynch wrote:
> > > > >
> > > > > What doesn't work:
> > > > > * restarting a 32-bit task from a 64-bit task and vice versa
> > > >
> > > > Is there a test to bail if we attempt to checkpoint such tasks ?
> > >
> > > No, but I'll add one if it looks too hard to fix for the next round.
> >
> > Unfortunately, adding a check for this is hard.
> >
> > The "point of no return" in the restart path is cr_read_mm, which tears
> > down current's address space. cr_read_mm runs way before cr_read_cpu,
> > which is the only restart method I've implemented for powerpc so far.
> > So, checking for this condition in cr_read_cpu is too late if I want
> > restart(2) to return an error and leave the caller's memory map
> > intact. (And I do want this: restart should be as robust as execve.)
> >
> > Well okay then, cr_read_head_arch seems to be the right place in the
> > restart sequence for the architecture code to handle this. However,
> > cr_write_head_arch (which produces the buffer that cr_read_head_arch
> > consumes) is not provided a reference to the task to be checkpointed,
> > nor can it assume that it's operating on current. I need a reference
> > to a task before I can determine whether it's running in 32- or 64-bit
> > mode, or using the FPU, Altivec, SPE, whatever.
> >
> > In any case, mixing 32- and 64-bit tasks across restart is something I
> > eventually want to support, not reject. But the problem I've outlined
> > applies to FPU state and vector extensions (VMX, SPE), as well as
> > sanity-checking debug register (DABR) contents. We'll need to be able
> > to error out gracefully from restart when a checkpoint image specifies a
> > feature unsupported by the current kernel or hardware. But I don't see
> > how to do it with the current architecture. Am I missing something?
>
> I suspect I can guess the response to this suggestion, but how about we
> accept that if sys_restart() fails due to something like this, the
> task is lost and can't exit gracefully?
In the short term it might be necessary. But the restart code should
forcibly kill the task instead of returning an error back up to
userspace in this case. Once the memory map of the process has been
altered, there is no point in allowing it to continue (and likely dump
a useless core). Btw, this failure mode seems to apply when
cr_read_files() fails, too...
But in the long term, things need to be more robust (e.g. restart(2)
returns ENOEXEC without messing with current->mm). I think it's worth
looking at how execve operates... if I understand correctly, it sets up
a new mm_struct disconnected from the current task and activates it at
the last moment.
^ permalink raw reply
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
From: David Woodhouse @ 2009-02-24 21:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Alessandro Zummo, Richard Zidlicky, rtc-linux, linux-parisc,
David, Linux Kernel Development, Kyle McMartin,
Linux/PPC Development, Linux/m68k
In-Reply-To: <alpine.LRH.2.00.0902231319170.22762@vixen.sonytel.be>
On Mon, 2009-02-23 at 13:34 +0100, Geert Uytterhoeven wrote:
> > my opinion on this kind of stuff is that I want to avoid the layering
> > of implementations under the rtc subsystem. I'd rather prefer that each
> > rtc device had its own driver.
> >
> > I've made error in the past, by accepting such kind of drivers, and
> > would like to avoid that it happens again.
>
> So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
That's the ideal... although did we get NTP sync working again yet?
The rtc-ppc driver was intended as a short-term workaround so that we
can enable the generic RTC class (which was required for PA Semi
Electra, iirc), and still have stuff work on other platforms.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
From: Alessandro Zummo @ 2009-02-24 22:11 UTC (permalink / raw)
To: David Woodhouse
Cc: Richard Zidlicky, rtc-linux, linux-parisc, David,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Linux/m68k, Geert Uytterhoeven
In-Reply-To: <1235511327.18632.73.camel@macbook.infradead.org>
On Wed, 25 Feb 2009 06:35:27 +0900
David Woodhouse <dwmw2@infradead.org> wrote:
> > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> > mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> > RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
>
> That's the ideal... although did we get NTP sync working again yet?
not yet. we're close but I've been very busy :(
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
From: David Woodhouse @ 2009-02-24 22:32 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Richard Zidlicky, rtc-linux, linux-parisc, David,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Linux/m68k, Geert Uytterhoeven
In-Reply-To: <20090224231154.60ba18d6@i1501.lan.towertech.it>
On Tue, 2009-02-24 at 23:11 +0100, Alessandro Zummo wrote:
> On Wed, 25 Feb 2009 06:35:27 +0900
> David Woodhouse <dwmw2@infradead.org> wrote:
>
> > > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> > > mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> > > RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
> >
> > That's the ideal... although did we get NTP sync working again yet?
>
> not yet. we're close but I've been very busy :(
I know the feeling.
Once that's working, we can convert individual PPC platforms over,
removing the routines from the ppc_md and creating a generic RTC driver
instead. PA Electra is already like that -- because it wasn't a
regression there to have broken NTP sync. But the others need to wait.
Eventually, we ought to be able to drop the RTC functions from the
ppc_md -- and presumably the equivalent for other architectures too.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4
From: Roland McGrath @ 2009-02-24 23:36 UTC (permalink / raw)
To: kyle; +Cc: linuxppc-dev, aoliva, linux-kernel, kyle
In-Reply-To: <20090224065112.GA6690@bombadil.infradead.org>
The patch is right though the log entry and comment are perhaps misleading.
The effect of the patch is to restore the compiler behavior to what it was
before. What it was before includes cases of producing .eh_frame and cases
of not producing it. The default behavior of a gcc-4.4 that was built
against new enough binutils has diverged, so that some situations that
before produced no .eh_frame now do produce one. -fno-dwarf2-cfi-asm
tells gcc to behave like it did before (which is also how 4.4 behaves when
built against an old enough binutils).
Thanks,
Roland
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
From: Brad Boyer @ 2009-02-25 1:14 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Richard Zidlicky, rtc-linux, linux-parisc, David,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Linux/m68k, Geert.Uytterhoeven, Woodhouse
In-Reply-To: <20090224193708.5f8be86c@i1501.lan.towertech.it>
On Tue, Feb 24, 2009 at 07:37:08PM +0100, Alessandro Zummo wrote:
> On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
> > class drivers would add ca. 100+ lines of code for each individual driver.
>
> How different are all of those boards? It's simply a matter
> of parameters and offsets? can we group them somehow?
I imagine we could cut down the numbers somewhat with clever code sharing,
but it's still going to be a fairly large number. I don't know all the
embedded boards, but just with all the Macintosh models there are at
least three and maybe four drastically different methods of RTC access,
and all of them are directly tied to some chip that does something else
completely unrelated. For one of them we don't even have a driver at the
moment. They also are all custom chips that wouldn't be used anywhere
else. The other thing we need to keep in mind is that if we do it right
we can share drivers across m68k and powerpc in some cases. I imagine
some of the embedded powerpc boards are using chips that are common in
other architectures as well.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Mark Nelson @ 2009-02-25 1:20 UTC (permalink / raw)
To: Jan Kara
Cc: Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev, Paul Mackerras,
Andrew Morton, linux-ext4
In-Reply-To: <20090224155119.GC22108@duck.suse.cz>
On Wed, 25 Feb 2009 02:51:20 am Jan Kara wrote:
> Hello,
>
> On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
> > Jan Kara wrote:
> >> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> >> somehow got beyond end of the page referenced by bh->b_data. So it means
> >> that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> >> ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> >> particular checks whether e_value_offs + e_value_size isn't greater than
> >> bh->b_size. So I see no way how memcpy can get beyond end of the page.
> >> Sachin, is the problem reproducible? If yes, can you send us contents
> >>
> > Yes, i am able to recreate this problem easily. As i had mentioned if the
> > earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
> > i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
> > without any problem.
> >
> >> of the page just before the faulting address (i.e., for current fault it
> >> would be 0xc00000003f370000-0xc00000003f37ffff). As far as I can
> >> remember powerpc monitor could dump it.
> >>
> > Here is the page dump. This time it crashed while accessing address
> > 0xc00000002d670000.
> Thanks for the dump.
>
> > Unable to handle kernel paging request for data at address 0xc0000
> > 0002d670000
> > Faulting instruction address: 0xc000000000039574
> > cpu 0x1: Vector: 300 (Data Access) at [c00000004288b0b0]
> > pc: c000000000039574: .memcpy+0x74/0x244
> > lr: c0000000001b497c: .ext3_xattr_get+0x288/0x2f4
> > sp: c00000004288b330
> > msr: 8000000000009032
> >
> > 1:mon> d 0xc00000002d660000
> > ............................... <SNIP> ...............................
> >
> > c00000002d66efd0 0000000000000000 0000000000000000 |................|
> > c00000002d66efe0 0000000000000000 0000000000000000 |................|
> > c00000002d66eff0 0000000000000000 0000000000000000 |................|
> > c00000002d66f000 000002ea00040000 01000000e200d20a |................|
> > c00000002d66f010 0000000000000000 0000000000000000 |................|
> > c00000002d66f020 0706e40f00000000 1b000000e200d20a |................|
> > c00000002d66f030 73656c696e757800 0000000000000000 |selinux.........|
> > c00000002d66f040 0000000000000000 0000000000000000 |................|
> > c00000002d66f050 0000000000000000 0000000000000000 |................|
> > c00000002d66f060 0000000000000000 0000000000000000 |................|
> >
> > ............................... <SNIP> ...............................
> >
> > c00000002d66ff60 0000000000000000 0000000000000000 |................|
> > c00000002d66ff70 0000000000000000 0000000000000000 |................|
> > c00000002d66ff80 0000000000000000 0000000000000000 |................|
> > c00000002d66ff90 0000000000000000 0000000000000000 |................|
> > c00000002d66ffa0 0000000000000000 0000000000000000 |................|
> > c00000002d66ffb0 0000000000000000 0000000000000000 |................|
> > c00000002d66ffc0 0000000000000000 0000000000000000 |................|
> > c00000002d66ffd0 0000000000000000 0000000000000000 |................|
> > c00000002d66ffe0 0000000073797374 656d5f753a6f626a |....system_u:obj|
> > c00000002d66fff0 6563745f723a7573 725f743a73300000 |ect_r:usr_t:s0..|
> > c00000002d670000 **************** **************** | |
> > 1:mon> r
> > R00 = 000000000000e40f R16 = 000000000000005d
> > R01 = c00000004288b330 R17 = 0000000000000000
> > R02 = c0000000009f59b8 R18 = 00000000fffbfe9e
> > R03 = c000000044aa34a0 R19 = 0000000010042638
> > R04 = c00000002d66fff4 R20 = 0000000010041610
> > R05 = 0000000000000003 R21 = 00000000000000ff
> > R06 = 0000000000000000 R22 = 0000000000000006
> > R07 = 0000000000000001 R23 = c0000000007d27c1
> > R08 = 723a7573725f743a R24 = c00000002c0cd758
> > R09 = 3a6f626a6563745f R25 = c000000044aa3488
> > R10 = c00000000017b43c R26 = c00000002c0cd6f0
> > R11 = c00000002d66f020 R27 = c00000002c0cd860
> > R12 = d0000000023c14b0 R28 = c00000002c0b0840
> > R13 = c000000000a93680 R29 = 000000000000001b
> > R14 = 00000000000041ed R30 = c0000000009880b0
> > R15 = 0000000010040000 R31 = ffffffffffffffde
> > pc = c000000000039574 .memcpy+0x74/0x244
> > lr = c0000000001b497c .ext3_xattr_get+0x288/0x2f4
> > msr = 8000000000009032 cr = 4400044b
> > ctr = 0000000000000000 xer = 0000000020000001 trap = 300
> > dar = c00000002d670000 dsisr = 40000000
> > 1:mon> zr
> >
> >> BTW, I suppose you use 4KB blocksize on the filesystem, right?
> >>
> > Yes.
> >
> > dumpe2fs /dev/sda3 | grep -i "block size" dumpe2fs 1.39 (29-May-2006)
> > Block size: 4096
> OK. The xattr block causing oops is completely correct. To me it seems
> more like some problem in powerpc memcpy() (I saw there went some changes
> into in in the end of December) - we call it to copy 27 bytes from
> address 0xc00000002d66ffe4 (which is one byte before end of the page).
> Could some of the powerpc guys have a look whether this could be the case?
> I'm not quite fluent in the powerpc assembly so it would take me ages ;).
You're right - it's a problem with the 64bit powerpc memcpy(). And the brown
paper bag is all mine (commit 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556). On
Power6 and Cell we're doing a load double that goes beyond the source size
we were given to copy. I'll see if I can find a nice way of fixing this up,
if not then I'll ask Ben to revert.
Sorry about the goose chase!
Mark
^ permalink raw reply
* Freescale MPC8313 & SPI
From: Mark Bishop @ 2009-02-25 1:19 UTC (permalink / raw)
To: linuxppc-dev
I am trying to understand more about how to talk to different spi
chips using the MPC8313. The documentation that comes with the
development board is really lacking and I am relying on the
/usr/src/linux/Documentaion/spi. However, I still can't seem to
answer my questions.
1) Which device do I open up to talk to the bus. I would use
something like /dev/ttyS0 for a serial port, and I assume it would be
/dev/spidev.0 and I would have to make it manually using mknod - but
what ties the /dev/spidev.0 to the actual chip driver? Is there
something I have to do in addition to mknod?
2) I would be looking for a few examples on how to talk to a SPI bus
as well. I've looked at spidev_test.c and I would like to see another
example or two.
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Mark Nelson @ 2009-02-25 1:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jan Kara, Mel Gorman, linux-kernel, Paul Mackerras,
Geert Uytterhoeven, Andrew Morton, linux-ext4
In-Reply-To: <alpine.LRH.2.00.0902241857170.544@vixen.sonytel.be>
On Wed, 25 Feb 2009 05:01:59 am Geert Uytterhoeven wrote:
> On Mon, 23 Feb 2009, Paul Mackerras wrote:
> > Andrew Morton writes:
> > > It looks like we died in ext3_xattr_block_get():
> > >
> > > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> > > size);
> > >
> > > Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> > > corrupted and this snuck through the defenses.
> > >
> > > I also wonder if there is enough info in that trace for a ppc person to
> > > be able to determine whether the faulting address is in the source or
> > > destination of the memcpy() (please)?
> >
> > It appears to have faulted on a load, implicating the source. The
> > address being referenced (0xc00000003f380000) doesn't look
> > outlandish. I wonder if this kernel has CONFIG_DEBUG_PAGEALLOC turned
> > on, and what page size is selected?
>
> I'm seeing a similar thing on PS3, but not in ext3. During early userspace
> setup (udevd), it crashes accessing a 0xc00* address in:
>
> | NIP setup+0x20/0x130
> | LR copy_user_page+0x18/0x6c
> | Call trace:
> | do_wp_page+0x5b4/0x89c
> | do_page_fault+0x3a8/0x58c
> | handle_page_fault+0x20/0x5c
>
> I have CONFIG_DEBUG_PAGEALLOC=y. If I disable it, the system boots fine.
>
> If needed, I can probably bisect this tomorrow. It definitely didn't happen in
> 2.6.29-rc5.
No need to bisect - it was 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556, my
commit that "optimised" 64bit memcpy() for Power6 and Cell.
The bug was in -rc1, but if your copies were 8-byte aligned with respect
to the source the problem wouldn't have been seen... Could this have
been why you didn't see it in -rc5?
I'll work on a fix now.
Thanks!
Mark
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4
From: Sam Ravnborg @ 2009-02-25 5:47 UTC (permalink / raw)
To: Kyle McMartin; +Cc: linuxppc-dev, aoliva, linux-kernel, roland, kyle
In-Reply-To: <20090224065112.GA6690@bombadil.infradead.org>
On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
> From: Kyle McMartin <kyle@redhat.com>
>
> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> sections, which are, for the kernel, fairly pointless. Additionally, on
> ppc64 this generates a relocation format which the kernel module loader
> does not currently support (R_PPC64_REL32.)
>
> Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
> .eh_frame section from being generated.
>
> These seem to be used for unwinding, but it doesn't look like we
> currently use them anywhere. (In fact, we explicitly dump them in the
> x86_64 linker script.)
>
> If these .eh_frame sections are eventually used, adding a per-arch
> CONFIG_WANT_UNWIND check would be trivial.
>
> (This was reported against Fedora, which appears to be the only distro
> doing any building against gcc-4.4 at present: RH bz#486545.)
>
> Signed-off-by: Kyle McMartin <kyle@redhat.com>
> Cc: roland@redhat.com
> Cc: aoliva@redhat.com
Kyle - can you resend wit an updated changelog reflecting the comments
from Roland and Alexandre.
I got it wrong when reading the above - so chances are others does too.
Thanks,
Sam
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4
From: Kyle McMartin @ 2009-02-25 5:46 UTC (permalink / raw)
To: Sam Ravnborg
Cc: kyle, Kyle McMartin, linux-kernel, linuxppc-dev, aoliva, roland
In-Reply-To: <20090225054707.GA20364@uranus.ravnborg.org>
On Wed, Feb 25, 2009 at 06:47:07AM +0100, Sam Ravnborg wrote:
> > On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> > sections, which are, for the kernel, fairly pointless. Additionally, on
> > ppc64 this generates a relocation format which the kernel module loader
> > does not currently support (R_PPC64_REL32.)
> >
> > Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
> > .eh_frame section from being generated.
> >
> > These seem to be used for unwinding, but it doesn't look like we
> > currently use them anywhere. (In fact, we explicitly dump them in the
> > x86_64 linker script.)
> >
> > If these .eh_frame sections are eventually used, adding a per-arch
> > CONFIG_WANT_UNWIND check would be trivial.
> >
> > (This was reported against Fedora, which appears to be the only distro
> > doing any building against gcc-4.4 at present: RH bz#486545.)
> >
> > Signed-off-by: Kyle McMartin <kyle@redhat.com>
> > Cc: roland@redhat.com
> > Cc: aoliva@redhat.com
>
> Kyle - can you resend wit an updated changelog reflecting the comments
> from Roland and Alexandre.
>
> I got it wrong when reading the above - so chances are others does too.
>
Yes, certainly. My apologies, I let my frustration leak through a little
into the changelog. :)
regards, Kyle
^ permalink raw reply
* [PATCH] powerpc: Split the various pgtable-* headers based on MMU type (v2)
From: Benjamin Herrenschmidt @ 2009-02-25 6:25 UTC (permalink / raw)
To: linuxppc-dev
This patch moves the definition of the PTE format for each MMU type
to separate files instead of all in one file. This improves overall
maintainability and will make it easier to add new types.
On 64-bit, additionally, I've separated the headers relative to the
format of the page table tree (3 vs. 4 levels for 64K vs 4K pages)
from the headers specific to the PTE format for hash based processors,
this will make it easier to add support for Book3 "E" 64-bit
implementations.
There are still some type-related ifdef's in the generic headers,
we might remove them in the long run, but this patch shouldn't result
in any code change, -hopefully- just definitions being moved around.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/pgtable-4k.h | 117 ---------
arch/powerpc/include/asm/pgtable-64k.h | 155 -------------
arch/powerpc/include/asm/pgtable-ppc32.h | 321 +--------------------------
arch/powerpc/include/asm/pgtable-ppc64-4k.h | 74 ++++++
arch/powerpc/include/asm/pgtable-ppc64-64k.h | 42 +++
arch/powerpc/include/asm/pgtable-ppc64.h | 87 ++++---
arch/powerpc/include/asm/pte-40x.h | 64 +++++
arch/powerpc/include/asm/pte-44x.h | 102 ++++++++
arch/powerpc/include/asm/pte-8xx.h | 64 +++++
arch/powerpc/include/asm/pte-fsl-booke.h | 46 +++
arch/powerpc/include/asm/pte-hash32.h | 49 ++++
arch/powerpc/include/asm/pte-hash64-4k.h | 20 +
arch/powerpc/include/asm/pte-hash64-64k.h | 115 +++++++++
arch/powerpc/include/asm/pte-hash64.h | 47 +++
14 files changed, 700 insertions(+), 603 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc32.h 2009-02-18 13:20:35.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc32.h 2009-02-25 16:47:11.000000000 +1100
@@ -19,55 +19,6 @@ extern int icache_44x_need_flush;
#endif /* __ASSEMBLY__ */
/*
- * The PowerPC MMU uses a hash table containing PTEs, together with
- * a set of 16 segment registers (on 32-bit implementations), to define
- * the virtual to physical address mapping.
- *
- * We use the hash table as an extended TLB, i.e. a cache of currently
- * active mappings. We maintain a two-level page table tree, much
- * like that used by the i386, for the sake of the Linux memory
- * management code. Low-level assembler code in hashtable.S
- * (procedure hash_page) is responsible for extracting ptes from the
- * tree and putting them into the hash table when necessary, and
- * updating the accessed and modified bits in the page table tree.
- */
-
-/*
- * The PowerPC MPC8xx uses a TLB with hardware assisted, software tablewalk.
- * We also use the two level tables, but we can put the real bits in them
- * needed for the TLB and tablewalk. These definitions require Mx_CTR.PPM = 0,
- * Mx_CTR.PPCS = 0, and MD_CTR.TWAM = 1. The level 2 descriptor has
- * additional page protection (when Mx_CTR.PPCS = 1) that allows TLB hit
- * based upon user/super access. The TLB does not have accessed nor write
- * protect. We assume that if the TLB get loaded with an entry it is
- * accessed, and overload the changed bit for write protect. We use
- * two bits in the software pte that are supposed to be set to zero in
- * the TLB entry (24 and 25) for these indicators. Although the level 1
- * descriptor contains the guarded and writethrough/copyback bits, we can
- * set these at the page level since they get copied from the Mx_TWC
- * register when the TLB entry is loaded. We will use bit 27 for guard, since
- * that is where it exists in the MD_TWC, and bit 26 for writethrough.
- * These will get masked from the level 2 descriptor at TLB load time, and
- * copied to the MD_TWC before it gets loaded.
- * Large page sizes added. We currently support two sizes, 4K and 8M.
- * This also allows a TLB hander optimization because we can directly
- * load the PMD into MD_TWC. The 8M pages are only used for kernel
- * mapping of well known areas. The PMD (PGD) entries contain control
- * flags in addition to the address, so care must be taken that the
- * software no longer assumes these are only pointers.
- */
-
-/*
- * At present, all PowerPC 400-class processors share a similar TLB
- * architecture. The instruction and data sides share a unified,
- * 64-entry, fully-associative TLB which is maintained totally under
- * software control. In addition, the instruction side has a
- * hardware-managed, 4-entry, fully-associative TLB which serves as a
- * first level to the shared TLB. These two TLBs are known as the UTLB
- * and ITLB, respectively (see "mmu.h" for definitions).
- */
-
-/*
* The normal case is that PTEs are 32-bits and we have a 1-page
* 1024-entry pgdir pointing to 1-page 1024-entry PTE pages. -- paulus
*
@@ -135,261 +86,25 @@ extern int icache_44x_need_flush;
*/
#if defined(CONFIG_40x)
-
-/* There are several potential gotchas here. The 40x hardware TLBLO
- field looks like this:
-
- 0 1 2 3 4 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31
- RPN..................... 0 0 EX WR ZSEL....... W I M G
-
- Where possible we make the Linux PTE bits match up with this
-
- - bits 20 and 21 must be cleared, because we use 4k pages (40x can
- support down to 1k pages), this is done in the TLBMiss exception
- handler.
- - We use only zones 0 (for kernel pages) and 1 (for user pages)
- of the 16 available. Bit 24-26 of the TLB are cleared in the TLB
- miss handler. Bit 27 is PAGE_USER, thus selecting the correct
- zone.
- - PRESENT *must* be in the bottom two bits because swap cache
- entries use the top 30 bits. Because 40x doesn't support SMP
- anyway, M is irrelevant so we borrow it for PAGE_PRESENT. Bit 30
- is cleared in the TLB miss handler before the TLB entry is loaded.
- - All other bits of the PTE are loaded into TLBLO without
- modification, leaving us only the bits 20, 21, 24, 25, 26, 30 for
- software PTE bits. We actually use use bits 21, 24, 25, and
- 30 respectively for the software bits: ACCESSED, DIRTY, RW, and
- PRESENT.
-*/
-
-/* Definitions for 40x embedded chips. */
-#define _PAGE_GUARDED 0x001 /* G: page is guarded from prefetch */
-#define _PAGE_FILE 0x001 /* when !present: nonlinear file mapping */
-#define _PAGE_PRESENT 0x002 /* software: PTE contains a translation */
-#define _PAGE_NO_CACHE 0x004 /* I: caching is inhibited */
-#define _PAGE_WRITETHRU 0x008 /* W: caching is write-through */
-#define _PAGE_USER 0x010 /* matches one of the zone permission bits */
-#define _PAGE_RW 0x040 /* software: Writes permitted */
-#define _PAGE_DIRTY 0x080 /* software: dirty page */
-#define _PAGE_HWWRITE 0x100 /* hardware: Dirty & RW, set in exception */
-#define _PAGE_HWEXEC 0x200 /* hardware: EX permission */
-#define _PAGE_ACCESSED 0x400 /* software: R: page referenced */
-
-#define _PMD_PRESENT 0x400 /* PMD points to page of PTEs */
-#define _PMD_BAD 0x802
-#define _PMD_SIZE 0x0e0 /* size field, != 0 for large-page PMD entry */
-#define _PMD_SIZE_4M 0x0c0
-#define _PMD_SIZE_16M 0x0e0
-#define PMD_PAGE_SIZE(pmdval) (1024 << (((pmdval) & _PMD_SIZE) >> 4))
-
-/* Until my rework is finished, 40x still needs atomic PTE updates */
-#define PTE_ATOMIC_UPDATES 1
-
+#include <asm/pte-40x.h>
#elif defined(CONFIG_44x)
-/*
- * Definitions for PPC440
- *
- * Because of the 3 word TLB entries to support 36-bit addressing,
- * the attribute are difficult to map in such a fashion that they
- * are easily loaded during exception processing. I decided to
- * organize the entry so the ERPN is the only portion in the
- * upper word of the PTE and the attribute bits below are packed
- * in as sensibly as they can be in the area below a 4KB page size
- * oriented RPN. This at least makes it easy to load the RPN and
- * ERPN fields in the TLB. -Matt
- *
- * Note that these bits preclude future use of a page size
- * less than 4KB.
- *
- *
- * PPC 440 core has following TLB attribute fields;
- *
- * TLB1:
- * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
- * RPN................................. - - - - - - ERPN.......
- *
- * TLB2:
- * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
- * - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW SR
- *
- * Newer 440 cores (440x6 as used on AMCC 460EX/460GT) have additional
- * TLB2 storage attibute fields. Those are:
- *
- * TLB2:
- * 0...10 11 12 13 14 15 16...31
- * no change WL1 IL1I IL1D IL2I IL2D no change
- *
- * There are some constrains and options, to decide mapping software bits
- * into TLB entry.
- *
- * - PRESENT *must* be in the bottom three bits because swap cache
- * entries use the top 29 bits for TLB2.
- *
- * - FILE *must* be in the bottom three bits because swap cache
- * entries use the top 29 bits for TLB2.
- *
- * - CACHE COHERENT bit (M) has no effect on original PPC440 cores,
- * because it doesn't support SMP. However, some later 460 variants
- * have -some- form of SMP support and so I keep the bit there for
- * future use
- *
- * With the PPC 44x Linux implementation, the 0-11th LSBs of the PTE are used
- * for memory protection related functions (see PTE structure in
- * include/asm-ppc/mmu.h). The _PAGE_XXX definitions in this file map to the
- * above bits. Note that the bit values are CPU specific, not architecture
- * specific.
- *
- * The kernel PTE entry holds an arch-dependent swp_entry structure under
- * certain situations. In other words, in such situations some portion of
- * the PTE bits are used as a swp_entry. In the PPC implementation, the
- * 3-24th LSB are shared with swp_entry, however the 0-2nd three LSB still
- * hold protection values. That means the three protection bits are
- * reserved for both PTE and SWAP entry at the most significant three
- * LSBs.
- *
- * There are three protection bits available for SWAP entry:
- * _PAGE_PRESENT
- * _PAGE_FILE
- * _PAGE_HASHPTE (if HW has)
- *
- * So those three bits have to be inside of 0-2nd LSB of PTE.
- *
- */
-
-#define _PAGE_PRESENT 0x00000001 /* S: PTE valid */
-#define _PAGE_RW 0x00000002 /* S: Write permission */
-#define _PAGE_FILE 0x00000004 /* S: nonlinear file mapping */
-#define _PAGE_HWEXEC 0x00000004 /* H: Execute permission */
-#define _PAGE_ACCESSED 0x00000008 /* S: Page referenced */
-#define _PAGE_DIRTY 0x00000010 /* S: Page dirty */
-#define _PAGE_SPECIAL 0x00000020 /* S: Special page */
-#define _PAGE_USER 0x00000040 /* S: User page */
-#define _PAGE_ENDIAN 0x00000080 /* H: E bit */
-#define _PAGE_GUARDED 0x00000100 /* H: G bit */
-#define _PAGE_COHERENT 0x00000200 /* H: M bit */
-#define _PAGE_NO_CACHE 0x00000400 /* H: I bit */
-#define _PAGE_WRITETHRU 0x00000800 /* H: W bit */
-
-/* TODO: Add large page lowmem mapping support */
-#define _PMD_PRESENT 0
-#define _PMD_PRESENT_MASK (PAGE_MASK)
-#define _PMD_BAD (~PAGE_MASK)
-
-/* ERPN in a PTE never gets cleared, ignore it */
-#define _PTE_NONE_MASK 0xffffffff00000000ULL
-
-#define __HAVE_ARCH_PTE_SPECIAL
-
+#include <asm/pte-44x.h>
#elif defined(CONFIG_FSL_BOOKE)
-/*
- MMU Assist Register 3:
-
- 32 33 34 35 36 ... 50 51 52 53 54 55 56 57 58 59 60 61 62 63
- RPN...................... 0 0 U0 U1 U2 U3 UX SX UW SW UR SR
-
- - PRESENT *must* be in the bottom three bits because swap cache
- entries use the top 29 bits.
-
- - FILE *must* be in the bottom three bits because swap cache
- entries use the top 29 bits.
-*/
-
-/* Definitions for FSL Book-E Cores */
-#define _PAGE_PRESENT 0x00001 /* S: PTE contains a translation */
-#define _PAGE_USER 0x00002 /* S: User page (maps to UR) */
-#define _PAGE_FILE 0x00002 /* S: when !present: nonlinear file mapping */
-#define _PAGE_RW 0x00004 /* S: Write permission (SW) */
-#define _PAGE_DIRTY 0x00008 /* S: Page dirty */
-#define _PAGE_HWEXEC 0x00010 /* H: SX permission */
-#define _PAGE_ACCESSED 0x00020 /* S: Page referenced */
-
-#define _PAGE_ENDIAN 0x00040 /* H: E bit */
-#define _PAGE_GUARDED 0x00080 /* H: G bit */
-#define _PAGE_COHERENT 0x00100 /* H: M bit */
-#define _PAGE_NO_CACHE 0x00200 /* H: I bit */
-#define _PAGE_WRITETHRU 0x00400 /* H: W bit */
-#define _PAGE_SPECIAL 0x00800 /* S: Special page */
-
-#ifdef CONFIG_PTE_64BIT
-/* ERPN in a PTE never gets cleared, ignore it */
-#define _PTE_NONE_MASK 0xffffffffffff0000ULL
-#endif
-
-#define _PMD_PRESENT 0
-#define _PMD_PRESENT_MASK (PAGE_MASK)
-#define _PMD_BAD (~PAGE_MASK)
-
-#define __HAVE_ARCH_PTE_SPECIAL
-
+#include <asm/pte-fsl-booke.h>
#elif defined(CONFIG_8xx)
-/* Definitions for 8xx embedded chips. */
-#define _PAGE_PRESENT 0x0001 /* Page is valid */
-#define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
-#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
-#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
-
-/* These five software bits must be masked out when the entry is loaded
- * into the TLB.
- */
-#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
-#define _PAGE_GUARDED 0x0010 /* software: guarded access */
-#define _PAGE_DIRTY 0x0020 /* software: page changed */
-#define _PAGE_RW 0x0040 /* software: user write access allowed */
-#define _PAGE_ACCESSED 0x0080 /* software: page referenced */
-
-/* Setting any bits in the nibble with the follow two controls will
- * require a TLB exception handler change. It is assumed unused bits
- * are always zero.
- */
-#define _PAGE_HWWRITE 0x0100 /* h/w write enable: never set in Linux PTE */
-#define _PAGE_USER 0x0800 /* One of the PP bits, the other is USER&~RW */
-
-#define _PMD_PRESENT 0x0001
-#define _PMD_BAD 0x0ff0
-#define _PMD_PAGE_MASK 0x000c
-#define _PMD_PAGE_8M 0x000c
-
-#define _PTE_NONE_MASK _PAGE_ACCESSED
-
-/* Until my rework is finished, 8xx still needs atomic PTE updates */
-#define PTE_ATOMIC_UPDATES 1
-
+#include <asm/pte-8xx.h>
#else /* CONFIG_6xx */
-/* Definitions for 60x, 740/750, etc. */
-#define _PAGE_PRESENT 0x001 /* software: pte contains a translation */
-#define _PAGE_HASHPTE 0x002 /* hash_page has made an HPTE for this pte */
-#define _PAGE_FILE 0x004 /* when !present: nonlinear file mapping */
-#define _PAGE_USER 0x004 /* usermode access allowed */
-#define _PAGE_GUARDED 0x008 /* G: prohibit speculative access */
-#define _PAGE_COHERENT 0x010 /* M: enforce memory coherence (SMP systems) */
-#define _PAGE_NO_CACHE 0x020 /* I: cache inhibit */
-#define _PAGE_WRITETHRU 0x040 /* W: cache write-through */
-#define _PAGE_DIRTY 0x080 /* C: page changed */
-#define _PAGE_ACCESSED 0x100 /* R: page referenced */
-#define _PAGE_EXEC 0x200 /* software: i-cache coherency required */
-#define _PAGE_RW 0x400 /* software: user write access allowed */
-#define _PAGE_SPECIAL 0x800 /* software: Special page */
-
-#ifdef CONFIG_PTE_64BIT
-/* We never clear the high word of the pte */
-#define _PTE_NONE_MASK (0xffffffff00000000ULL | _PAGE_HASHPTE)
-#else
-#define _PTE_NONE_MASK _PAGE_HASHPTE
+#include <asm/pte-hash32.h>
#endif
-#define _PMD_PRESENT 0
-#define _PMD_PRESENT_MASK (PAGE_MASK)
-#define _PMD_BAD (~PAGE_MASK)
-
-/* Hash table based platforms need atomic updates of the linux PTE */
-#define PTE_ATOMIC_UPDATES 1
-
+/* If _PAGE_SPECIAL is defined, then we advertise our support for it */
+#ifdef _PAGE_SPECIAL
#define __HAVE_ARCH_PTE_SPECIAL
-
#endif
/*
- * Some bits are only used on some cpu families...
+ * Some bits are only used on some cpu families... Make sure that all
+ * the undefined gets defined as 0
*/
#ifndef _PAGE_HASHPTE
#define _PAGE_HASHPTE 0
@@ -600,11 +315,19 @@ extern void flush_hash_entry(struct mm_s
unsigned long address);
/*
- * Atomic PTE updates.
- *
- * pte_update clears and sets bit atomically, and returns
- * the old pte value. In the 64-bit PTE case we lock around the
- * low PTE word since we expect ALL flag bits to be there
+ * PTE updates. This function is called whenever an existing
+ * valid PTE is updated. This does -not- include set_pte_at()
+ * which nowadays only sets a new PTE.
+ *
+ * Depending on the type of MMU, we may need to use atomic updates
+ * and the PTE may be either 32 or 64 bit wide. In the later case,
+ * when using atomic updates, only the low part of the PTE is
+ * accessed atomically.
+ *
+ * In addition, on 44x, we also maintain a global flag indicating
+ * that an executable user mapping was modified, which is needed
+ * to properly flush the virtually tagged instruction cache of
+ * those implementations.
*/
#ifndef CONFIG_PTE_64BIT
static inline unsigned long pte_update(pte_t *p,
Index: linux-work/arch/powerpc/include/asm/pgtable-ppc64.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc64.h 2009-02-18 13:13:53.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc64.h 2009-02-25 16:47:20.000000000 +1100
@@ -11,9 +11,9 @@
#endif /* __ASSEMBLY__ */
#ifdef CONFIG_PPC_64K_PAGES
-#include <asm/pgtable-64k.h>
+#include <asm/pgtable-ppc64-64k.h>
#else
-#include <asm/pgtable-4k.h>
+#include <asm/pgtable-ppc64-4k.h>
#endif
#define FIRST_USER_ADDRESS 0
@@ -25,6 +25,8 @@
PUD_INDEX_SIZE + PGD_INDEX_SIZE + PAGE_SHIFT)
#define PGTABLE_RANGE (ASM_CONST(1) << PGTABLE_EADDR_SIZE)
+
+/* Some sanity checking */
#if TASK_SIZE_USER64 > PGTABLE_RANGE
#error TASK_SIZE_USER64 exceeds pagetable range
#endif
@@ -33,7 +35,6 @@
#error TASK_SIZE_USER64 exceeds user VSID range
#endif
-
/*
* Define the address range of the vmalloc VM area.
*/
@@ -76,29 +77,26 @@
/*
- * Common bits in a linux-style PTE. These match the bits in the
- * (hardware-defined) PowerPC PTE as closely as possible. Additional
- * bits may be defined in pgtable-*.h
- */
-#define _PAGE_PRESENT 0x0001 /* software: pte contains a translation */
-#define _PAGE_USER 0x0002 /* matches one of the PP bits */
-#define _PAGE_FILE 0x0002 /* (!present only) software: pte holds file offset */
-#define _PAGE_EXEC 0x0004 /* No execute on POWER4 and newer (we invert) */
-#define _PAGE_GUARDED 0x0008
-#define _PAGE_COHERENT 0x0010 /* M: enforce memory coherence (SMP systems) */
-#define _PAGE_NO_CACHE 0x0020 /* I: cache inhibit */
-#define _PAGE_WRITETHRU 0x0040 /* W: cache write-through */
-#define _PAGE_DIRTY 0x0080 /* C: page changed */
-#define _PAGE_ACCESSED 0x0100 /* R: page referenced */
-#define _PAGE_RW 0x0200 /* software: user write access allowed */
-#define _PAGE_BUSY 0x0800 /* software: PTE & hash are busy */
+ * Include the PTE bits definitions
+ */
+#include <asm/pte-hash64.h>
-/* Strong Access Ordering */
-#define _PAGE_SAO (_PAGE_WRITETHRU | _PAGE_NO_CACHE | _PAGE_COHERENT)
+/* To make some generic powerpc code happy */
+#ifndef _PAGE_HWEXEC
+#define _PAGE_HWEXEC 0
+#endif
+
+/* Some other useful definitions */
+#define PTE_RPN_MAX (1UL << (64 - PTE_RPN_SHIFT))
+#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
+
+/* _PAGE_CHG_MASK masks of bits that are to be preserved accross
+ * pgprot changes
+ */
+#define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
+ _PAGE_ACCESSED | _PAGE_SPECIAL)
-#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT)
-#define _PAGE_WRENABLE (_PAGE_RW | _PAGE_DIRTY)
/* __pgprot defined in arch/powerpc/include/asm/page.h */
#define PAGE_NONE __pgprot(_PAGE_PRESENT | _PAGE_ACCESSED)
@@ -117,16 +115,9 @@
#define PAGE_AGP __pgprot(_PAGE_BASE | _PAGE_WRENABLE | _PAGE_NO_CACHE)
#define HAVE_PAGE_AGP
-#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | \
- _PAGE_NO_CACHE | _PAGE_WRITETHRU | \
- _PAGE_4K_PFN | _PAGE_RW | _PAGE_USER | \
- _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_EXEC)
-/* PTEIDX nibble */
-#define _PTEIDX_SECONDARY 0x8
-#define _PTEIDX_GROUP_IX 0x7
+/* We always have _PAGE_SPECIAL on 64 bit */
+#define __HAVE_ARCH_PTE_SPECIAL
-/* To make some generic powerpc code happy */
-#define _PAGE_HWEXEC 0
/*
* POWER4 and newer have per page execute protection, older chips can only
@@ -163,6 +154,38 @@
#ifndef __ASSEMBLY__
/*
+ * This is the default implementation of various PTE accessors, it's
+ * used in all cases except Book3S with 64K pages where we have a
+ * concept of sub-pages
+ */
+#ifndef __real_pte
+
+#ifdef STRICT_MM_TYPECHECKS
+#define __real_pte(e,p) ((real_pte_t){(e)})
+#define __rpte_to_pte(r) ((r).pte)
+#else
+#define __real_pte(e,p) (e)
+#define __rpte_to_pte(r) (__pte(r))
+#endif
+#define __rpte_to_hidx(r,index) (pte_val(__rpte_to_pte(r)) >> 12)
+
+#define pte_iterate_hashed_subpages(rpte, psize, va, index, shift) \
+ do { \
+ index = 0; \
+ shift = mmu_psize_defs[psize].shift; \
+
+#define pte_iterate_hashed_end() } while(0)
+
+#ifdef CONFIG_PPC_HAS_HASH_64K
+#define pte_pagesize_index(mm, addr, pte) get_slice_psize(mm, addr)
+#else
+#define pte_pagesize_index(mm, addr, pte) MMU_PAGE_4K
+#endif
+
+#endif /* __real_pte */
+
+
+/*
* Conversion functions: convert a page and protection to a page entry,
* and a page entry and page directory to the page they refer to.
*
Index: linux-work/arch/powerpc/include/asm/pgtable-4k.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/pgtable-4k.h 2009-02-18 13:20:35.000000000 +1100
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,117 +0,0 @@
-#ifndef _ASM_POWERPC_PGTABLE_4K_H
-#define _ASM_POWERPC_PGTABLE_4K_H
-/*
- * Entries per page directory level. The PTE level must use a 64b record
- * for each page table entry. The PMD and PGD level use a 32b record for
- * each entry by assuming that each entry is page aligned.
- */
-#define PTE_INDEX_SIZE 9
-#define PMD_INDEX_SIZE 7
-#define PUD_INDEX_SIZE 7
-#define PGD_INDEX_SIZE 9
-
-#ifndef __ASSEMBLY__
-#define PTE_TABLE_SIZE (sizeof(pte_t) << PTE_INDEX_SIZE)
-#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
-#define PUD_TABLE_SIZE (sizeof(pud_t) << PUD_INDEX_SIZE)
-#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
-#endif /* __ASSEMBLY__ */
-
-#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
-#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
-#define PTRS_PER_PUD (1 << PMD_INDEX_SIZE)
-#define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
-
-/* PMD_SHIFT determines what a second-level page table entry can map */
-#define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
-#define PMD_SIZE (1UL << PMD_SHIFT)
-#define PMD_MASK (~(PMD_SIZE-1))
-
-/* With 4k base page size, hugepage PTEs go at the PMD level */
-#define MIN_HUGEPTE_SHIFT PMD_SHIFT
-
-/* PUD_SHIFT determines what a third-level page table entry can map */
-#define PUD_SHIFT (PMD_SHIFT + PMD_INDEX_SIZE)
-#define PUD_SIZE (1UL << PUD_SHIFT)
-#define PUD_MASK (~(PUD_SIZE-1))
-
-/* PGDIR_SHIFT determines what a fourth-level page table entry can map */
-#define PGDIR_SHIFT (PUD_SHIFT + PUD_INDEX_SIZE)
-#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
-#define PGDIR_MASK (~(PGDIR_SIZE-1))
-
-/* PTE bits */
-#define _PAGE_HASHPTE 0x0400 /* software: pte has an associated HPTE */
-#define _PAGE_SECONDARY 0x8000 /* software: HPTE is in secondary group */
-#define _PAGE_GROUP_IX 0x7000 /* software: HPTE index within group */
-#define _PAGE_F_SECOND _PAGE_SECONDARY
-#define _PAGE_F_GIX _PAGE_GROUP_IX
-#define _PAGE_SPECIAL 0x10000 /* software: special page */
-#define __HAVE_ARCH_PTE_SPECIAL
-
-/* PTE flags to conserve for HPTE identification */
-#define _PAGE_HPTEFLAGS (_PAGE_BUSY | _PAGE_HASHPTE | \
- _PAGE_SECONDARY | _PAGE_GROUP_IX)
-
-/* There is no 4K PFN hack on 4K pages */
-#define _PAGE_4K_PFN 0
-
-/* PAGE_MASK gives the right answer below, but only by accident */
-/* It should be preserving the high 48 bits and then specifically */
-/* preserving _PAGE_SECONDARY | _PAGE_GROUP_IX */
-#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | \
- _PAGE_HPTEFLAGS | _PAGE_SPECIAL)
-
-/* Bits to mask out from a PMD to get to the PTE page */
-#define PMD_MASKED_BITS 0
-/* Bits to mask out from a PUD to get to the PMD page */
-#define PUD_MASKED_BITS 0
-/* Bits to mask out from a PGD to get to the PUD page */
-#define PGD_MASKED_BITS 0
-
-/* shift to put page number into pte */
-#define PTE_RPN_SHIFT (17)
-
-#ifdef STRICT_MM_TYPECHECKS
-#define __real_pte(e,p) ((real_pte_t){(e)})
-#define __rpte_to_pte(r) ((r).pte)
-#else
-#define __real_pte(e,p) (e)
-#define __rpte_to_pte(r) (__pte(r))
-#endif
-#define __rpte_to_hidx(r,index) (pte_val(__rpte_to_pte(r)) >> 12)
-
-#define pte_iterate_hashed_subpages(rpte, psize, va, index, shift) \
- do { \
- index = 0; \
- shift = mmu_psize_defs[psize].shift; \
-
-#define pte_iterate_hashed_end() } while(0)
-
-#ifdef CONFIG_PPC_HAS_HASH_64K
-#define pte_pagesize_index(mm, addr, pte) get_slice_psize(mm, addr)
-#else
-#define pte_pagesize_index(mm, addr, pte) MMU_PAGE_4K
-#endif
-
-/*
- * 4-level page tables related bits
- */
-
-#define pgd_none(pgd) (!pgd_val(pgd))
-#define pgd_bad(pgd) (pgd_val(pgd) == 0)
-#define pgd_present(pgd) (pgd_val(pgd) != 0)
-#define pgd_clear(pgdp) (pgd_val(*(pgdp)) = 0)
-#define pgd_page_vaddr(pgd) (pgd_val(pgd) & ~PGD_MASKED_BITS)
-#define pgd_page(pgd) virt_to_page(pgd_page_vaddr(pgd))
-
-#define pud_offset(pgdp, addr) \
- (((pud_t *) pgd_page_vaddr(*(pgdp))) + \
- (((addr) >> PUD_SHIFT) & (PTRS_PER_PUD - 1)))
-
-#define pud_ERROR(e) \
- printk("%s:%d: bad pud %08lx.\n", __FILE__, __LINE__, pud_val(e))
-
-#define remap_4k_pfn(vma, addr, pfn, prot) \
- remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, (prot))
-#endif /* _ASM_POWERPC_PGTABLE_4K_H */
Index: linux-work/arch/powerpc/include/asm/pgtable-64k.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/pgtable-64k.h 2009-02-18 13:20:35.000000000 +1100
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,155 +0,0 @@
-#ifndef _ASM_POWERPC_PGTABLE_64K_H
-#define _ASM_POWERPC_PGTABLE_64K_H
-
-#include <asm-generic/pgtable-nopud.h>
-
-
-#define PTE_INDEX_SIZE 12
-#define PMD_INDEX_SIZE 12
-#define PUD_INDEX_SIZE 0
-#define PGD_INDEX_SIZE 4
-
-#ifndef __ASSEMBLY__
-#define PTE_TABLE_SIZE (sizeof(real_pte_t) << PTE_INDEX_SIZE)
-#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
-#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
-
-#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
-#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
-#define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
-
-#ifdef CONFIG_PPC_SUBPAGE_PROT
-/*
- * For the sub-page protection option, we extend the PGD with one of
- * these. Basically we have a 3-level tree, with the top level being
- * the protptrs array. To optimize speed and memory consumption when
- * only addresses < 4GB are being protected, pointers to the first
- * four pages of sub-page protection words are stored in the low_prot
- * array.
- * Each page of sub-page protection words protects 1GB (4 bytes
- * protects 64k). For the 3-level tree, each page of pointers then
- * protects 8TB.
- */
-struct subpage_prot_table {
- unsigned long maxaddr; /* only addresses < this are protected */
- unsigned int **protptrs[2];
- unsigned int *low_prot[4];
-};
-
-#undef PGD_TABLE_SIZE
-#define PGD_TABLE_SIZE ((sizeof(pgd_t) << PGD_INDEX_SIZE) + \
- sizeof(struct subpage_prot_table))
-
-#define SBP_L1_BITS (PAGE_SHIFT - 2)
-#define SBP_L2_BITS (PAGE_SHIFT - 3)
-#define SBP_L1_COUNT (1 << SBP_L1_BITS)
-#define SBP_L2_COUNT (1 << SBP_L2_BITS)
-#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
-#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
-
-extern void subpage_prot_free(pgd_t *pgd);
-
-static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd)
-{
- return (struct subpage_prot_table *)(pgd + PTRS_PER_PGD);
-}
-#endif /* CONFIG_PPC_SUBPAGE_PROT */
-#endif /* __ASSEMBLY__ */
-
-/* With 4k base page size, hugepage PTEs go at the PMD level */
-#define MIN_HUGEPTE_SHIFT PAGE_SHIFT
-
-/* PMD_SHIFT determines what a second-level page table entry can map */
-#define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
-#define PMD_SIZE (1UL << PMD_SHIFT)
-#define PMD_MASK (~(PMD_SIZE-1))
-
-/* PGDIR_SHIFT determines what a third-level page table entry can map */
-#define PGDIR_SHIFT (PMD_SHIFT + PMD_INDEX_SIZE)
-#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
-#define PGDIR_MASK (~(PGDIR_SIZE-1))
-
-/* Additional PTE bits (don't change without checking asm in hash_low.S) */
-#define __HAVE_ARCH_PTE_SPECIAL
-#define _PAGE_SPECIAL 0x00000400 /* software: special page */
-#define _PAGE_HPTE_SUB 0x0ffff000 /* combo only: sub pages HPTE bits */
-#define _PAGE_HPTE_SUB0 0x08000000 /* combo only: first sub page */
-#define _PAGE_COMBO 0x10000000 /* this is a combo 4k page */
-#define _PAGE_4K_PFN 0x20000000 /* PFN is for a single 4k page */
-
-/* For 64K page, we don't have a separate _PAGE_HASHPTE bit. Instead,
- * we set that to be the whole sub-bits mask. The C code will only
- * test this, so a multi-bit mask will work. For combo pages, this
- * is equivalent as effectively, the old _PAGE_HASHPTE was an OR of
- * all the sub bits. For real 64k pages, we now have the assembly set
- * _PAGE_HPTE_SUB0 in addition to setting the HIDX bits which overlap
- * that mask. This is fine as long as the HIDX bits are never set on
- * a PTE that isn't hashed, which is the case today.
- *
- * A little nit is for the huge page C code, which does the hashing
- * in C, we need to provide which bit to use.
- */
-#define _PAGE_HASHPTE _PAGE_HPTE_SUB
-
-/* Note the full page bits must be in the same location as for normal
- * 4k pages as the same asssembly will be used to insert 64K pages
- * wether the kernel has CONFIG_PPC_64K_PAGES or not
- */
-#define _PAGE_F_SECOND 0x00008000 /* full page: hidx bits */
-#define _PAGE_F_GIX 0x00007000 /* full page: hidx bits */
-
-/* PTE flags to conserve for HPTE identification */
-#define _PAGE_HPTEFLAGS (_PAGE_BUSY | _PAGE_HASHPTE | _PAGE_COMBO)
-
-/* Shift to put page number into pte.
- *
- * That gives us a max RPN of 34 bits, which means a max of 50 bits
- * of addressable physical space, or 46 bits for the special 4k PFNs.
- */
-#define PTE_RPN_SHIFT (30)
-#define PTE_RPN_MAX (1UL << (64 - PTE_RPN_SHIFT))
-#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
-
-/* _PAGE_CHG_MASK masks of bits that are to be preserved accross
- * pgprot changes
- */
-#define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
- _PAGE_ACCESSED | _PAGE_SPECIAL)
-
-/* Bits to mask out from a PMD to get to the PTE page */
-#define PMD_MASKED_BITS 0x1ff
-/* Bits to mask out from a PGD/PUD to get to the PMD page */
-#define PUD_MASKED_BITS 0x1ff
-
-/* Manipulate "rpte" values */
-#define __real_pte(e,p) ((real_pte_t) { \
- (e), pte_val(*((p) + PTRS_PER_PTE)) })
-#define __rpte_to_hidx(r,index) ((pte_val((r).pte) & _PAGE_COMBO) ? \
- (((r).hidx >> ((index)<<2)) & 0xf) : ((pte_val((r).pte) >> 12) & 0xf))
-#define __rpte_to_pte(r) ((r).pte)
-#define __rpte_sub_valid(rpte, index) \
- (pte_val(rpte.pte) & (_PAGE_HPTE_SUB0 >> (index)))
-
-
-/* Trick: we set __end to va + 64k, which happens works for
- * a 16M page as well as we want only one iteration
- */
-#define pte_iterate_hashed_subpages(rpte, psize, va, index, shift) \
- do { \
- unsigned long __end = va + PAGE_SIZE; \
- unsigned __split = (psize == MMU_PAGE_4K || \
- psize == MMU_PAGE_64K_AP); \
- shift = mmu_psize_defs[psize].shift; \
- for (index = 0; va < __end; index++, va += (1L << shift)) { \
- if (!__split || __rpte_sub_valid(rpte, index)) do { \
-
-#define pte_iterate_hashed_end() } while(0); } } while(0)
-
-#define pte_pagesize_index(mm, addr, pte) \
- (((pte) & _PAGE_COMBO)? MMU_PAGE_4K: MMU_PAGE_64K)
-
-#define remap_4k_pfn(vma, addr, pfn, prot) \
- remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, \
- __pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
-
-#endif /* _ASM_POWERPC_PGTABLE_64K_H */
Index: linux-work/arch/powerpc/include/asm/pgtable-ppc64-4k.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc64-4k.h 2009-02-25 16:27:57.000000000 +1100
@@ -0,0 +1,74 @@
+#ifndef _ASM_POWERPC_PGTABLE_4K_H
+#define _ASM_POWERPC_PGTABLE_4K_H
+/*
+ * Entries per page directory level. The PTE level must use a 64b record
+ * for each page table entry. The PMD and PGD level use a 32b record for
+ * each entry by assuming that each entry is page aligned.
+ */
+#define PTE_INDEX_SIZE 9
+#define PMD_INDEX_SIZE 7
+#define PUD_INDEX_SIZE 7
+#define PGD_INDEX_SIZE 9
+
+#ifndef __ASSEMBLY__
+#define PTE_TABLE_SIZE (sizeof(pte_t) << PTE_INDEX_SIZE)
+#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
+#define PUD_TABLE_SIZE (sizeof(pud_t) << PUD_INDEX_SIZE)
+#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
+#endif /* __ASSEMBLY__ */
+
+#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
+#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
+#define PTRS_PER_PUD (1 << PMD_INDEX_SIZE)
+#define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
+
+/* PMD_SHIFT determines what a second-level page table entry can map */
+#define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
+#define PMD_SIZE (1UL << PMD_SHIFT)
+#define PMD_MASK (~(PMD_SIZE-1))
+
+/* With 4k base page size, hugepage PTEs go at the PMD level */
+#define MIN_HUGEPTE_SHIFT PMD_SHIFT
+
+/* PUD_SHIFT determines what a third-level page table entry can map */
+#define PUD_SHIFT (PMD_SHIFT + PMD_INDEX_SIZE)
+#define PUD_SIZE (1UL << PUD_SHIFT)
+#define PUD_MASK (~(PUD_SIZE-1))
+
+/* PGDIR_SHIFT determines what a fourth-level page table entry can map */
+#define PGDIR_SHIFT (PUD_SHIFT + PUD_INDEX_SIZE)
+#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+
+/* Bits to mask out from a PMD to get to the PTE page */
+#define PMD_MASKED_BITS 0
+/* Bits to mask out from a PUD to get to the PMD page */
+#define PUD_MASKED_BITS 0
+/* Bits to mask out from a PGD to get to the PUD page */
+#define PGD_MASKED_BITS 0
+
+
+/*
+ * 4-level page tables related bits
+ */
+
+#define pgd_none(pgd) (!pgd_val(pgd))
+#define pgd_bad(pgd) (pgd_val(pgd) == 0)
+#define pgd_present(pgd) (pgd_val(pgd) != 0)
+#define pgd_clear(pgdp) (pgd_val(*(pgdp)) = 0)
+#define pgd_page_vaddr(pgd) (pgd_val(pgd) & ~PGD_MASKED_BITS)
+#define pgd_page(pgd) virt_to_page(pgd_page_vaddr(pgd))
+
+#define pud_offset(pgdp, addr) \
+ (((pud_t *) pgd_page_vaddr(*(pgdp))) + \
+ (((addr) >> PUD_SHIFT) & (PTRS_PER_PUD - 1)))
+
+#define pud_ERROR(e) \
+ printk("%s:%d: bad pud %08lx.\n", __FILE__, __LINE__, pud_val(e))
+
+/*
+ * On all 4K setups, remap_4k_pfn() equates to remap_pfn_range() */
+#define remap_4k_pfn(vma, addr, pfn, prot) \
+ remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, (prot))
+
+#endif /* _ASM_POWERPC_PGTABLE_4K_H */
Index: linux-work/arch/powerpc/include/asm/pgtable-ppc64-64k.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc64-64k.h 2009-02-25 16:16:14.000000000 +1100
@@ -0,0 +1,42 @@
+#ifndef _ASM_POWERPC_PGTABLE_64K_H
+#define _ASM_POWERPC_PGTABLE_64K_H
+
+#include <asm-generic/pgtable-nopud.h>
+
+
+#define PTE_INDEX_SIZE 12
+#define PMD_INDEX_SIZE 12
+#define PUD_INDEX_SIZE 0
+#define PGD_INDEX_SIZE 4
+
+#ifndef __ASSEMBLY__
+
+#define PTE_TABLE_SIZE (sizeof(real_pte_t) << PTE_INDEX_SIZE)
+#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
+#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
+
+#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
+#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
+#define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
+
+/* With 4k base page size, hugepage PTEs go at the PMD level */
+#define MIN_HUGEPTE_SHIFT PAGE_SHIFT
+
+/* PMD_SHIFT determines what a second-level page table entry can map */
+#define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
+#define PMD_SIZE (1UL << PMD_SHIFT)
+#define PMD_MASK (~(PMD_SIZE-1))
+
+/* PGDIR_SHIFT determines what a third-level page table entry can map */
+#define PGDIR_SHIFT (PMD_SHIFT + PMD_INDEX_SIZE)
+#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+
+#endif /* __ASSEMBLY__ */
+
+/* Bits to mask out from a PMD to get to the PTE page */
+#define PMD_MASKED_BITS 0x1ff
+/* Bits to mask out from a PGD/PUD to get to the PMD page */
+#define PUD_MASKED_BITS 0x1ff
+
+#endif /* _ASM_POWERPC_PGTABLE_64K_H */
Index: linux-work/arch/powerpc/include/asm/pte-40x.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-40x.h 2009-02-25 15:39:44.000000000 +1100
@@ -0,0 +1,64 @@
+#ifndef _ASM_POWERPC_PGTABLE_40x_H
+#define _ASM_POWERPC_PGTABLE_40x_H
+#ifdef __KERNEL__
+
+/*
+ * At present, all PowerPC 400-class processors share a similar TLB
+ * architecture. The instruction and data sides share a unified,
+ * 64-entry, fully-associative TLB which is maintained totally under
+ * software control. In addition, the instruction side has a
+ * hardware-managed, 4-entry, fully-associative TLB which serves as a
+ * first level to the shared TLB. These two TLBs are known as the UTLB
+ * and ITLB, respectively (see "mmu.h" for definitions).
+ *
+ * There are several potential gotchas here. The 40x hardware TLBLO
+ * field looks like this:
+ *
+ * 0 1 2 3 4 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+ * RPN..................... 0 0 EX WR ZSEL....... W I M G
+ *
+ * Where possible we make the Linux PTE bits match up with this
+ *
+ * - bits 20 and 21 must be cleared, because we use 4k pages (40x can
+ * support down to 1k pages), this is done in the TLBMiss exception
+ * handler.
+ * - We use only zones 0 (for kernel pages) and 1 (for user pages)
+ * of the 16 available. Bit 24-26 of the TLB are cleared in the TLB
+ * miss handler. Bit 27 is PAGE_USER, thus selecting the correct
+ * zone.
+ * - PRESENT *must* be in the bottom two bits because swap cache
+ * entries use the top 30 bits. Because 40x doesn't support SMP
+ * anyway, M is irrelevant so we borrow it for PAGE_PRESENT. Bit 30
+ * is cleared in the TLB miss handler before the TLB entry is loaded.
+ * - All other bits of the PTE are loaded into TLBLO without
+ * modification, leaving us only the bits 20, 21, 24, 25, 26, 30 for
+ * software PTE bits. We actually use use bits 21, 24, 25, and
+ * 30 respectively for the software bits: ACCESSED, DIRTY, RW, and
+ * PRESENT.
+ */
+
+#define _PAGE_GUARDED 0x001 /* G: page is guarded from prefetch */
+#define _PAGE_FILE 0x001 /* when !present: nonlinear file mapping */
+#define _PAGE_PRESENT 0x002 /* software: PTE contains a translation */
+#define _PAGE_NO_CACHE 0x004 /* I: caching is inhibited */
+#define _PAGE_WRITETHRU 0x008 /* W: caching is write-through */
+#define _PAGE_USER 0x010 /* matches one of the zone permission bits */
+#define _PAGE_RW 0x040 /* software: Writes permitted */
+#define _PAGE_DIRTY 0x080 /* software: dirty page */
+#define _PAGE_HWWRITE 0x100 /* hardware: Dirty & RW, set in exception */
+#define _PAGE_HWEXEC 0x200 /* hardware: EX permission */
+#define _PAGE_ACCESSED 0x400 /* software: R: page referenced */
+
+#define _PMD_PRESENT 0x400 /* PMD points to page of PTEs */
+#define _PMD_BAD 0x802
+#define _PMD_SIZE 0x0e0 /* size field, != 0 for large-page PMD entry */
+#define _PMD_SIZE_4M 0x0c0
+#define _PMD_SIZE_16M 0x0e0
+
+#define PMD_PAGE_SIZE(pmdval) (1024 << (((pmdval) & _PMD_SIZE) >> 4))
+
+/* Until my rework is finished, 40x still needs atomic PTE updates */
+#define PTE_ATOMIC_UPDATES 1
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_PGTABLE_40x_H */
Index: linux-work/arch/powerpc/include/asm/pte-44x.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-44x.h 2009-02-25 15:39:44.000000000 +1100
@@ -0,0 +1,102 @@
+#ifndef _ASM_POWERPC_PGTABLE_44x_H
+#define _ASM_POWERPC_PGTABLE_44x_H
+#ifdef __KERNEL__
+
+/*
+ * Definitions for PPC440
+ *
+ * Because of the 3 word TLB entries to support 36-bit addressing,
+ * the attribute are difficult to map in such a fashion that they
+ * are easily loaded during exception processing. I decided to
+ * organize the entry so the ERPN is the only portion in the
+ * upper word of the PTE and the attribute bits below are packed
+ * in as sensibly as they can be in the area below a 4KB page size
+ * oriented RPN. This at least makes it easy to load the RPN and
+ * ERPN fields in the TLB. -Matt
+ *
+ * This isn't entirely true anymore, at least some bits are now
+ * easier to move into the TLB from the PTE. -BenH.
+ *
+ * Note that these bits preclude future use of a page size
+ * less than 4KB.
+ *
+ *
+ * PPC 440 core has following TLB attribute fields;
+ *
+ * TLB1:
+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+ * RPN................................. - - - - - - ERPN.......
+ *
+ * TLB2:
+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+ * - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW SR
+ *
+ * Newer 440 cores (440x6 as used on AMCC 460EX/460GT) have additional
+ * TLB2 storage attibute fields. Those are:
+ *
+ * TLB2:
+ * 0...10 11 12 13 14 15 16...31
+ * no change WL1 IL1I IL1D IL2I IL2D no change
+ *
+ * There are some constrains and options, to decide mapping software bits
+ * into TLB entry.
+ *
+ * - PRESENT *must* be in the bottom three bits because swap cache
+ * entries use the top 29 bits for TLB2.
+ *
+ * - FILE *must* be in the bottom three bits because swap cache
+ * entries use the top 29 bits for TLB2.
+ *
+ * - CACHE COHERENT bit (M) has no effect on original PPC440 cores,
+ * because it doesn't support SMP. However, some later 460 variants
+ * have -some- form of SMP support and so I keep the bit there for
+ * future use
+ *
+ * With the PPC 44x Linux implementation, the 0-11th LSBs of the PTE are used
+ * for memory protection related functions (see PTE structure in
+ * include/asm-ppc/mmu.h). The _PAGE_XXX definitions in this file map to the
+ * above bits. Note that the bit values are CPU specific, not architecture
+ * specific.
+ *
+ * The kernel PTE entry holds an arch-dependent swp_entry structure under
+ * certain situations. In other words, in such situations some portion of
+ * the PTE bits are used as a swp_entry. In the PPC implementation, the
+ * 3-24th LSB are shared with swp_entry, however the 0-2nd three LSB still
+ * hold protection values. That means the three protection bits are
+ * reserved for both PTE and SWAP entry at the most significant three
+ * LSBs.
+ *
+ * There are three protection bits available for SWAP entry:
+ * _PAGE_PRESENT
+ * _PAGE_FILE
+ * _PAGE_HASHPTE (if HW has)
+ *
+ * So those three bits have to be inside of 0-2nd LSB of PTE.
+ *
+ */
+
+#define _PAGE_PRESENT 0x00000001 /* S: PTE valid */
+#define _PAGE_RW 0x00000002 /* S: Write permission */
+#define _PAGE_FILE 0x00000004 /* S: nonlinear file mapping */
+#define _PAGE_HWEXEC 0x00000004 /* H: Execute permission */
+#define _PAGE_ACCESSED 0x00000008 /* S: Page referenced */
+#define _PAGE_DIRTY 0x00000010 /* S: Page dirty */
+#define _PAGE_SPECIAL 0x00000020 /* S: Special page */
+#define _PAGE_USER 0x00000040 /* S: User page */
+#define _PAGE_ENDIAN 0x00000080 /* H: E bit */
+#define _PAGE_GUARDED 0x00000100 /* H: G bit */
+#define _PAGE_COHERENT 0x00000200 /* H: M bit */
+#define _PAGE_NO_CACHE 0x00000400 /* H: I bit */
+#define _PAGE_WRITETHRU 0x00000800 /* H: W bit */
+
+/* TODO: Add large page lowmem mapping support */
+#define _PMD_PRESENT 0
+#define _PMD_PRESENT_MASK (PAGE_MASK)
+#define _PMD_BAD (~PAGE_MASK)
+
+/* ERPN in a PTE never gets cleared, ignore it */
+#define _PTE_NONE_MASK 0xffffffff00000000ULL
+
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_PGTABLE_44x_H */
Index: linux-work/arch/powerpc/include/asm/pte-8xx.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-8xx.h 2009-02-25 15:39:44.000000000 +1100
@@ -0,0 +1,64 @@
+#ifndef _ASM_POWERPC_PGTABLE_8xx_H
+#define _ASM_POWERPC_PGTABLE_8xx_H
+#ifdef __KERNEL__
+
+/*
+ * The PowerPC MPC8xx uses a TLB with hardware assisted, software tablewalk.
+ * We also use the two level tables, but we can put the real bits in them
+ * needed for the TLB and tablewalk. These definitions require Mx_CTR.PPM = 0,
+ * Mx_CTR.PPCS = 0, and MD_CTR.TWAM = 1. The level 2 descriptor has
+ * additional page protection (when Mx_CTR.PPCS = 1) that allows TLB hit
+ * based upon user/super access. The TLB does not have accessed nor write
+ * protect. We assume that if the TLB get loaded with an entry it is
+ * accessed, and overload the changed bit for write protect. We use
+ * two bits in the software pte that are supposed to be set to zero in
+ * the TLB entry (24 and 25) for these indicators. Although the level 1
+ * descriptor contains the guarded and writethrough/copyback bits, we can
+ * set these at the page level since they get copied from the Mx_TWC
+ * register when the TLB entry is loaded. We will use bit 27 for guard, since
+ * that is where it exists in the MD_TWC, and bit 26 for writethrough.
+ * These will get masked from the level 2 descriptor at TLB load time, and
+ * copied to the MD_TWC before it gets loaded.
+ * Large page sizes added. We currently support two sizes, 4K and 8M.
+ * This also allows a TLB hander optimization because we can directly
+ * load the PMD into MD_TWC. The 8M pages are only used for kernel
+ * mapping of well known areas. The PMD (PGD) entries contain control
+ * flags in addition to the address, so care must be taken that the
+ * software no longer assumes these are only pointers.
+ */
+
+/* Definitions for 8xx embedded chips. */
+#define _PAGE_PRESENT 0x0001 /* Page is valid */
+#define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
+#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
+#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
+
+/* These five software bits must be masked out when the entry is loaded
+ * into the TLB.
+ */
+#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
+#define _PAGE_GUARDED 0x0010 /* software: guarded access */
+#define _PAGE_DIRTY 0x0020 /* software: page changed */
+#define _PAGE_RW 0x0040 /* software: user write access allowed */
+#define _PAGE_ACCESSED 0x0080 /* software: page referenced */
+
+/* Setting any bits in the nibble with the follow two controls will
+ * require a TLB exception handler change. It is assumed unused bits
+ * are always zero.
+ */
+#define _PAGE_HWWRITE 0x0100 /* h/w write enable: never set in Linux PTE */
+#define _PAGE_USER 0x0800 /* One of the PP bits, the other is USER&~RW */
+
+#define _PMD_PRESENT 0x0001
+#define _PMD_BAD 0x0ff0
+#define _PMD_PAGE_MASK 0x000c
+#define _PMD_PAGE_8M 0x000c
+
+#define _PTE_NONE_MASK _PAGE_ACCESSED
+
+/* Until my rework is finished, 8xx still needs atomic PTE updates */
+#define PTE_ATOMIC_UPDATES 1
+
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_PGTABLE_8xx_H */
Index: linux-work/arch/powerpc/include/asm/pte-fsl-booke.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-fsl-booke.h 2009-02-25 15:39:44.000000000 +1100
@@ -0,0 +1,46 @@
+#ifndef _ASM_POWERPC_PGTABLE_FSL_BOOKE_H
+#define _ASM_POWERPC_PGTABLE_FSL_BOOKE_H
+#ifdef __KERNEL__
+
+/* PTE bit definitions for Freescale BookE SW loaded TLB MMU based
+ * processors
+ *
+ MMU Assist Register 3:
+
+ 32 33 34 35 36 ... 50 51 52 53 54 55 56 57 58 59 60 61 62 63
+ RPN...................... 0 0 U0 U1 U2 U3 UX SX UW SW UR SR
+
+ - PRESENT *must* be in the bottom three bits because swap cache
+ entries use the top 29 bits.
+
+ - FILE *must* be in the bottom three bits because swap cache
+ entries use the top 29 bits.
+*/
+
+/* Definitions for FSL Book-E Cores */
+#define _PAGE_PRESENT 0x00001 /* S: PTE contains a translation */
+#define _PAGE_USER 0x00002 /* S: User page (maps to UR) */
+#define _PAGE_FILE 0x00002 /* S: when !present: nonlinear file mapping */
+#define _PAGE_RW 0x00004 /* S: Write permission (SW) */
+#define _PAGE_DIRTY 0x00008 /* S: Page dirty */
+#define _PAGE_HWEXEC 0x00010 /* H: SX permission */
+#define _PAGE_ACCESSED 0x00020 /* S: Page referenced */
+
+#define _PAGE_ENDIAN 0x00040 /* H: E bit */
+#define _PAGE_GUARDED 0x00080 /* H: G bit */
+#define _PAGE_COHERENT 0x00100 /* H: M bit */
+#define _PAGE_NO_CACHE 0x00200 /* H: I bit */
+#define _PAGE_WRITETHRU 0x00400 /* H: W bit */
+#define _PAGE_SPECIAL 0x00800 /* S: Special page */
+
+#ifdef CONFIG_PTE_64BIT
+/* ERPN in a PTE never gets cleared, ignore it */
+#define _PTE_NONE_MASK 0xffffffffffff0000ULL
+#endif
+
+#define _PMD_PRESENT 0
+#define _PMD_PRESENT_MASK (PAGE_MASK)
+#define _PMD_BAD (~PAGE_MASK)
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_PGTABLE_FSL_BOOKE_H */
Index: linux-work/arch/powerpc/include/asm/pte-hash32.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-hash32.h 2009-02-25 15:39:44.000000000 +1100
@@ -0,0 +1,49 @@
+#ifndef _ASM_POWERPC_PGTABLE_HASH32_H
+#define _ASM_POWERPC_PGTABLE_HASH32_H
+#ifdef __KERNEL__
+
+/*
+ * The "classic" 32-bit implementation of the PowerPC MMU uses a hash
+ * table containing PTEs, together with a set of 16 segment registers,
+ * to define the virtual to physical address mapping.
+ *
+ * We use the hash table as an extended TLB, i.e. a cache of currently
+ * active mappings. We maintain a two-level page table tree, much
+ * like that used by the i386, for the sake of the Linux memory
+ * management code. Low-level assembler code in hash_low_32.S
+ * (procedure hash_page) is responsible for extracting ptes from the
+ * tree and putting them into the hash table when necessary, and
+ * updating the accessed and modified bits in the page table tree.
+ */
+
+#define _PAGE_PRESENT 0x001 /* software: pte contains a translation */
+#define _PAGE_HASHPTE 0x002 /* hash_page has made an HPTE for this pte */
+#define _PAGE_FILE 0x004 /* when !present: nonlinear file mapping */
+#define _PAGE_USER 0x004 /* usermode access allowed */
+#define _PAGE_GUARDED 0x008 /* G: prohibit speculative access */
+#define _PAGE_COHERENT 0x010 /* M: enforce memory coherence (SMP systems) */
+#define _PAGE_NO_CACHE 0x020 /* I: cache inhibit */
+#define _PAGE_WRITETHRU 0x040 /* W: cache write-through */
+#define _PAGE_DIRTY 0x080 /* C: page changed */
+#define _PAGE_ACCESSED 0x100 /* R: page referenced */
+#define _PAGE_EXEC 0x200 /* software: i-cache coherency required */
+#define _PAGE_RW 0x400 /* software: user write access allowed */
+#define _PAGE_SPECIAL 0x800 /* software: Special page */
+
+#ifdef CONFIG_PTE_64BIT
+/* We never clear the high word of the pte */
+#define _PTE_NONE_MASK (0xffffffff00000000ULL | _PAGE_HASHPTE)
+#else
+#define _PTE_NONE_MASK _PAGE_HASHPTE
+#endif
+
+#define _PMD_PRESENT 0
+#define _PMD_PRESENT_MASK (PAGE_MASK)
+#define _PMD_BAD (~PAGE_MASK)
+
+/* Hash table based platforms need atomic updates of the linux PTE */
+#define PTE_ATOMIC_UPDATES 1
+
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_PGTABLE_HASH32_H */
Index: linux-work/arch/powerpc/include/asm/pte-hash64-4k.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-hash64-4k.h 2009-02-25 16:27:36.000000000 +1100
@@ -0,0 +1,20 @@
+/* To be include by pgtable-hash64.h only */
+
+/* PTE bits */
+#define _PAGE_HASHPTE 0x0400 /* software: pte has an associated HPTE */
+#define _PAGE_SECONDARY 0x8000 /* software: HPTE is in secondary group */
+#define _PAGE_GROUP_IX 0x7000 /* software: HPTE index within group */
+#define _PAGE_F_SECOND _PAGE_SECONDARY
+#define _PAGE_F_GIX _PAGE_GROUP_IX
+#define _PAGE_SPECIAL 0x10000 /* software: special page */
+
+/* There is no 4K PFN hack on 4K pages */
+#define _PAGE_4K_PFN 0
+
+/* PTE flags to conserve for HPTE identification */
+#define _PAGE_HPTEFLAGS (_PAGE_BUSY | _PAGE_HASHPTE | \
+ _PAGE_SECONDARY | _PAGE_GROUP_IX)
+
+/* shift to put page number into pte */
+#define PTE_RPN_SHIFT (17)
+
Index: linux-work/arch/powerpc/include/asm/pte-hash64-64k.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-hash64-64k.h 2009-02-25 16:19:58.000000000 +1100
@@ -0,0 +1,115 @@
+/* To be include by pgtable-hash64.h only */
+
+/* Additional PTE bits (don't change without checking asm in hash_low.S) */
+#define _PAGE_SPECIAL 0x00000400 /* software: special page */
+#define _PAGE_HPTE_SUB 0x0ffff000 /* combo only: sub pages HPTE bits */
+#define _PAGE_HPTE_SUB0 0x08000000 /* combo only: first sub page */
+#define _PAGE_COMBO 0x10000000 /* this is a combo 4k page */
+#define _PAGE_4K_PFN 0x20000000 /* PFN is for a single 4k page */
+
+/* For 64K page, we don't have a separate _PAGE_HASHPTE bit. Instead,
+ * we set that to be the whole sub-bits mask. The C code will only
+ * test this, so a multi-bit mask will work. For combo pages, this
+ * is equivalent as effectively, the old _PAGE_HASHPTE was an OR of
+ * all the sub bits. For real 64k pages, we now have the assembly set
+ * _PAGE_HPTE_SUB0 in addition to setting the HIDX bits which overlap
+ * that mask. This is fine as long as the HIDX bits are never set on
+ * a PTE that isn't hashed, which is the case today.
+ *
+ * A little nit is for the huge page C code, which does the hashing
+ * in C, we need to provide which bit to use.
+ */
+#define _PAGE_HASHPTE _PAGE_HPTE_SUB
+
+/* Note the full page bits must be in the same location as for normal
+ * 4k pages as the same asssembly will be used to insert 64K pages
+ * wether the kernel has CONFIG_PPC_64K_PAGES or not
+ */
+#define _PAGE_F_SECOND 0x00008000 /* full page: hidx bits */
+#define _PAGE_F_GIX 0x00007000 /* full page: hidx bits */
+
+/* PTE flags to conserve for HPTE identification */
+#define _PAGE_HPTEFLAGS (_PAGE_BUSY | _PAGE_HASHPTE | _PAGE_COMBO)
+
+/* Shift to put page number into pte.
+ *
+ * That gives us a max RPN of 34 bits, which means a max of 50 bits
+ * of addressable physical space, or 46 bits for the special 4k PFNs.
+ */
+#define PTE_RPN_SHIFT (30)
+
+#ifndef __ASSEMBLY__
+
+/*
+ * With 64K pages on hash table, we have a special PTE format that
+ * uses a second "half" of the page table to encode sub-page information
+ * in order to deal with 64K made of 4K HW pages. Thus we override the
+ * generic accessors and iterators here
+ */
+#define __real_pte(e,p) ((real_pte_t) { \
+ (e), pte_val(*((p) + PTRS_PER_PTE)) })
+#define __rpte_to_hidx(r,index) ((pte_val((r).pte) & _PAGE_COMBO) ? \
+ (((r).hidx >> ((index)<<2)) & 0xf) : ((pte_val((r).pte) >> 12) & 0xf))
+#define __rpte_to_pte(r) ((r).pte)
+#define __rpte_sub_valid(rpte, index) \
+ (pte_val(rpte.pte) & (_PAGE_HPTE_SUB0 >> (index)))
+
+/* Trick: we set __end to va + 64k, which happens works for
+ * a 16M page as well as we want only one iteration
+ */
+#define pte_iterate_hashed_subpages(rpte, psize, va, index, shift) \
+ do { \
+ unsigned long __end = va + PAGE_SIZE; \
+ unsigned __split = (psize == MMU_PAGE_4K || \
+ psize == MMU_PAGE_64K_AP); \
+ shift = mmu_psize_defs[psize].shift; \
+ for (index = 0; va < __end; index++, va += (1L << shift)) { \
+ if (!__split || __rpte_sub_valid(rpte, index)) do { \
+
+#define pte_iterate_hashed_end() } while(0); } } while(0)
+
+#define pte_pagesize_index(mm, addr, pte) \
+ (((pte) & _PAGE_COMBO)? MMU_PAGE_4K: MMU_PAGE_64K)
+
+#define remap_4k_pfn(vma, addr, pfn, prot) \
+ remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, \
+ __pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
+
+
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+/*
+ * For the sub-page protection option, we extend the PGD with one of
+ * these. Basically we have a 3-level tree, with the top level being
+ * the protptrs array. To optimize speed and memory consumption when
+ * only addresses < 4GB are being protected, pointers to the first
+ * four pages of sub-page protection words are stored in the low_prot
+ * array.
+ * Each page of sub-page protection words protects 1GB (4 bytes
+ * protects 64k). For the 3-level tree, each page of pointers then
+ * protects 8TB.
+ */
+struct subpage_prot_table {
+ unsigned long maxaddr; /* only addresses < this are protected */
+ unsigned int **protptrs[2];
+ unsigned int *low_prot[4];
+};
+
+#undef PGD_TABLE_SIZE
+#define PGD_TABLE_SIZE ((sizeof(pgd_t) << PGD_INDEX_SIZE) + \
+ sizeof(struct subpage_prot_table))
+
+#define SBP_L1_BITS (PAGE_SHIFT - 2)
+#define SBP_L2_BITS (PAGE_SHIFT - 3)
+#define SBP_L1_COUNT (1 << SBP_L1_BITS)
+#define SBP_L2_COUNT (1 << SBP_L2_BITS)
+#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
+#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
+
+extern void subpage_prot_free(pgd_t *pgd);
+
+static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd)
+{
+ return (struct subpage_prot_table *)(pgd + PTRS_PER_PGD);
+}
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
+#endif /* __ASSEMBLY__ */
Index: linux-work/arch/powerpc/include/asm/pte-hash64.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/include/asm/pte-hash64.h 2009-02-25 16:47:28.000000000 +1100
@@ -0,0 +1,47 @@
+#ifndef _ASM_POWERPC_PGTABLE_HASH64_H
+#define _ASM_POWERPC_PGTABLE_HASH64_H
+#ifdef __KERNEL__
+
+/*
+ * Common bits between 4K and 64K pages in a linux-style PTE.
+ * These match the bits in the (hardware-defined) PowerPC PTE as closely
+ * as possible. Additional bits may be defined in pgtable-hash64-*.h
+ */
+#define _PAGE_PRESENT 0x0001 /* software: pte contains a translation */
+#define _PAGE_USER 0x0002 /* matches one of the PP bits */
+#define _PAGE_FILE 0x0002 /* (!present only) software: pte holds file offset */
+#define _PAGE_EXEC 0x0004 /* No execute on POWER4 and newer (we invert) */
+#define _PAGE_GUARDED 0x0008
+#define _PAGE_COHERENT 0x0010 /* M: enforce memory coherence (SMP systems) */
+#define _PAGE_NO_CACHE 0x0020 /* I: cache inhibit */
+#define _PAGE_WRITETHRU 0x0040 /* W: cache write-through */
+#define _PAGE_DIRTY 0x0080 /* C: page changed */
+#define _PAGE_ACCESSED 0x0100 /* R: page referenced */
+#define _PAGE_RW 0x0200 /* software: user write access allowed */
+#define _PAGE_BUSY 0x0800 /* software: PTE & hash are busy */
+
+/* Strong Access Ordering */
+#define _PAGE_SAO (_PAGE_WRITETHRU | _PAGE_NO_CACHE | _PAGE_COHERENT)
+
+#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT)
+
+#define _PAGE_WRENABLE (_PAGE_RW | _PAGE_DIRTY)
+
+/* PTEIDX nibble */
+#define _PTEIDX_SECONDARY 0x8
+#define _PTEIDX_GROUP_IX 0x7
+
+#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | \
+ _PAGE_NO_CACHE | _PAGE_WRITETHRU | \
+ _PAGE_4K_PFN | _PAGE_RW | _PAGE_USER | \
+ _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_EXEC)
+
+
+#ifdef CONFIG_PPC_64K_PAGES
+#include <asm/pte-hash64-64k.h>
+#else
+#include <asm/pte-hash64-4k.h>
+#endif
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_PGTABLE_HASH64_H */
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Mark Nelson @ 2009-02-25 6:52 UTC (permalink / raw)
To: Sachin P. Sant, Geert Uytterhoeven
Cc: Jan Kara, Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton, linux-ext4
In-Reply-To: <49A395ED.5030607@in.ibm.com>
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> Jan Kara wrote:
> > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > somehow got beyond end of the page referenced by bh->b_data. So it means
> > that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> > ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> > particular checks whether e_value_offs + e_value_size isn't greater than
> > bh->b_size. So I see no way how memcpy can get beyond end of the page.
> > Sachin, is the problem reproducible? If yes, can you send us contents
> >
> Yes, i am able to recreate this problem easily. As i had mentioned if the
> earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
> i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
> without any problem.
Hi Sanchin and Geert,
Does the patch below fix the problems you're seeing? If it does I'll send
a properly written up and formatted patch to linuxppc-dev (as well as
another one to fix the same problem in copy_tofrom_user()).
Thanks and sorry again!
Mark
---
arch/powerpc/lib/memcpy_64.S | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
Index: upstream/arch/powerpc/lib/memcpy_64.S
===================================================================
--- upstream.orig/arch/powerpc/lib/memcpy_64.S
+++ upstream/arch/powerpc/lib/memcpy_64.S
@@ -53,18 +53,19 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
3: std r8,8(r3)
beq 3f
addi r3,r3,16
- ld r9,8(r4)
.Ldo_tail:
bf cr7*4+1,1f
- rotldi r9,r9,32
+ lwz r9,8(r4)
+ addi r4,r4,4
stw r9,0(r3)
addi r3,r3,4
1: bf cr7*4+2,2f
- rotldi r9,r9,16
+ lhz r9,8(r4)
+ addi r4,r4,2
sth r9,0(r3)
addi r3,r3,2
2: bf cr7*4+3,3f
- rotldi r9,r9,8
+ lbz r9,8(r4)
stb r9,0(r3)
3: ld r3,48(r1) /* return dest pointer */
blr
@@ -133,11 +134,24 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
cmpwi cr1,r5,8
addi r3,r3,32
sld r9,r9,r10
- ble cr1,.Ldo_tail
+ ble cr1,6f
ld r0,8(r4)
srd r7,r0,r11
or r9,r7,r9
- b .Ldo_tail
+6:
+ bf cr7*4+1,1f
+ rotldi r9,r9,32
+ stw r9,0(r3)
+ addi r3,r3,4
+1: bf cr7*4+2,2f
+ rotldi r9,r9,16
+ sth r9,0(r3)
+ addi r3,r3,2
+2: bf cr7*4+3,3f
+ rotldi r9,r9,8
+ stb r9,0(r3)
+3: ld r3,48(r1) /* return dest pointer */
+ blr
.Ldst_unaligned:
PPC_MTOCRF 0x01,r6 # put #bytes to 8B bdry into cr7
^ permalink raw reply
* Re: How to bring up fs_enet on 2.6.27?
From: Daniel Ng @ 2009-02-25 7:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Mike Ditto
In-Reply-To: <547eba1b0902192101n323f51ceuf39b9d954b696225@mail.gmail.com>
Hi guys,
I was hoping to have gotten some form of comment by now...
Can anyone help out here, please?
Daniel
On Fri, Feb 20, 2009 at 4:01 PM, Daniel Ng <daniel.ng1234@gmail.com> wrote:
>
> Now, I'm seeing these boot messages:
>
> f0010d40:00 not found
> eth0: Could not attach to PHY
> IP-Config: Failed to open eth0
> IP-Config: Device `eth0' not found.
>
> Previous mailing list discussions suggest that I use the correct PHY,
> which I am sure about because my 8272-based board only has the one PHY
> ie. PHY0 with reg =3D <0x0>.
>
> Note the relevant parts of my Device Tree below. Currently, our PHY
> attributes eg. 'auto-negotiate' are not changeable, so we aren't
> actually using MDC+MDIO even the MDC+MDIO lines exist. Also, the PHY
> interrupt line is not wired up. Hence the PHY0 interrupts field is <0
> 8> (or should it be removed altogether?).
>
> I am usig FCC2.
>
> What might I need to change to get the ethernet driver working?
>
>
> =A0 =A0 =A0ethernet@11320 {
> =A0 =A0 =A0 =A0device_type =3D "network";
> =A0 =A0 =A0 =A0compatible =3D "fsl,mpc8272-fcc-enet",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,cpm2-fcc-enet";
> =A0 =A0 =A0 =A0// FCC2-
> =A0 =A0 =A0 =A0reg =3D <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
> =A0 =A0 =A0 =A0local-mac-address =3D [ 00 00 00 00 00 00 ];
> =A0 =A0 =A0 =A0interrupts =3D <33 8>;
> =A0 =A0 =A0 =A0interrupt-parent =3D <&PIC>;
> =A0 =A0 =A0 =A0phy-handle =3D <&PHY0>;
> =A0 =A0 =A0 =A0linux,network-index =3D <0>;
> =A0 =A0 =A0 =A0fsl,cpm-command =3D <0x16200300>;
> =A0 =A0 =A0};
>
> =A0 =A0 =A0mdio@10d40 {
> =A0 =A0 =A0 =A0device_type =3D "mdio";
> =A0 =A0 =A0 =A0compatible =3D "fsl,mpc8272ads-mdio-bitbang",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,mpc8272-mdio-bitbang",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,cpm2-mdio-bitbang";
> =A0 =A0 =A0 =A0reg =3D <0x10d40 0x14>;
> =A0 =A0 =A0 =A0#address-cells =3D <1>;
> =A0 =A0 =A0 =A0#size-cells =3D <0>;
> =A0 =A0 =A0 =A0fsl,mdio-pin =3D <5>;
> =A0 =A0 =A0 =A0fsl,mdc-pin =3D <19>;
>
> =A0 =A0 =A0 =A0PHY0: ethernet-phy@0 {
> =A0 =A0 =A0 =A0 =A0interrupt-parenn =3D <&PIC>;
> =A0 =A0 =A0 =A0 =A0interrupts =3D <0 8>;
> =A0 =A0 =A0 =A0 =A0reg =3D <0x0>;
> =A0 =A0 =A0 =A0 =A0device_type =3D "ethernet-phy";
> =A0 =A0 =A0 =A0};
> .
> .
> .
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PIC: interrupt-controller@10c00 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#interrupt-cells =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-controller;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x10c00 0x80>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc827=
2-pic", "fsl,cpm2-pic";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> Cheers,
> Daniel
>
^ permalink raw reply
* Re: [PATCH 0/10] DMA-API debugging facility
From: David Woodhouse @ 2009-02-25 8:11 UTC (permalink / raw)
To: Joerg Roedel, linuxppc-dev
Cc: netdev, linux-kernel, iommu, Ingo Molnar, Ingo Molnar,
Thomas Gleixner
In-Reply-To: <1233873842.8135.6.camel@macbook.infradead.org>
On Thu, 2009-02-05 at 22:44 +0000, David Woodhouse wrote:
> On Fri, 2008-11-21 at 18:27 +0100, Joerg Roedel wrote:
> > On Fri, Nov 21, 2008 at 05:24:29PM +0000, David Woodhouse wrote:
> > > On Fri, 2008-11-21 at 18:20 +0100, Joerg Roedel wrote:
> > > > Ok, I will move the generic bits to lib/ and include/linux and let
> > > > architectures decide if they want to use it.
> > >
> > > Once you've done that, I'll try to hook it up on PowerPC to make sure it
> > > works there.
> >
> > Ok, cool. Thanks
>
> This builds; I haven't actually tried booting it yet. Will do that in
> the morning.
So I lied about that. Did anyone else manage...?
(Applies on top of the dma-api/debug branch of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu)
> I'm not so fond of the way each architecture gets to define
> PREALLOC_DMA_DEBUG_ENTRIES for itself... and also call dma_debug_init(),
> for that matter. Couldn't we do that in lib/dma-debug.c directly?
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 74cc312..11db356 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -124,6 +124,7 @@ config PPC
> select USE_GENERIC_SMP_HELPERS if SMP
> select HAVE_OPROFILE
> select HAVE_SYSCALL_WRAPPERS if PPC64
> + select HAVE_DMA_API_DEBUG
>
> config EARLY_PRINTK
> bool
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index 86cef7d..b49107a 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -13,6 +13,7 @@
> /* need struct page definitions */
> #include <linux/mm.h>
> #include <linux/scatterlist.h>
> +#include <linux/dma-debug.h>
> #include <linux/dma-attrs.h>
> #include <asm/io.h>
>
> @@ -170,12 +171,17 @@ static inline dma_addr_t dma_map_single_attrs(struct device *dev,
> struct dma_attrs *attrs)
> {
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
> + dma_addr_t addr;
>
> BUG_ON(!dma_ops);
>
> - return dma_ops->map_page(dev, virt_to_page(cpu_addr),
> + addr = dma_ops->map_page(dev, virt_to_page(cpu_addr),
> (unsigned long)cpu_addr % PAGE_SIZE, size,
> direction, attrs);
> + debug_dma_map_page(dev, virt_to_page(cpu_addr),
> + (unsigned long)cpu_addr & PAGE_SIZE, size,
> + direction, addr, true);
> + return addr;
> }
>
> static inline void dma_unmap_single_attrs(struct device *dev,
> @@ -189,6 +195,7 @@ static inline void dma_unmap_single_attrs(struct device *dev,
> BUG_ON(!dma_ops);
>
> dma_ops->unmap_page(dev, dma_addr, size, direction, attrs);
> + debug_dma_unmap_page(dev, dma_addr, size, direction, true);
> }
>
> static inline dma_addr_t dma_map_page_attrs(struct device *dev,
> @@ -198,10 +205,13 @@ static inline dma_addr_t dma_map_page_attrs(struct device *dev,
> struct dma_attrs *attrs)
> {
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
> + dma_addr_t addr;
>
> BUG_ON(!dma_ops);
>
> - return dma_ops->map_page(dev, page, offset, size, direction, attrs);
> + addr = dma_ops->map_page(dev, page, offset, size, direction, attrs);
> + debug_dma_map_page(dev, page, offset, size, direction, addr, false);
> + return addr;
> }
>
> static inline void dma_unmap_page_attrs(struct device *dev,
> @@ -215,6 +225,7 @@ static inline void dma_unmap_page_attrs(struct device *dev,
> BUG_ON(!dma_ops);
>
> dma_ops->unmap_page(dev, dma_address, size, direction, attrs);
> + debug_dma_unmap_page(dev, dma_address, size, direction, false);
> }
>
> static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
> @@ -222,9 +233,12 @@ static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
> struct dma_attrs *attrs)
> {
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
> + int ents;
>
> BUG_ON(!dma_ops);
> - return dma_ops->map_sg(dev, sg, nents, direction, attrs);
> + ents = dma_ops->map_sg(dev, sg, nents, direction, attrs);
> + debug_dma_map_sg(dev, sg, ents, direction);
> + return ents;
> }
>
> static inline void dma_unmap_sg_attrs(struct device *dev,
> @@ -237,15 +251,19 @@ static inline void dma_unmap_sg_attrs(struct device *dev,
>
> BUG_ON(!dma_ops);
> dma_ops->unmap_sg(dev, sg, nhwentries, direction, attrs);
> + debug_dma_unmap_sg(dev, sg, nhwentries, direction);
> }
>
> static inline void *dma_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
> + void *mem;
>
> BUG_ON(!dma_ops);
> - return dma_ops->alloc_coherent(dev, size, dma_handle, flag);
> + mem = dma_ops->alloc_coherent(dev, size, dma_handle, flag);
> + debug_dma_alloc_coherent(dev, size, *dma_handle, mem);
> + return mem;
> }
>
> static inline void dma_free_coherent(struct device *dev, size_t size,
> @@ -254,6 +272,7 @@ static inline void dma_free_coherent(struct device *dev, size_t size,
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
>
> BUG_ON(!dma_ops);
> + debug_dma_free_coherent(dev, size, cpu_addr, dma_handle);
> dma_ops->free_coherent(dev, size, cpu_addr, dma_handle);
> }
>
> @@ -306,6 +325,8 @@ static inline void dma_sync_single_for_cpu(struct device *dev,
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
>
> BUG_ON(!dma_ops);
> + debug_dma_sync_single_range_for_cpu(dev, dma_handle, 0,
> + size, direction);
> dma_ops->sync_single_range_for_cpu(dev, dma_handle, 0,
> size, direction);
> }
> @@ -317,6 +338,8 @@ static inline void dma_sync_single_for_device(struct device *dev,
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
>
> BUG_ON(!dma_ops);
> + debug_dma_sync_single_range_for_device(dev, dma_handle,
> + 0, size, direction);
> dma_ops->sync_single_range_for_device(dev, dma_handle,
> 0, size, direction);
> }
> @@ -328,6 +351,7 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
>
> BUG_ON(!dma_ops);
> + debug_dma_sync_sg_for_cpu(dev, sgl, nents, direction);
> dma_ops->sync_sg_for_cpu(dev, sgl, nents, direction);
> }
>
> @@ -338,6 +362,7 @@ static inline void dma_sync_sg_for_device(struct device *dev,
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
>
> BUG_ON(!dma_ops);
> + debug_dma_sync_sg_for_device(dev, sgl, nents, direction);
> dma_ops->sync_sg_for_device(dev, sgl, nents, direction);
> }
>
> @@ -348,6 +373,8 @@ static inline void dma_sync_single_range_for_cpu(struct device *dev,
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
>
> BUG_ON(!dma_ops);
> + debug_dma_sync_single_range_for_cpu(dev, dma_handle,
> + offset, size, direction);
> dma_ops->sync_single_range_for_cpu(dev, dma_handle,
> offset, size, direction);
> }
> @@ -359,6 +386,8 @@ static inline void dma_sync_single_range_for_device(struct device *dev,
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
>
> BUG_ON(!dma_ops);
> + debug_dma_sync_single_range_for_device(dev, dma_handle, offset,
> + size, direction);
> dma_ops->sync_single_range_for_device(dev, dma_handle, offset,
> size, direction);
> }
> @@ -367,36 +396,46 @@ static inline void dma_sync_single_for_cpu(struct device *dev,
> dma_addr_t dma_handle, size_t size,
> enum dma_data_direction direction)
> {
> + debug_dma_sync_single_range_for_cpu(dev, dma_handle, 0,
> + size, direction);
> }
>
> static inline void dma_sync_single_for_device(struct device *dev,
> dma_addr_t dma_handle, size_t size,
> enum dma_data_direction direction)
> {
> + debug_dma_sync_single_range_for_device(dev, dma_handle,
> + 0, size, direction);
> }
>
> static inline void dma_sync_sg_for_cpu(struct device *dev,
> struct scatterlist *sgl, int nents,
> enum dma_data_direction direction)
> {
> + debug_dma_sync_sg_for_cpu(dev, sgl, nents, direction);
> }
>
> static inline void dma_sync_sg_for_device(struct device *dev,
> struct scatterlist *sgl, int nents,
> enum dma_data_direction direction)
> {
> + debug_dma_sync_sg_for_device(dev, sgl, nents, direction);
> }
>
> static inline void dma_sync_single_range_for_cpu(struct device *dev,
> dma_addr_t dma_handle, unsigned long offset, size_t size,
> enum dma_data_direction direction)
> {
> + debug_dma_sync_single_range_for_cpu(dev, dma_handle,
> + offset, size, direction);
> }
>
> static inline void dma_sync_single_range_for_device(struct device *dev,
> dma_addr_t dma_handle, unsigned long offset, size_t size,
> enum dma_data_direction direction)
> {
> + debug_dma_sync_single_range_for_device(dev, dma_handle, offset,
> + size, direction);
> }
> #endif
>
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index 1c5c8a6..90bb016 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -6,7 +6,9 @@
> */
>
> #include <linux/device.h>
> +#include <linux/dma-debug.h>
> #include <linux/dma-mapping.h>
> +#include <linux/init.h>
> #include <asm/bug.h>
> #include <asm/abs_addr.h>
>
> @@ -156,3 +158,12 @@ struct dma_mapping_ops dma_direct_ops = {
> #endif
> };
> EXPORT_SYMBOL(dma_direct_ops);
> +
> +#define PREALLOC_DMA_DEBUG_ENTRIES 8192
> +
> +static int __init dma_debug_init_ppc(void)
> +{
> + dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
> + return 0;
> +}
> +fs_initcall(dma_debug_init_ppc);
>
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* PPC 405 EX USB Development
From: Adish Kuvelker @ 2009-02-25 9:15 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
Hello,
I am developing a Host Controller Driver for the PPC405EX based board. I
have a OTG controller on it, which I have to configure as Host Controller
and thus I am witting a HCD for the same. I am stuck at the Control stage
wherein although my SETUP stage seems to be going through I get a STALL.
Can anyone help me in this regard as to where would I get a reference code
for this?
Regards;
Aadish
[-- Attachment #2: Type: text/html, Size: 444 bytes --]
^ permalink raw reply
* defining platform_devices in DTS
From: Pieter @ 2009-02-25 9:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]
Hi all
I am busy porting my board to Linux 2.6.27 from 2.6.19. The old Linux
was compiled using the ppc architecture, and had a "platform_device"
struct ure containing the custom devices on my board. (
/arch/ppc/platform/sdh8548.c and /arch/ppc/platform/sdh8548.h )
I assume these devices should now be declared in the device tree source.
Building the new Linux using the powerpc architecture, but I am
strugeling translating teh information defined in the "platform_device"
to a device tree node. In particular what happens to the resource.flags
could anyone help please?
Below is the "platform_device" definition and my interpretation of how
it should look in the device tree. Am I on the right track?
thanks pieter
platform_device definition:
{
.name = "bio",
.id = 0,
.dev.platform_data = NULL,
.num_resources = 2,
.resource = (struct resource[]) {
{
.start = 0xe0100000,
.end = 0xe0100000 + 0x10000 -1,
.flags = IORESOURCE_MEM, /* 0x00000200 */
},
{
.name = "int",
.start = MPC85xx_IRQ_EXT0, /* 48 +
MPC85xx_OPENPIC_IRQ_OFFSET */
.end = MPC85xx_IRQ_EXT0,
.flags = IORESOURCE_IRQ, /*0x00000400 */
},
},
FDT source:
localbus@e0000000 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "simple-bus";
reg = <0xe0000000 0x5000>;
interrupt-parent = <&mpic>;
ranges = <
0x0 0x0 0xf8000000 0x07ffffff /*128MB Flash*/
0x1 0x0 0xe0200000 0x00200000 /*2MB FPGA*/
0x2 0x0 0xe0100000 0x00100000 /*1MB BIO CPLD*/
>;
bio@2,0 {
compatible = "wrs,epld-localbus";
#address-cells = <2>;
#size-cells = <1>;
//interrupt-parent = <&mpic>;
//interrupts = <48>;
reg = <0x2 0x0 0x0010000>;
ranges = <0x0 0x0 0x2 0x0 0x00100000>;
};
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2722 bytes --]
^ permalink raw reply
* Re: How to bring up fs_enet on 2.6.27?
From: Mike Ditto @ 2009-02-25 9:25 UTC (permalink / raw)
To: Daniel Ng; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <547eba1b0902242309o2086dce2p49c59a9ea1b85b53@mail.gmail.com>
Daniel Ng wrote:
>> Now, I'm seeing these boot messages:
>>
>> f0010d40:00 not found
>> eth0: Could not attach to PHY
Daniel,
These messages are typical of having the wrong GPIO pins in the mdio
node or the wrong MDIO address (reg property) in the ethernet-phy node.
>> Currently, our PHY
>> attributes eg. 'auto-negotiate' are not changeable, so we aren't
>> actually using MDC+MDIO even the MDC+MDIO lines exist.
The driver definitely tries to talk to the PHY using the GPIO pins
and address specified and if it doesn't respond, it won't attach.
>> Also, the PHY
>> interrupt line is not wired up. Hence the PHY0 interrupts field is <0
>> 8> (or should it be removed altogether?).
The mdio driver works without interrupts. I have no interrupt-parent
or interrupts properties on my ethernet-phy node.
-=] Mike [=-
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Geert Uytterhoeven @ 2009-02-25 9:50 UTC (permalink / raw)
To: Mark Nelson
Cc: Jan Kara, Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton, linux-ext4
In-Reply-To: <200902251752.56514.markn@au1.ibm.com>
On Wed, 25 Feb 2009, Mark Nelson wrote:
> On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> > Jan Kara wrote:
> > > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > > somehow got beyond end of the page referenced by bh->b_data. So it means
> > > that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> > > ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> > > particular checks whether e_value_offs + e_value_size isn't greater than
> > > bh->b_size. So I see no way how memcpy can get beyond end of the page.
> > > Sachin, is the problem reproducible? If yes, can you send us contents
> > >
> > Yes, i am able to recreate this problem easily. As i had mentioned if the
> > earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
> > i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
> > without any problem.
>
> Hi Sanchin and Geert,
>
> Does the patch below fix the problems you're seeing? If it does I'll send
> a properly written up and formatted patch to linuxppc-dev (as well as
> another one to fix the same problem in copy_tofrom_user()).
Unfortunately not, now it crashes while accessing the memory pointed to by
GPR16, in
NIP: copy_page_range+x0608/0x628
LR: dup_mm+0x2e4/0x428
Trace: debug_table+0xcc70/0x1afe0 (unreliable)
dup_mm+0x2e4/0x428
copy_process+0x86c/0xf9c
do_fork+0x188/0x39c
sys_clone+0x58/0x70
ppc_clone+0x8/0xc
However, after reverting 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556, I still see
similar problems as above (crash in copy_page_range()).
Which makes me think that
1. Your new patch fixes the problem introduced by 25d6e2d7,
2. There's still another issue than the one introduced by 25d6e2d7.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-02-25 9:54 UTC (permalink / raw)
To: David Woodhouse
Cc: Alessandro Zummo, Richard Zidlicky, rtc-linux, linux-parisc,
David, Linux Kernel Development, Kyle McMartin,
Linux/PPC Development, Linux/m68k
In-Reply-To: <1235511327.18632.73.camel@macbook.infradead.org>
On Wed, 25 Feb 2009, David Woodhouse wrote:
> On Mon, 2009-02-23 at 13:34 +0100, Geert Uytterhoeven wrote:
> > > my opinion on this kind of stuff is that I want to avoid the layering
> > > of implementations under the rtc subsystem. I'd rather prefer that each
> > > rtc device had its own driver.
> > >
> > > I've made error in the past, by accepting such kind of drivers, and
> > > would like to avoid that it happens again.
> >
> > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> > mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> > RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
>
> That's the ideal... although did we get NTP sync working again yet?
>
> The rtc-ppc driver was intended as a short-term workaround so that we
> can enable the generic RTC class (which was required for PA Semi
> Electra, iirc), and still have stuff work on other platforms.
Sure. The only differences between your rtc-ppc driver and rtc-parisc were:
- rtc-ppc uses the PPC RTC abstraction (ppc_md.[gs]et_rtc_time()),
while rtc-parisc uses the genrtc abstraction layer ([gs]et_rtc_time()),
which is shared by several architectures,
- rtc-ppc has the platform device built-in in the driver, while rtc-parisc
relies on the creation of the platform device in platform code.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ 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