* [2.6 patch] drivers/of/of_i2c.c: add MODULE_LICENSE
From: Adrian Bunk @ 2008-04-23 9:51 UTC (permalink / raw)
To: Jochen Friedrich, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
After commit 585468e5d5962660867c269e26f0a4b89a599473
([POWERPC] i2c: Fix build breakage introduced by OF helpers)
drivers/of/of_i2c.c needs a MODULE_LICENSE.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
drivers/of/of_i2c.c | 3 +++
1 file changed, 3 insertions(+)
946ca8103416a313577b0b9d52d30541fe7eef85 diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 6316891..715a444 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -13,6 +13,7 @@
#include <linux/i2c.h>
#include <linux/of.h>
+#include <linux/module.h>
struct i2c_driver_device {
char *of_device;
@@ -113,3 +114,5 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
+
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* [2.6 patch] char/xilinx_hwicap/ section fix
From: Adrian Bunk @ 2008-04-23 9:51 UTC (permalink / raw)
To: Stephen Neuendorffer, Grant Likely, paulus; +Cc: linuxppc-dev, linux-kernel
This patch fixes the following build error:
<-- snip -->
...
CC [M] drivers/char/xilinx_hwicap/xilinx_hwicap.o
...
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/xilinx_hwicap/xilinx_hwicap.c:806: error: hwicap_of_match causes a section type conflict
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/xilinx_hwicap/xilinx_hwicap.c:806: error: hwicap_of_match causes a section type conflict
make[4]: *** [drivers/char/xilinx_hwicap/xilinx_hwicap.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
2f0f31d8aa696ca6cc45ab865ec8c68b90cd0e46 diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 016f905..dfe6907 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -803,7 +803,7 @@ static int __devexit hwicap_of_remove(struct of_device *op)
}
/* Match table for of_platform binding */
-static const struct of_device_id __devinit hwicap_of_match[] = {
+static const struct of_device_id __devinitconst hwicap_of_match[] = {
{ .compatible = "xlnx,opb-hwicap-1.00.b", .data = &buffer_icap_config},
{ .compatible = "xlnx,xps-hwicap-1.00.a", .data = &fifo_icap_config},
{},
^ permalink raw reply related
* Re: [Linux-fbdev-devel] [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
From: David Miller @ 2008-04-23 9:57 UTC (permalink / raw)
To: michel
Cc: linux-fbdev-devel, hollisb, adaplas, linux-kernel, linuxppc-dev,
akpm, dzu
In-Reply-To: <1208943127.5632.324.camel@thor.sulgenrain.local>
From: Michel D=E4nzer <michel@tungstengraphics.com>
Date: Wed, 23 Apr 2008 11:32:07 +0200
> On Wed, 2008-04-23 at 08:21 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote:
> > > I wanted to ask if there are any known workarounds atm that would=
> > > allow me to use my X11 for now?
> > =
> > X is doing a mmap of /dev/mem instead of /dev/fb ?
> > =
> > You can normally map the fb mapping /dev/fb and then map the regist=
ers
> > using /dev/fb at an offset beyond the framebuffer (fix->smem_len).
> > =
> > If X is using /dev/mem instead, then it's being stupid and needs to=
be
> > fixed...
> =
> It's up to the driver, and again, the current radeon driver doesn't u=
se
> radeonfb at all anymore...
The only portable thing is for X to use the PCI sysfs mmap() stuff,
which current Xorg servers using libpciaccess do.
I know because I'm typing this from a sparc64 using a Radeon
with current Xorg :-)
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
From: Benjamin Herrenschmidt @ 2008-04-23 10:34 UTC (permalink / raw)
To: David Miller
Cc: linux-fbdev-devel, adaplas, hollisb, linux-kernel, michel,
linuxppc-dev, akpm, dzu
In-Reply-To: <20080423.025721.50367920.davem@davemloft.net>
On Wed, 2008-04-23 at 02:57 -0700, David Miller wrote:
> > It's up to the driver, and again, the current radeon driver doesn't
> use
> > radeonfb at all anymore...
>
> The only portable thing is for X to use the PCI sysfs mmap() stuff,
> which current Xorg servers using libpciaccess do.
>
> I know because I'm typing this from a sparc64 using a Radeon
> with current Xorg :-)
True :-) But I'd still like to fix the fb API for the sake of things
like directfb etc...
Ben.
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jean Delvare @ 2008-04-23 11:09 UTC (permalink / raw)
To: Stefan Roese; +Cc: Alessandro Zummo, rtc-linux, linuxppc-dev, i2c
In-Reply-To: <200804211412.49201.sr@denx.de>
On Mon, 21 Apr 2008 14:12:48 +0200, Stefan Roese wrote:
> On Monday 21 April 2008, Laurent Pinchart wrote:
> > > > > Is there any chance they will got to 2.6.26?
> > > >
> > > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > > under the impression that the powerpc folks are tired of having to wait
> > > > for me and may push it to Linus through their tree? That would be fine
> > > > with me, as I don't want to be the one delaying something many
> > > > developers want (but I also can't sign patches I've not even read.)
> >
> > The patches are required for long awaited I2C support on various PowerPC
> > boards. As the ppc architecture support is going away in 2.6.27, it would
> > be nice to have them applied in 2.6.26.
>
> Yes, please.
I know that many people would like to see these patches upstream
quickly, no question about that. The problem is that I am very busy
with my day job and my family life these days so I just don't know when
I will find the time an energy to go through this huge patch set.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: Sergei Shtylyov @ 2008-04-23 11:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <1208895496.9212.671.camel@pmac.infradead.org>
David Woodhouse wrote:
>>>>Ok. I'll submit a new patch as soon as we agree on a compatible name.
>>>Did we?
>> IIRC, The latest agreement was that we don't need the "compatible" and
>>will match on node name.
> Ok. Is there a current patch I should be merging?
Looks like it was decided to revert to the platform device method, not
sure why -- so, no changes. Laurent?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jean Delvare @ 2008-04-23 11:16 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev list, Alessandro Zummo, rtc-linux, i2c
In-Reply-To: <200804221612.06745.laurentp@cse-semaphore.com>
Hi Laurent,
On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> Hi Jean,
>
> On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > Jean Delvare wrote:
> > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > under the impression that the powerpc folks are tired of having to wait
> > > for me and may push it to Linus through their tree? That would be fine
> > > with me, as I don't want to be the one delaying something many
> > > developers want (but I also can't sign patches I've not even read.)
I still don't know exactly what happened there... I think I saw some
"OpenFirmware i2c" patches go upstream yesterday? But not the ones
listed below, which I thought they depended upon.
> > The required patches are:
> >
> > http://patchwork.ozlabs.org/linuxppc/patch?id=17833
> > http://patchwork.ozlabs.org/linuxppc/patch?id=17834
> >
> > which are just the forward ported patches you sent to the poweprc mailing
> > list some time ago:
> >
> > http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> > http://patchwork.ozlabs.org/linuxppc/patch?id=16283
>
> Given that the required patches are just forward-ported versions of patches
> you sent (and thus probably reviewed as well :-)), what's the best way to get
> them in 2.6.26 (if at all possible) ?
It's not that easy. A lot of new new-style i2c drivers have shown up in
the kernel since I wrote my patches (themselves derived heavily from
Jon Smirl's). Even if Jochen's patches are based on mine, we still need
to take a careful look on how each driver is modified, I remember for
example that some v4l drivers were using the original new-style driver
binding in a way I did not expect. So I can't just sign these patches
and hope they didn't break anything. It needs care, and this requires
time.
I will do my best to get this done before the 2.6.26 merge window
closes, but I can't promise anything.
--
Jean Delvare
^ permalink raw reply
* Re: [2.6 patch] drivers/of/of_i2c.c: add MODULE_LICENSE
From: Jochen Friedrich @ 2008-04-23 11:25 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080423095134.GZ28933@cs181133002.pp.htv.fi>
Adrian Bunk schrieb:
> After commit 585468e5d5962660867c269e26f0a4b89a599473
> ([POWERPC] i2c: Fix build breakage introduced by OF helpers)
> drivers/of/of_i2c.c needs a MODULE_LICENSE.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: Jochen Friedrich <jochen@scram.de>
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Stefan Roese @ 2008-04-23 11:35 UTC (permalink / raw)
To: Jean Delvare; +Cc: Alessandro Zummo, rtc-linux, linuxppc-dev, i2c
In-Reply-To: <20080423130919.5d55feff@hyperion.delvare>
On Wednesday 23 April 2008, Jean Delvare wrote:
> > > The patches are required for long awaited I2C support on various
> > > PowerPC boards. As the ppc architecture support is going away in
> > > 2.6.27, it would be nice to have them applied in 2.6.26.
> >
> > Yes, please.
>
> I know that many people would like to see these patches upstream
> quickly, no question about that. The problem is that I am very busy
> with my day job and my family life these days
Something I know very well too. ;)
Please don't get we wrong, I didn't want to put additional pressure on you
here. I just wanted to express that I'm waiting for these patches to arrive
upstream quite some time now too.
> so I just don't know when
> I will find the time an energy to go through this huge patch set.
Your hard work is really appreciated. Thanks a lot.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jochen Friedrich @ 2008-04-23 11:45 UTC (permalink / raw)
To: Stefan Roese; +Cc: Alessandro Zummo, rtc-linux, linuxppc-dev, i2c, Jean Delvare
In-Reply-To: <200804231335.08038.sr@denx.de>
Hi Stefan,
> Please don't get we wrong, I didn't want to put additional pressure on you
> here. I just wanted to express that I'm waiting for these patches to arrive
> upstream quite some time now too.
and unfortunately, the longer we wait the more drivers are ported to new-style
and the bigger the patch grows :(.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Laurent Pinchart @ 2008-04-23 12:12 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, rtc-linux, i2c
In-Reply-To: <20080423131657.71d6312f@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]
Hi Jean,
On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> Hi Laurent,
>
> On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> > Hi Jean,
> >
> > On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > > Jean Delvare wrote:
> > > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > > under the impression that the powerpc folks are tired of having to
> > > > wait for me and may push it to Linus through their tree? That would be
> > > > fine with me, as I don't want to be the one delaying something many
> > > > developers want (but I also can't sign patches I've not even read.)
>
> I still don't know exactly what happened there... I think I saw some
> "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> listed below, which I thought they depended upon.
The code that went upstream introduces helper functions to create i2c devices
from information supplied by the OF device tree. It doesn't strictly depend
on the below patches, but the new devices won't be properly bound to a driver
without them.
> > > The required patches are:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17833
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17834
> > >
> > > which are just the forward ported patches you sent to the poweprc
> > > mailing list some time ago:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16283
> >
> > Given that the required patches are just forward-ported versions of
> > patches you sent (and thus probably reviewed as well :-)), what's the best
> > way to get them in 2.6.26 (if at all possible) ?
>
> It's not that easy. A lot of new new-style i2c drivers have shown up in
> the kernel since I wrote my patches (themselves derived heavily from
> Jon Smirl's). Even if Jochen's patches are based on mine, we still need
> to take a careful look on how each driver is modified, I remember for
> example that some v4l drivers were using the original new-style driver
> binding in a way I did not expect. So I can't just sign these patches
> and hope they didn't break anything. It needs care, and this requires
> time.
I won't ask to merge the patches for 2.6.26-rc1 and fix introduced breakages
afterwards, I know how you would react to that :-)
> I will do my best to get this done before the 2.6.26 merge window
> closes, but I can't promise anything.
Nobody will get angry if you can't merge them in time for 2.6.26. But many
people will be happy if you can :-)
Cheers,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC patch 6/9] POWERPC remove -traditional
From: Mathieu Desnoyers @ 2008-04-23 12:14 UTC (permalink / raw)
To: Kyle McMartin, Paul Mackerras
Cc: linuxppc-dev, akpm, Sam Ravnborg, Ingo Molnar, linux-kernel
In-Reply-To: <18446.48624.515912.541936@cargo.ozlabs.ibm.com>
* Paul Mackerras (paulus@samba.org) wrote:
> Mathieu Desnoyers writes:
> > Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> > > This is a no-no for those archs that still use -traditional.
> > > > I dunno if this is a problem for you at the moment and the
> > > > right fix is anyway to nuke -traditional.
> > > >
> > > > Sam
> >
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> > CC: Sam Ravnborg <sam@ravnborg.org>
> > CC: paulus@samba.org
> > CC: linuxppc-dev@ozlabs.org
> > ---
> > arch/powerpc/boot/Makefile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Looks OK. I'll put it in my tree.
>
> Paul.
OK, although it won't be needed with v2 of the stringify with commas.
There seems to be some important details which differ between
-traditional and stdc gcc operation which makes it non-trivial to remove
the -traditional, at least on sparc. Maybe Kyle could tell us a bit more
about the nature of these limitations ?
I would wait a bit before merging until we at least identify what those
limitations are.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Xilinx GPIO driver / CONFIG_OF
From: Johann Baudy @ 2008-04-23 12:48 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
Is there a Xilinx GPIO driver draft that uses CONFIG_OF somewhere?
Thanks in advance,
Johann Baudy
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jean Delvare @ 2008-04-23 12:47 UTC (permalink / raw)
To: Laurent Pinchart, Jochen Friedrich
Cc: linuxppc-dev list, Alessandro Zummo, i2c, rtc-linux
In-Reply-To: <200804231412.40038.laurentp@cse-semaphore.com>
On Wed, 23 Apr 2008 14:12:37 +0200, Laurent Pinchart wrote:
> On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> > I still don't know exactly what happened there... I think I saw some
> > "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> > listed below, which I thought they depended upon.
>
> The code that went upstream introduces helper functions to create i2c devices
> from information supplied by the OF device tree. It doesn't strictly depend
> on the below patches, but the new devices won't be properly bound to a driver
> without them.
OK. So... Out of the 7 patches Jochen sent originally, only 1 ([3/7] OF
helpers for the i2c API) went upstream. Am I correct?
Jochen, I'm a bit confused by the dependencies that exist - or not -
between these 7 patches you sent at once. I thought they had to be
applied in sequence but it seems not? And some of them should
apparently go through me i2c tree but others (e.g. [7/7]) not?
I would appreciate if you could summarize quickly which patches depend
on others in which way. If we can make smaller subsets of patches, that
will be easier for me to review and push upstream on my limited time.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
From: Stefan Roese @ 2008-04-23 12:49 UTC (permalink / raw)
To: u-boot-users; +Cc: Dave Littell, linuxppc-embedded
In-Reply-To: <480EADF4.2020706@verizon.net>
On Wednesday 23 April 2008, Dave Littell wrote:
> I'm working on an AMCC PPC440EPx-based platform that's similar to the
> Sequoia. The board runs pretty well, but occasionally takes exceptions
> both in U-Boot and while running Linux. The exceptions vary from
> Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and
> DTLB Errors, to DSI, etc., which made us believe there's a problem with
> SDRAM.
Yes, this is my first idea too. Almost every time such "random" errors are
seen, SDRAM setup/initialization is the cause for it.
> Sometimes there are simple hard lockups from which even the JTAG
> can't regain control. However, the SDRAM physical/electrical and DDR
> Controller configurations have been investigated in detail (and some
> corrections made) with no resulting improvement in the exception behavior.
Is the SDRAM termination similar to the one used on Sequoia too? Are you using
soldered chips and not DIMM modules? Is ECC available?
> We see problems primarily at 667 MHz but have noted some issues at 533
> MHz as well. Some boards seem particularly susceptible to this while
> others rarely (if ever) exhibit the problem.
>
> At this point all possibilities are on the table and I'm looking for any
> input from anyone with experience (good, bad, or whatever) with this
> processor and/or designs similar to the Sequoia.
If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will
most likely find some references.
Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the
440EPx CHIP 11 errata. I suggest you take a look at this too and see if this
changes your behavior.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: Patches added to powerpc.git master and powerpc-next branches
From: Kumar Gala @ 2008-04-23 12:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18445.11801.422321.151268@cargo.ozlabs.ibm.com>
On Apr 21, 2008, at 7:15 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> Once again I want to go through it carefully and understand how it
>>> all
>>> works, and in particular understand things like the way it ensures
>>> that the base address for the kmap region is aligned to a 4M
>>> boundary
>>> so all the kmap ptes are in a single page (assuming it does :).
>>
>> I'm not clear on why this is needed. I can see value in having the
>> PGD entry in place but the pte PAs would be changing all the time
>> so I
>> don't see what benefit there is in keeping them in one page.
>
> Have a look at map_new_virtual in mm/highmem.c. In particular:
>
> set_pte_at(&init_mm, vaddr,
> &(pkmap_page_table[last_pkmap_nr]), mk_pte(page,
> kmap_prot));
>
> assumes that the ptes that kmap uses are in a contiguous array whose
> base is pkmap_page_table.
>
>> For normal kmap ptes we cover things in one PGD via:
>>
>> #define PKMAP_BASE ((FIXADDR_BOOT_START -
>> PAGE_SIZE*(LAST_PKMAP +
>> 1)) & PMD_MASK)
>
> OK, that probably does the trick ... <checks> ... yes it does.
>
> We seem to have a distinction without a difference between
> FIXADDR_START and FIXADDR_BOOT_START, and similarly between
> __FIXADDR_SIZE and __FIXADDR_BOOT_SIZE. Is there any actual
> difference and if not why do we have two names for the same thing?
>
>
> Also, we seem to have an unnecessary distinction (and unnecessary
> casting) between __FIXADDR_TOP and FIXADDR_TOP.
its left over from the x86 port. I'll get rid of __FIXADDR_BOOT_SIZE,
FIXADDR_BOOT_START, and __FIXADDR_TOP.
If we want the early ioremap support in the future we can add back
__FIXADDR_BOOT_SIZE and FIXADDR_BOOT_START.
- k
^ permalink raw reply
* [PATCH v2] [POWERPC] Port fixmap from x86 and use for kmap_atomic
From: Kumar Gala @ 2008-04-23 13:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The fixmap code from x86 allows us to have compile time virtual addresses
that we change the physical addresses of at run time.
This is useful for applications like kmap_atomic, PCI config that is done
via direct memory map, kexec/kdump.
We got ride of CONFIG_HIGHMEM_START as we can now determine a more optimal
location for PKMAP_BASE based on where the fixmap addresses start and
working back from there.
Additionally, the kmap code in asm-powerpc/highmem.h always had debug
enabled. Moved to using CONFIG_DEBUG_HIGHMEM to determine if we should
have the extra debug checking.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Removed __FIXADDR_TOP, __FIXADDR_BOOT_SIZE, and FIXADDR_BOOT_START
as they were duplicates of other defines and held over from the initial
x86 port.
- k
arch/powerpc/Kconfig | 14 -----
arch/powerpc/mm/init_32.c | 8 ---
arch/powerpc/mm/mem.c | 32 ++++++++++--
arch/powerpc/mm/pgtable_32.c | 23 +++++++++
include/asm-powerpc/fixmap.h | 108 +++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/highmem.h | 41 ++++++++-------
6 files changed, 179 insertions(+), 47 deletions(-)
create mode 100644 include/asm-powerpc/fixmap.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fdc755a..20f45a8 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -626,20 +626,6 @@ config ADVANCED_OPTIONS
comment "Default settings for advanced configuration options are used"
depends on !ADVANCED_OPTIONS
-config HIGHMEM_START_BOOL
- bool "Set high memory pool address"
- depends on ADVANCED_OPTIONS && HIGHMEM
- help
- This option allows you to set the base address of the kernel virtual
- area used to map high memory pages. This can be useful in
- optimizing the layout of kernel virtual memory.
-
- Say N here unless you know what you are doing.
-
-config HIGHMEM_START
- hex "Virtual start address of high memory pool" if HIGHMEM_START_BOOL
- default "0xfe000000"
-
config LOWMEM_SIZE_BOOL
bool "Set maximum low memory"
depends on ADVANCED_OPTIONS
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 578750e..1952b4d 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -71,14 +71,6 @@ unsigned long agp_special_page;
EXPORT_SYMBOL(agp_special_page);
#endif
-#ifdef CONFIG_HIGHMEM
-pte_t *kmap_pte;
-pgprot_t kmap_prot;
-
-EXPORT_SYMBOL(kmap_prot);
-EXPORT_SYMBOL(kmap_pte);
-#endif
-
void MMU_init(void);
/* XXX should be in current.h -- paulus */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 0062e6b..5ccb579 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -45,6 +45,7 @@
#include <asm/tlb.h>
#include <asm/sections.h>
#include <asm/vdso.h>
+#include <asm/fixmap.h>
#include "mmu_decl.h"
@@ -57,6 +58,20 @@ int init_bootmem_done;
int mem_init_done;
unsigned long memory_limit;
+#ifdef CONFIG_HIGHMEM
+pte_t *kmap_pte;
+pgprot_t kmap_prot;
+
+EXPORT_SYMBOL(kmap_prot);
+EXPORT_SYMBOL(kmap_pte);
+
+static inline pte_t *virt_to_kpte(unsigned long vaddr)
+{
+ return pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k(vaddr),
+ vaddr), vaddr), vaddr);
+}
+#endif
+
int page_is_ram(unsigned long pfn)
{
unsigned long paddr = (pfn << PAGE_SHIFT);
@@ -311,14 +326,19 @@ void __init paging_init(void)
unsigned long top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
+#ifdef CONFIG_PPC32
+ unsigned long v = __fix_to_virt(__end_of_fixed_addresses - 1);
+ unsigned long end = __fix_to_virt(FIX_HOLE);
+
+ for (; v < end; v += PAGE_SIZE)
+ map_page(v, 0, 0); /* XXX gross */
+#endif
+
#ifdef CONFIG_HIGHMEM
map_page(PKMAP_BASE, 0, 0); /* XXX gross */
- pkmap_page_table = pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k
- (PKMAP_BASE), PKMAP_BASE), PKMAP_BASE), PKMAP_BASE);
- map_page(KMAP_FIX_BEGIN, 0, 0); /* XXX gross */
- kmap_pte = pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k
- (KMAP_FIX_BEGIN), KMAP_FIX_BEGIN), KMAP_FIX_BEGIN),
- KMAP_FIX_BEGIN);
+ pkmap_page_table = virt_to_kpte(PKMAP_BASE);
+
+ kmap_pte = virt_to_kpte(__fix_to_virt(FIX_KMAP_BEGIN));
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 64c44bc..80d1bab 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -29,6 +29,7 @@
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
+#include <asm/fixmap.h>
#include <asm/io.h>
#include "mmu_decl.h"
@@ -387,3 +388,25 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
change_page_attr(page, numpages, enable ? PAGE_KERNEL : __pgprot(0));
}
#endif /* CONFIG_DEBUG_PAGEALLOC */
+
+static int fixmaps;
+unsigned long FIXADDR_TOP = 0xfffff000;
+EXPORT_SYMBOL(FIXADDR_TOP);
+
+void __set_fixmap (enum fixed_addresses idx, phys_addr_t phys, pgprot_t flags)
+{
+ unsigned long address = __fix_to_virt(idx);
+
+ if (idx >= __end_of_fixed_addresses) {
+ BUG();
+ return;
+ }
+
+ map_page(address, phys, flags);
+ fixmaps++;
+}
+
+void __this_fixmap_does_not_exist(void)
+{
+ WARN_ON(1);
+}
diff --git a/include/asm-powerpc/fixmap.h b/include/asm-powerpc/fixmap.h
new file mode 100644
index 0000000..974b6de
--- /dev/null
+++ b/include/asm-powerpc/fixmap.h
@@ -0,0 +1,108 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ *
+ * Copyright 2008 Freescale Semiconductor Inc.
+ * Port to powerpc added by Kumar Gala
+ */
+
+#ifndef _ASM_FIXMAP_H
+#define _ASM_FIXMAP_H
+
+extern unsigned long FIXADDR_TOP;
+
+#ifndef __ASSEMBLY__
+#include <linux/kernel.h>
+#include <asm/page.h>
+#ifdef CONFIG_HIGHMEM
+#include <linux/threads.h>
+#include <asm/kmap_types.h>
+#endif
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process. We allocate these special addresses
+ * from the end of virtual memory (0xfffff000) backwards.
+ * Also this lets us do fail-safe vmalloc(), we
+ * can guarantee that these special addresses and
+ * vmalloc()-ed addresses never overlap.
+ *
+ * these 'compile-time allocated' memory buffers are
+ * fixed-size 4k pages. (or larger if used with an increment
+ * highger than 1) use fixmap_set(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ * TLB entries of such buffers will not be flushed across
+ * task switches.
+ */
+enum fixed_addresses {
+ FIX_HOLE,
+#ifdef CONFIG_HIGHMEM
+ FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
+ FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
+#endif
+ /* FIX_PCIE_MCFG, */
+ __end_of_fixed_addresses
+};
+
+extern void __set_fixmap (enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL)
+/*
+ * Some hardware wants to get fixmapped without caching.
+ */
+#define set_fixmap_nocache(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
+
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, __pgprot(0))
+
+#define __FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
+
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
+#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
+
+extern void __this_fixmap_does_not_exist(void);
+
+/*
+ * 'index to address' translation. If anyone tries to use the idx
+ * directly without tranlation, we catch the bug with a NULL-deference
+ * kernel oops. Illegal ranges of incoming indices are caught too.
+ */
+static __always_inline unsigned long fix_to_virt(const unsigned int idx)
+{
+ /*
+ * this branch gets completely eliminated after inlining,
+ * except when someone tries to use fixaddr indices in an
+ * illegal way. (such as mixing up address types or using
+ * out-of-range indices).
+ *
+ * If it doesn't get removed, the linker will complain
+ * loudly with a reasonably clear error message..
+ */
+ if (idx >= __end_of_fixed_addresses)
+ __this_fixmap_does_not_exist();
+
+ return __fix_to_virt(idx);
+}
+
+static inline unsigned long virt_to_fix(const unsigned long vaddr)
+{
+ BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+ return __virt_to_fix(vaddr);
+}
+
+#endif /* !__ASSEMBLY__ */
+#endif
diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
index f7b21ee..5d99b64 100644
--- a/include/asm-powerpc/highmem.h
+++ b/include/asm-powerpc/highmem.h
@@ -27,9 +27,7 @@
#include <asm/kmap_types.h>
#include <asm/tlbflush.h>
#include <asm/page.h>
-
-/* undef for production */
-#define HIGHMEM_DEBUG 1
+#include <asm/fixmap.h>
extern pte_t *kmap_pte;
extern pgprot_t kmap_prot;
@@ -40,14 +38,12 @@ extern pte_t *pkmap_page_table;
* easily, subsequent pte tables have to be allocated in one physical
* chunk of RAM.
*/
-#define PKMAP_BASE CONFIG_HIGHMEM_START
#define LAST_PKMAP (1 << PTE_SHIFT)
#define LAST_PKMAP_MASK (LAST_PKMAP-1)
+#define PKMAP_BASE ((FIXADDR_START - PAGE_SIZE*(LAST_PKMAP + 1)) & PMD_MASK)
#define PKMAP_NR(virt) ((virt-PKMAP_BASE) >> PAGE_SHIFT)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) << PAGE_SHIFT))
-#define KMAP_FIX_BEGIN (PKMAP_BASE + 0x00400000UL)
-
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
@@ -73,7 +69,7 @@ static inline void kunmap(struct page *page)
* be used in IRQ contexts, so in some (very limited) cases we need
* it.
*/
-static inline void *kmap_atomic(struct page *page, enum km_type type)
+static inline void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t prot)
{
unsigned int idx;
unsigned long vaddr;
@@ -84,34 +80,39 @@ static inline void *kmap_atomic(struct page *page, enum km_type type)
return page_address(page);
idx = type + KM_TYPE_NR*smp_processor_id();
- vaddr = KMAP_FIX_BEGIN + idx * PAGE_SIZE;
-#ifdef HIGHMEM_DEBUG
- BUG_ON(!pte_none(*(kmap_pte+idx)));
+ vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
+#ifdef CONFIG_DEBUG_HIGHMEM
+ BUG_ON(!pte_none(*(kmap_pte-idx)));
#endif
- set_pte_at(&init_mm, vaddr, kmap_pte+idx, mk_pte(page, kmap_prot));
+ set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot));
flush_tlb_page(NULL, vaddr);
return (void*) vaddr;
}
+static inline void *kmap_atomic(struct page *page, enum km_type type)
+{
+ return kmap_atomic_prot(page, type, kmap_prot);
+}
+
static inline void kunmap_atomic(void *kvaddr, enum km_type type)
{
-#ifdef HIGHMEM_DEBUG
+#ifdef CONFIG_DEBUG_HIGHMEM
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
- unsigned int idx = type + KM_TYPE_NR*smp_processor_id();
+ enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
- if (vaddr < KMAP_FIX_BEGIN) { // FIXME
+ if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
pagefault_enable();
return;
}
- BUG_ON(vaddr != KMAP_FIX_BEGIN + idx * PAGE_SIZE);
+ BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
/*
* force other mappings to Oops if they'll try to access
* this pte without first remap it
*/
- pte_clear(&init_mm, vaddr, kmap_pte+idx);
+ pte_clear(&init_mm, vaddr, kmap_pte-idx);
flush_tlb_page(NULL, vaddr);
#endif
pagefault_enable();
@@ -120,12 +121,14 @@ static inline void kunmap_atomic(void *kvaddr, enum km_type type)
static inline struct page *kmap_atomic_to_page(void *ptr)
{
unsigned long idx, vaddr = (unsigned long) ptr;
+ pte_t *pte;
- if (vaddr < KMAP_FIX_BEGIN)
+ if (vaddr < FIXADDR_START)
return virt_to_page(ptr);
- idx = (vaddr - KMAP_FIX_BEGIN) >> PAGE_SHIFT;
- return pte_page(kmap_pte[idx]);
+ idx = virt_to_fix(vaddr);
+ pte = kmap_pte - (idx - FIX_KMAP_BEGIN);
+ return pte_page(*pte);
}
#define flush_cache_kmaps() flush_cache_all()
--
1.5.4.1
^ permalink raw reply related
* [BUG] linux-next: Tree for April 23 - kernel panic during bootup on x86_64 and ppc
From: Kamalesh Babulal @ 2008-04-23 13:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, linuxppc-dev, linux-next, Ingo Molnar, Balbir Singh
In-Reply-To: <20080423190248.2f21b33f.sfr@canb.auug.org.au>
Hi Stephen,
The next-20080423 kernel panics at various points on x86_64 and ppc machines
I have listed the call trace of ppc machine followed by the trace of x86_64
on ppc box
-----------
kernel BUG at arch/powerpc/lib/locks.c:36!
Oops: Exception in kernel mode, sig: 5 [#43]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c000000000031e34 LR: c0000000004b91bc CTR: 0000000000000000
REGS: c000000042043160 TRAP: 0700 Tainted: G D (2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 44000044 XER: 20000006
TASK = c00000007e030000[1] 'swapper' THREAD: c000000042040000 CPU: 5
GPR00: 0000000000000001 c0000000420433e0 c0000000008245a8 c0000000426ef580
GPR04: 0000000000000001 0000000000000000 0000000000000000 0000000000000000
GPR08: c000000041007070 0000000000000001 00000000ffffffff 000000000000ffff
GPR12: 0000000600000004 c00000000073b900 0000000000000000 c000000042536000
GPR16: 4000000002100000 c0000000005f8010 0000000000000000 000000000023f000 Re:
GPR20: 00000000027d69c8 c0000000006d69c8 00000000000000a0 c00000007e95c800
GPR24: c000000042043b10 c000000042043b10 0000000000000000 0000000000000000
GPR28: c0000000426ef500 c0000000008a5b4c c0000000007c3c90 c0000000426ef580
NIP [c000000000031e34] .__spin_yield+0x28/0x80
LR [c0000000004b91bc] ._spin_lock+0x5c/0x88
Call Trace:
[c0000000420433e0] [c000000042043b10] 0xc000000042043b10 (unreliable)
[c000000042043450] [c0000000004b91bc] ._spin_lock+0x5c/0x88
[c0000000420434d0] [c0000000000de66c] .get_unused_fd_flags+0x38/0x174
[c000000042043570] [c00000000012a664] .load_elf_binary+0x18c/0x1670
[c0000000420436b0] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043760] [c000000000126ab0] .load_script+0x274/0x2a0
[c000000042043890] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043940] [c0000000000e7c64] .do_execve+0x180/0x258
[c000000042043a00] [c000000000010714] .sys_execve+0x70/0xac
[c000000042043aa0] [c0000000000086ac] syscall_exit+0x0/0x40
--- Exception: c01 at .kernel_execve+0x8/0x14
LR = .run_init_process+0x28/0x40
[c000000042043d90] [c0000000000f05e4] .sys_dup+0x2c/0x44 (unreliable)
[c000000042043e10] [c000000000009284] .init_post+0x98/0xf8
[c000000042043ea0] [c0000000006a2dc4] .kernel_init+0x38c/0x3c0
[c000000042043f90] [c000000000025304] .kernel_thread+0x4c/0x68
Instruction dump:
7c0803a6 4e800020 7c0802a6 f8010010 f821ff91 81430000 2faa0000 794b0420
2b0b007f 419e0054 7c000026 5400d7fe <0b000000> e8029068 79695564 7d290214
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
[c000000042042c80] [c00000000000f9e8] .show_stack+0x70/0x1bc (unreliable)
[c000000042042d30] [c000000000055704] .panic+0x80/0x1b8
[c000000042042dd0] [c00000000005a270] .do_exit+0x8c/0x758
[c000000042042e90] [c000000000023778] .die+0x24c/0x27c
[c000000042042f30] [c000000000023aa8] ._exception+0x88/0x204
[c0000000420430f0] [c000000000004a84] program_check_common+0x104/0x180
--- Exception: 700 at .__spin_yield+0x28/0x80
LR = ._spin_lock+0x5c/0x88
[c0000000420433e0] [c000000042043b10] 0xc000000042043b10 (unreliable)
[c000000042043450] [c0000000004b91bc] ._spin_lock+0x5c/0x88
[c0000000420434d0] [c0000000000de66c] .get_unused_fd_flags+0x38/0x174
[c000000042043570] [c00000000012a664] .load_elf_binary+0x18c/0x1670
[c0000000420436b0] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043760] [c000000000126ab0] .load_script+0x274/0x2a0
[c000000042043890] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043940] [c0000000000e7c64] .do_execve+0x180/0x258
[c000000042043a00] [c000000000010714] .sys_execve+0x70/0xac
[c000000042043aa0] [c0000000000086ac] syscall_exit+0x0/0x40
--- Exception: c01 at .kernel_execve+0x8/0x14
LR = .run_init_process+0x28/0x40
[c000000042043d90] [c0000000000f05e4] .sys_dup+0x2c/0x44 (unreliable)
[c000000042043e10] [c000000000009284] .init_post+0x98/0xf8
[c000000042043ea0] [c0000000006a2dc4] .kernel_init+0x38c/0x3c0
[c000000042043f90] [c000000000025304] .kernel_thread+0x4c/0x68
Pid: 21, comm: khelper Not tainted 2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest #1
RIP: 0010:[<ffffffff804eaa77>] [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP: 0000:ffff81003fa9beb0 EFLAGS: 00010202
RAX: 0000000000000075 RBX: ffff81003fa8e630 RCX: ffff81003fa9bee0
RDX: ffff81003fa8e7c8 RSI: ffff81003fa9a010 RDI: 0000000000000003
RBP: ffff81003fa9beb0 R08: 0000000000000000 R09: ffff810001026458
R10: ffff81003fa8e630 R11: 0000000300000000 R12: 0000000000000000
R13: ffff81003fa8e758 R14: ffffffff807e9420 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff81003f9a0800(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khelper (pid: 21, threadinfo ffff81003fa9a000, task ffff81003fa8e630)
Stack: ffff81003fa8e630 ffffffff80249cd9 ffff81003fa9bda8 ffff81003fa8e630
ffff81003f9c6000 ffffffff80238a93 ffff81003fa9bee0 ffff81003fa9bee0
ffffffff80646d40 0000000000000000 ffff81003f9a5120 0000000000000000
Call Trace:
[<ffffffff80249cd9>] switch_task_namespaces+0x20/0x54
[<ffffffff80238a93>] ? do_exit+0x4d3/0x661
[<ffffffff80243e58>] ? request_module+0x0/0x15c
[<ffffffff802439f7>] ? __call_usermodehelper+0x0/0x60
[<ffffffff8020cda8>] ? child_rip+0xa/0x12
[<ffffffff802439f7>] ? __call_usermodehelper+0x0/0x60
[<ffffffff80243cfd>] ? ____call_usermodehelper+0x0/0x15b
[<ffffffff8020cd9e>] ? child_rip+0x0/0x12
Code: 33 00 01 75 16 e8 98 f8 d4 ff e8 91 70 d4 ff e8 f2 f4 d4 ff b8 01 00 00 00 eb 02 31 c0 c9 c3 55 48 89 e5 e8 74 e3 d3 ff 83 c0 74 <27> 65 48 8b 04 25 10 00 00 00 f6 80 47 e0 ff ff 10 75 15 83 3d
on x86_64
----------
RIP [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP <ffff81003fa9beb0>
invalid opcode: 0000 [2] <4>---[ end trace ca143223eefdc828 ]---
Fixing recursive fault but reboot is needed!
SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Tainted: G D 2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest #1
RIP: 0010:[<ffffffff804eaa77>] [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP: 0000:ffff81003f9c9e30 EFLAGS: 00010206
RAX: 0000000000000074 RBX: ffffffff806415a0 RCX: 0000000000000000
RDX: 0000000000001312 RSI: ffff81003f9c8010 RDI: 0000000000000003
RBP: ffff81003f9c9e30 R08: 00000000000003c0 R09: 7fffffffffffffff
R10: ffff8100010193c0 R11: 0000000300000000 R12: 00000000fffffff4
R13: ffff81003f9a6500 R14: ffffffff807e9420 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff80688000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff81003f9c8000, task ffff81003f9c6000)
Stack: ffff81003f9c9e80 ffffffff804eb062 000000133f9b60e0 ffffffff80653e00
ffff81003f9a6500 ffffffff802d8e28 ffff81003f9a6500 ffffffff80653e00
ffff81003f9a6550 ffffffff802d897e ffff81003f9a6500 0000000000000000
Call Trace:
[<ffffffff804eb062>] mutex_lock+0x1e/0x2f
[<ffffffff802d8e28>] ? sysfs_addrm_start+0x26/0x9a
[<ffffffff802d897e>] ? sysfs_add_file_mode+0x43/0x74
[<ffffffff807dd223>] ? cpu_dev_init+0x2c/0x79
[<ffffffff807c08bb>] ? kernel_init+0x10a/0x2d9
[<ffffffff804ebd6d>] ? _spin_unlock_irq+0x9/0xd
[<ffffffff80230d5d>] ? finish_task_switch+0x5f/0x86
[<ffffffff8020cda8>] ? child_rip+0xa/0x12
[<ffffffff807c07b1>] ? kernel_init+0x0/0x2d9
[<ffffffff8020cd9e>] ? child_rip+0x0/0x12
Code: 33 00 01 75 16 e8 98 f8 d4 ff e8 91 70 d4 ff e8 f2 f4 d4 ff b8 01 00 00 00 eb 02 31 c0 c9 c3 55 48 89 e5 e8 74 e3 d3 ff 83 c0 74 <27> 65 48 8b 04 25 10 00 00 00 f6 80 47 e0 ff ff 10 75 15 83 3d
RIP [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP <ffff81003f9c9e30>
---[ end trace ca143223eefdc828 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G D 2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest #1
Call Trace:
[<ffffffff80235624>] panic+0x86/0x146
[<ffffffff8023611c>] printk+0x4e/0x56
[<ffffffff80238631>] do_exit+0x71/0x661
[<ffffffff804ec331>] oops_begin+0x0/0x8c
[<ffffffff8020e224>] do_invalid_op+0x87/0x91
[<ffffffff804eaa77>] _cond_resched+0xc/0x38
[<ffffffff804ebd6d>] _spin_unlock_irq+0x9/0xd
[<ffffffff8022bd23>] __wake_up+0x38/0x4e
[<ffffffff804ebf79>] error_exit+0x0/0x51
[<ffffffff804eaa77>] _cond_resched+0xc/0x38
[<ffffffff804eb062>] mutex_lock+0x1e/0x2f
[<ffffffff802d8e28>] sysfs_addrm_start+0x26/0x9a
[<ffffffff802d897e>] sysfs_add_file_mode+0x43/0x74
[<ffffffff807dd223>] cpu_dev_init+0x2c/0x79
[<ffffffff807c08bb>] kernel_init+0x10a/0x2d9
[<ffffffff804ebd6d>] _spin_unlock_irq+0x9/0xd
[<ffffffff80230d5d>] finish_task_switch+0x5f/0x86
[<ffffffff8020cda8>] child_rip+0xa/0x12
[<ffffffff807c07b1>] kernel_init+0x0/0x2d9
[<ffffffff8020cd9e>] child_rip+0x0/0x12
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jon Smirl @ 2008-04-23 13:11 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, i2c, rtc-linux
In-Reply-To: <20080423131657.71d6312f@hyperion.delvare>
On 4/23/08, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Laurent,
>
>
> On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> > Hi Jean,
> >
> > On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > > Jean Delvare wrote:
>
> > > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > > under the impression that the powerpc folks are tired of having to wait
> > > > for me and may push it to Linus through their tree? That would be fine
> > > > with me, as I don't want to be the one delaying something many
> > > > developers want (but I also can't sign patches I've not even read.)
My company has stuck with 2.6.24 and my original patch set. We'd like
to sync back up with mainline at some point.
> I still don't know exactly what happened there... I think I saw some
> "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> listed below, which I thought they depended upon.
>
>
> > > The required patches are:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17833
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17834
> > >
> > > which are just the forward ported patches you sent to the poweprc mailing
> > > list some time ago:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16283
> >
> > Given that the required patches are just forward-ported versions of patches
> > you sent (and thus probably reviewed as well :-)), what's the best way to get
> > them in 2.6.26 (if at all possible) ?
>
>
> It's not that easy. A lot of new new-style i2c drivers have shown up in
> the kernel since I wrote my patches (themselves derived heavily from
> Jon Smirl's). Even if Jochen's patches are based on mine, we still need
> to take a careful look on how each driver is modified, I remember for
> example that some v4l drivers were using the original new-style driver
> binding in a way I did not expect. So I can't just sign these patches
> and hope they didn't break anything. It needs care, and this requires
> time.
>
> I will do my best to get this done before the 2.6.26 merge window
> closes, but I can't promise anything.
>
> --
>
> Jean Delvare
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RE: Xilinx GPIO driver / CONFIG_OF
From: John Linn @ 2008-04-23 13:21 UTC (permalink / raw)
To: Johann Baudy, linuxppc-dev
In-Reply-To: <7e0dd21a0804230548n21a57969pc5f0acb7d9c77e50@mail.gmail.com>
Hi Johann,
Not to my knowledge yet. We have it on our list to do.
Thanks,
John
-----Original Message-----
From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org] On =
Behalf
Of Johann Baudy
Sent: Wednesday, April 23, 2008 6:48 AM
To: linuxppc-dev@ozlabs.org
Subject: Xilinx GPIO driver / CONFIG_OF
Hi All,
Is there a Xilinx GPIO driver draft that uses CONFIG_OF somewhere?
Thanks in advance,
Johann Baudy
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jochen Friedrich @ 2008-04-23 13:26 UTC (permalink / raw)
To: Jean Delvare
Cc: Alessandro Zummo, rtc-linux, linuxppc-dev list, i2c,
Andrew Morton
In-Reply-To: <20080423144756.3fc9b1bf@hyperion.delvare>
Hi Jean,
> Jochen, I'm a bit confused by the dependencies that exist - or not -
> between these 7 patches you sent at once. I thought they had to be
> applied in sequence but it seems not? And some of them should
> apparently go through me i2c tree but others (e.g. [7/7]) not?
[1/7] and [2/7] are forward ports of patches from you. I'm currently
just running a make allmodconfig compile to check if it really caught
all affected i2c drivers.
These are the patches we are talking about.
[3/7] is the OF helper stuff which translates between OF names and
i2c types. It does NOT translate OF names to module names, but relies
on [1/7] to do so. Without [1/7], [3/7] still applies, but module
auto loading won't work.
This has been applied to 2.6.26.
> I would appreciate if you could summarize quickly which patches depend
> on others in which way. If we can make smaller subsets of patches, that
> will be easier for me to review and push upstream on my limited time.
[4/7] is the patch from Jon Smirl to convert i2c-mpc to OF. This relies
on [3/7] instead of Jons initial OF-autoloading patches you didn't like.
As there were no comments at all, I would however postpone this to 2.6.27.
[5/7] is the cleanup patch (originating from you) which completely removes
old driver matching scheme. This should probably wait until 2.6.27, as well.
This relies on [1/7] and [2/7].
[6/7] and [7/7] are a new driver and depend on [3/7]. This can wait for 2.6.27,
as well (i would rather like to see those in -mm to get more testing, though).
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jon Smirl @ 2008-04-23 13:46 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Alessandro Zummo, rtc-linux, linuxppc-dev list, i2c, Jean Delvare,
Andrew Morton
In-Reply-To: <480F390A.90707@scram.de>
On 4/23/08, Jochen Friedrich <jochen@scram.de> wrote:
> Hi Jean,
>
>
> > Jochen, I'm a bit confused by the dependencies that exist - or not -
> > between these 7 patches you sent at once. I thought they had to be
> > applied in sequence but it seems not? And some of them should
> > apparently go through me i2c tree but others (e.g. [7/7]) not?
>
>
> [1/7] and [2/7] are forward ports of patches from you. I'm currently
> just running a make allmodconfig compile to check if it really caught
> all affected i2c drivers.
>
> These are the patches we are talking about.
>
> [3/7] is the OF helper stuff which translates between OF names and
> i2c types. It does NOT translate OF names to module names, but relies
> on [1/7] to do so. Without [1/7], [3/7] still applies, but module
> auto loading won't work.
>
> This has been applied to 2.6.26.
>
>
> > I would appreciate if you could summarize quickly which patches depend
> > on others in which way. If we can make smaller subsets of patches, that
> > will be easier for me to review and push upstream on my limited time.
>
>
> [4/7] is the patch from Jon Smirl to convert i2c-mpc to OF. This relies
> on [3/7] instead of Jons initial OF-autoloading patches you didn't like.
> As there were no comments at all, I would however postpone this to 2.6.27.
This is why we chose to ignore mainline and do these changes in our
own tree. There is no certainty when or if these patches will ever go
in. This has also caused us to stop submitting code in other areas.
It's all intertwined and too much work to break up.
> [5/7] is the cleanup patch (originating from you) which completely removes
> old driver matching scheme. This should probably wait until 2.6.27, as well.
> This relies on [1/7] and [2/7].
>
> [6/7] and [7/7] are a new driver and depend on [3/7]. This can wait for 2.6.27,
> as well (i would rather like to see those in -mm to get more testing, though).
>
> Thanks,
>
> Jochen
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Laurent Pinchart @ 2008-04-23 13:53 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, rtc-linux, i2c
In-Reply-To: <20080423144756.3fc9b1bf@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]
On Wednesday 23 April 2008 14:47, Jean Delvare wrote:
> On Wed, 23 Apr 2008 14:12:37 +0200, Laurent Pinchart wrote:
> > On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> > > I still don't know exactly what happened there... I think I saw some
> > > "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> > > listed below, which I thought they depended upon.
> >
> > The code that went upstream introduces helper functions to create i2c
> > devices from information supplied by the OF device tree. It doesn't
> > strictly depend on the below patches, but the new devices won't be
> > properly bound to a driver without them.
>
> OK. So... Out of the 7 patches Jochen sent originally, only 1 ([3/7] OF
> helpers for the i2c API) went upstream. Am I correct?
>
> Jochen, I'm a bit confused by the dependencies that exist - or not -
> between these 7 patches you sent at once. I thought they had to be
> applied in sequence but it seems not? And some of them should
> apparently go through me i2c tree but others (e.g. [7/7]) not?
>
> I would appreciate if you could summarize quickly which patches depend
> on others in which way. If we can make smaller subsets of patches, that
> will be easier for me to review and push upstream on my limited time.
Here is a summary based on my understanding of the situation. Jochen please
correct me if I'm wrong.
[PATCH1/7] i2c: Add support for device alias names
This patch allows new-style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). It basically
adds device id table found in various subsystems (PCI, USB, ...) to i2c
new-style drivers.
The patch extends the new-style i2c device/driver matching code to support
device id tables. It modifies the drivers accordingly, as the probe function
now takes an extra argument (pointer to the device id entry that matched),
but doesn't add device id tables to the drivers.
[PATCH2/7] i2c: Convert all new-style drivers to use module aliasing
This patch adds the device id tables to the new-style i2c drivers. It depends
on the previous patch.
[PATCH3/7] i2c: OF helpers for the i2c API
This one has already been applied through the ppc subsystem. It adds helper
functions to instantiate i2c devices from the OF device tree. The patch has
no compile time dependencies but relies on 1/7 and 2/7 to bind devices to
drivers at runtime.
[PATCH4/7] i2c: Convert PowerPC MPC i2c to of_platform_driver from
platform_driver
This patch should go through the ppc subsystem. It adds OF device tree support
to the i2c-mpc driver. To the best of my knowledge it depends on 3/7 only.
[PATCH5/7] i2c: Kill the old driver matching scheme
This patch removes the old driver_name/type scheme for i2c driver matching.
Only the new matching scheme introduced by 2/7 remains for new-style drivers.
[PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
This one introduces a new i2c bus driver. It should go through the ppc
subsystem. To the best of my knowledge it depends on 3/7 only.
[PATCH7/7] [POWERPC] Add i2c pins to dts and board setup
This last patch configures i2c pins on various powerpc boards and updates the
associated device trees to include the i2c controller. It should go through
the ppc subsystem. It has no compile-time dependency on any other patch in
the serie.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC POWERPC] booting-without-of: bindings for FHCI USB, GPIO LEDs, MCU, and NAND on UPM
From: Anton Vorontsov @ 2008-04-23 14:01 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804231115.39126.laurentp@cse-semaphore.com>
On Wed, Apr 23, 2008 at 11:15:35AM +0200, Laurent Pinchart wrote:
> Hi Anton,
>
> On Tuesday 22 April 2008 21:41, Anton Vorontsov wrote:
> > Hi all,
> >
> > Here is purposed bindings draft for the new drivers that I would like to
> > send for this or next merge window, depending on results of this RFC. ;-)
> > (The new bindings needs to be in-tree or at least Acked before I could
> > send the drivers.)
> >
> > Comments and suggestions are highly appreciated.
> >
> > Thanks.
> >
> > diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> > index c350623..38fe3e9 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -59,6 +59,11 @@ Table of Contents
> > p) Freescale Synchronous Serial Interface
> > q) USB EHCI controllers
> > r) Freescale General-purpose Timers Module
> > + s) Freescale USB Parameter RAM:
> > + t) Freescale QUICC Engine USB Controller
> > + u) LEDs on GPIOs
> > + v) Freescale MCU with MPC8349E-mITX compatible firmware
> > + w) NAND on UPM-driven Freescale Localbus
> >
> > VII - Marvell Discovery mv64[345]6x System Controller chips
> > 1) The /system-controller node
> > @@ -2866,6 +2871,139 @@ platforms are moved over to use the
> flattened-device-tree model.
> > clock-frequency = <0>;
> > };
> >
> > + s) Freescale USB Parameter RAM:
> > +
> > + Required properties:
> > + - compatible : should be "fsl,<chip>-qe-muram-usb-pram",
> > + "fsl,qe-muram-usb-pram", "fsl,cpm-muram-usb-pram".
> > + - reg : should contain USB PRAM location and length.
> > +
> > + Example:
> > +
> > + usb-pram@8b00 {
> > + compatible = "fsl,mpc8360-qe-muram-usb-pram",
> > + "fsl,qe-muram-usb-pram",
> > + "fsl,cpm-muram-usb-pram";
> > + reg = <0x8b00 0x100>;
> > + };
> > +
> > + t) Freescale QUICC Engine USB Controller
> > +
> > + Required properties:
> > + - compatible : should be "fsl,<chip>-qe-usb", "fsl,qe-usb",
> > + "fsl,usb-fhci"
> > + - reg : should contain gtm registers location and length.
> > + - interrupts : should contain USB interrupt.
> > + - interrupt-parent : interrupt source phandle.
> > + - fsl,fullspeed-clock : specifies the full speed USB clock source.
> > + - fsl,lowspeed-clock : specifies the low speed USB clock source.
> > + - fsl,usb-mode : should be "host".
> > + - linux,hub-power-budget : optional, USB power budget for the root
> hub
> > + in mA.
> > + - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN,
> USBRP,
> > + USBRN, SPEED (optional), and SUSPEND (optional).
>
> Suspend should in my opinion be renamed power (or bus power or anything
> similar), as it controls the USB power and not USB PHY sleep mode.
Thanks, I'll rename it.
> > + Example:
> > +
> > + usb@6c0 {
> > + compatible = "fsl,mpc8360-qe-usb", "fsl,qe-usb",
> > + "fsl,usb-fhci";
> > + reg = <0x6c0 0x40>;
> > + interrupts = <11>;
> > + interrupt-parent = <&qeic>;
> > + fsl,fullspeed-clock = "clk21";
> > + fsl,usb-mode = "host";
> > + gpios = <&qe_pio_b 2 0 /* USBOE */
> > + &qe_pio_b 3 0 /* USBTP */
> > + &qe_pio_b 8 0 /* USBTN */
> > + &qe_pio_b 9 0 /* USBRP */
> > + &qe_pio_b 11 0 /* USBRN */
> > + &qe_pio_e 20 0 /* SPEED */
> > + &qe_pio_e 21 0 /* SUSPN */>;
> > + };
> > +
> > + u) LEDs on GPIOs
> > +
> > + Required properties:
> > + - compatible : should be "linux,gpio-led".
> > + - linux,name : LED name.
> > + - linux,active-low : property should be present if LED wired as
> > + active-low.
>
> Just thinking out loud, wasn't the third GPIO cell supposed to be used to
> encode such properties ?
Oh well, yes, origianally I wrote that it `may' encode this information.
Encoding this would be really useful if node is using many gpios that are
wired in some random inverted/not-inverted way...
gpios <&qe_pio 2 1 /* wired active-low */
&qe_pio 3 0 /* wired active-high */
&qe_pio 4 1 /* wired active-low */
&qe_pio 5 0 /* wired active-high */
&qe_pio 6 1>; /* wired active-low */
But we didn't see this setup yet, and I'm not sure if I want to implement
this support now just for the LEDs. Specifying this information via
gpios = <> property or separate one isn't going to conflict anyhow
and when we'll implement actual flags for GPIOs, we'll easily could
switch to it in backwards compatible way.
Thanks for brining it up though.
> > + - linux,default-trigger : Linux default trigger for this LED.
> > + - linux,brightness : default brightness.
> > + - gpios : should specify LED GPIO.
> > +
> > + Example:
> > +
> > + led@0 {
> > + compatible = "linux,gpio-led";
> > + linux,name = "pwr";
> > + linux,brightness = <1>;
> > + linux,active-low;
> > + gpios = <&mcu_pio 0>;
> > + };
> > +
> > + led@1 {
> > + compatible = "linux,gpio-led";
> > + linux,name = "hdd";
> > + linux,default-trigger = "ide-disk";
> > + linux,active-low;
> > + gpios = <&mcu_pio 1>;
> > + };
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: new warnings from stacktrace patch
From: Christoph Hellwig @ 2008-04-23 14:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <20080423175938.a4b3cc26.sfr@canb.auug.org.au>
On Wed, Apr 23, 2008 at 05:59:38PM +1000, Stephen Rothwell wrote:
> This is from commit fd3e0bbc6052ca9747a5332b382584ece83aab6d ("[POWERPC]
> Stacktrace support for lockdep"). We don't include asm-offsets.h in any
> other C file in the powerpc build.
I think the include can be safely removed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/arch/powerpc/kernel/stacktrace.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/stacktrace.c 2008-04-23 15:28:05.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/stacktrace.c 2008-04-23 15:28:16.000000000 +0200
@@ -13,7 +13,6 @@
#include <linux/sched.h>
#include <linux/stacktrace.h>
#include <asm/ptrace.h>
-#include <asm/asm-offsets.h>
/*
* Save stack-backtrace addresses into a stack_trace buffer.
^ 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