* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-12-14 8:08 UTC (permalink / raw)
To: Olof Johansson; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20071214081210.GB27284@lixom.net>
On Dec 14, 2007, at 2:12 AM, Olof Johansson wrote:
> On Thu, Nov 29, 2007 at 04:13:14PM +0100, Geert Uytterhoeven wrote:
>> On Wed, 28 Nov 2007, Geert Uytterhoeven wrote:
>>> +static inline void warn_emulated_sysctl_register(void)
>>> +{
>>> + int res = register_sysctl_table(warn_emulated_sysctl_root);
>> ^^^^^^^^^^
>>> + printk("@@@ register_sysctl_table() returned %d\n", res);
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +}
>>
>> Woops, that part shouldn't have been there...
>
> Care to resubmit a clean patch under a fresh subject? Paul didn't
> chime
> in but hopefully he can pick it up for 2.6.25.
I'd say wait for Paul to pickup my 2.6.25 request. Than the base will
have the isel emulation as well.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Olof Johansson @ 2007-12-14 8:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <20071214081210.GB27284@lixom.net>
On Fri, Dec 14, 2007 at 02:12:10AM -0600, Olof Johansson wrote:
> Care to resubmit a clean patch under a fresh subject? Paul didn't chime
> in but hopefully he can pick it up for 2.6.25.
Next time I will take the time to re-read the whole thread. :)
Seems like the open question was how to warn only for excessive
amounts of emulated ops. Maybe a simple count/threshold per process
(+ printk_ratelimit)? Warning on every power of 10 occurrances was also
suggested, either works for me.
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Olof Johansson @ 2007-12-14 8:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <77815911-B0FA-4FFD-AC50-5C9A8FED90C4@kernel.crashing.org>
On Fri, Dec 14, 2007 at 02:08:14AM -0600, Kumar Gala wrote:
> I'd say wait for Paul to pickup my 2.6.25 request. Than the base will
> have the isel emulation as well.
It was spotting the isel patch in your queue that made me go back and
look at the thread. :)
-Olof
^ permalink raw reply
* Re: [PATCH] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-12-14 8:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Li Yang
In-Reply-To: <20071207020130.GA26412@localhost.localdomain>
On Dec 6, 2007, at 8:01 PM, David Gibson wrote:
> On Wed, Dec 05, 2007 at 06:37:53PM +0800, Li Yang wrote:
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> Update SATA nodes; remove serdes nodes; add aliases and labels.
>>
>> arch/powerpc/boot/dts/mpc8377_mds.dts | 270 +++++++++++++++++++++++
>> ++++++++
>> arch/powerpc/boot/dts/mpc8378_mds.dts | 256 +++++++++++++++++++++++
>> ++++++
>> arch/powerpc/boot/dts/mpc8379_mds.dts | 284 +++++++++++++++++++++++
>> ++++++++++
>> 3 files changed, 810 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts
>> create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
>> create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/
>> boot/dts/mpc8377_mds.dts
>> new file mode 100644
>> index 0000000..919ffd0
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> [snip]
>> + aliases {
>> + ethernet0 = "/soc@e0000000/ethernet@24000";
>> + ethernet1 = "/soc@e0000000/ethernet@25000";
>> + serial0 = "/soc@e0000000/serial@4500";
>> + serial1 = "/soc@e0000000/serial@4600";
>> + pci0 = "/pci@e0008500";
>
> You can use path references for these now.
>
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,837x@0 {
>
> This should absolutely not have a "x" in it. Either have an exact
> model, or just use "cpu@9" (in which case you can put the model in
> "compatible").
>
> [snip]
>> + i2c@3000 {
>> + device_type = "i2c";
>
> Drop the device_type. No "i2c" device_type class is defined.
>
> [snip]
>> + /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
>> + usb@23000 {
>> + device_type = "usb";
>
> Drop device_type here too.
>
>> + compatible = "fsl-usb2-dr";
>> + reg = <23000 1000>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + interrupt-parent = < &ipic >;
>> + interrupts = <26 8>;
>> + phy_type = "utmi_wide";
>> + };
>> +
>> + mdio@24520 {
>> + device_type = "mdio";
>> + compatible = "gianfar";
>
> Grr... not your fault, but this crap in the gianfar driver where it
> uses the same compatible property for the mdio and MAC has to be
> fixed.
I've fixed this now. Look at my tree/patch.
> [snip]
>
>> + serial1:serial@4600 {
>
> Standard style puts a space after the colon.
>
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <4600 100>;
>> + clock-frequency = <0>;
>> + interrupts = <a 8>;
>> + interrupt-parent = < &ipic >;
>> + };
>> +
>> + crypto@30000 {
>> + model = "SEC3";
>> + compatible = "talitos";
>
> This driver, also, needs fixing to recognize a better formatted
> compatible property.
Can you respin with David's changes as well as mirror my cleanup of
the other 83xx/85xx .dts
- k
^ permalink raw reply
* Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Olof Johansson @ 2007-12-14 8:23 UTC (permalink / raw)
To: Scott Wood
Cc: linux-ide, Paul Mundt, Arnd Bergmann, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071205183912.GA4516@loki.buserror.net>
On Wed, Dec 05, 2007 at 12:39:12PM -0600, Scott Wood wrote:
> On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote:
> > On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> > > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > > > tristate "Generic platform device PATA support"
> > > > - depends on EMBEDDED || ARCH_RPC
> > > > + depends on EMBEDDED || ARCH_PPC
> > >
> > > It needs to be || PPC, not || ARCH_PPC.
> > >
> > Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC.
>
> Why is it dependent on anything other than platform bus support and ATA?
There's no way to specify dependency on platform bus as a config option,
that's likely what EMBEDDED was meant to do. Some platforms have platform
bus in spite of being !EMBEDDED, arch/arm/configs/rpc_defconfig seems
to be among those. PPC too.
-Olof
^ permalink raw reply
* RE: [PATCH] add MPC837x MDS board default device tree
From: Li Yang @ 2007-12-14 8:33 UTC (permalink / raw)
To: Kumar Gala, David Gibson; +Cc: linuxppc-dev
In-Reply-To: <4A496992-9B46-427D-8F40-447E92F8CA3D@kernel.crashing.org>
> >> + device_type =3D "serial";
> >> + compatible =3D "ns16550";
> >> + reg =3D <4600 100>;
> >> + clock-frequency =3D <0>;
> >> + interrupts =3D <a 8>;
> >> + interrupt-parent =3D < &ipic >;
> >> + };
> >> +
> >> + crypto@30000 {
> >> + model =3D "SEC3";
> >> + compatible =3D "talitos";
> >
> > This driver, also, needs fixing to recognize a better formatted=20
> > compatible property.
>=20
> Can you respin with David's changes as well as mirror my=20
> cleanup of the other 83xx/85xx .dts
Sure, but I'm taking one week off. Will send you the updated one after
Christmas though.
- Leo
^ permalink raw reply
* Re: [PATCH 4/15] [POWERPC] pci32: Add flags modifying the PCI code behaviour
From: Olof Johansson @ 2007-12-14 8:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071214045612.3A7E6DE2E2@ozlabs.org>
Hi,
Minor nitpicks:
On Fri, Dec 14, 2007 at 03:56:05PM +1100, Benjamin Herrenschmidt wrote:
> --- linux-merge.orig/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:28.000000000 +1100
> +++ linux-merge/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:29.000000000 +1100
> @@ -48,7 +51,7 @@ static u8* pci_to_OF_bus_map;
> /* By default, we don't re-assign bus numbers. We do this only on
> * some pmacs
> */
> -int pci_assign_all_buses;
> +static int pci_assign_all_buses;
>
Why not remove it alltogether, there's still the function to test the
flag that's just as cheap (load + test + branch).
> Index: linux-merge/include/asm-powerpc/pci-bridge.h
> ===================================================================
> --- linux-merge.orig/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:01.000000000 +1100
> +++ linux-merge/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:29.000000000 +1100
> @@ -13,6 +13,26 @@
>
> struct device_node;
>
> +extern unsigned int ppc_pci_flags;
Should the below be a named enum and the type for the above be the same
for nicer decode in gdb?
> +enum {
> + /* Force re-assigning all resources (ignore firmware
> + * setup completely)
> + */
> + PPC_PCI_REASSIGN_ALL_RSRC = 0x00000001,
This should be ..._RSRCS (resources, not resource)
> + /* Re-assign all bus numbers */
> + PPC_PCI_REASSIGN_ALL_BUS = 0x00000002,
And this should be ..._BUSSES
> + /* Do not try to assign, just use existing setup */
> + PPC_PCI_PROBE_ONLY = 0x00000004,
My first reaction was "what's the difference between setting this and
keeping the two other cleared". Looks like the difference is the
assignment of unassigned resources. Not sure how to better represent
that so it's obvious from the naming (without doing something as
excessive as PPC_PCI_REASSIGN_UNASSIGNED_RSRCS :)
> +
> + /* Don't bother with ISA alignment unless the bridge has
> + * ISA forwarding enabled
> + */
> + PPC_PCI_CAN_SKIP_ISA_ALIGN = 0x00000008,
> +};
-Olof
^ permalink raw reply
* Re: [PATCH 1/7] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-12-14 8:05 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: ppcdev
In-Reply-To: <20071213234221.B0BC27D0054@mail142-sin.bigfish.com>
On Fri Dec 14 10:43:27 EST 2007, Stephen Neuendorffer wrote:
> From: Grant Likely <grant.likely at secretlab.ca>
>
> This target produces a flat binary rather than an ELF file,
> fixes the entry point at the beginning of the image, and takes
> a complete device tree with no fixups needed.
>
> The device tree must have labels on /#address-cells, the timebase
> frequency, and the memory size.
>
> Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
> ---
You indicated in the intro in 0/ that this was not ready, and you
didn't include your own s-o-b, but you did not put any statements to
that effect in the header. The intro is not copied into patchwork,
which maintainers often use when deciding what to push.
Now on to why this should not be merged:
In addition to the above, it changes the build rules. It tries to
change wrapper to assemble the .dtb into a .o from a .S file, but
doesn't set any flags to force the assembler into the right mode. In
contrast the linker is controlled by the .lds linker script.
In addition, the requirement for assembly labels can easily be
eliminated. As mentioned above, they are used for 3 properties. With
the existing library (in 2.6.24 and earlier), call simple_malloc_init
with a small bss array (like BSS_STACK does to allocate stack), and
then read the properties out of the device tree. At that point, call
simple_malloc_init a second time using the found memory size. As I
said the last time this was posted, my patches to boot from kexec
implemented this strategy.
However, with the new libfdt, which is already in for-2.6.25, we should
no longer need malloc() to simple read the tree. At least that is
what was advertised.
> +$(obj)/zImage.raw: vmlinux $(dts) $(wrapperbits)
> + $(call if_changed,wrap,raw,$(dts))
>
This should be handled by the standard zImage% rule.
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long
> r5,
> + unsigned long r6, unsigned long r7)
>
The calling convention of platform_init is controlled by head, and
doesn't have a global prototype. Since you use none of these
arguments, this implementation should take void.
In general, serial_console_init is not safe to call, as the wrapper has
no access mode change for its io access macros and instead requires
firmware to setup a mapping. That and the fact the wrapper uses the
same properties to choose the console as the kernel means even
kexec-tools can't add or delete a property to kill that call. (This
statement is made from the viewpoint that this raw image should be
suitable for kexec in addition to being loaded by a dumb firmware).
I'm not sure exactly what platform you are using this on. Apparently
it is a legacy firmware that loads the image and jumps to it leaving
interrupts on and not invalidating the cache.
I was going to suggest this platform_init be turned into a helper like
simple_platform_init or so. However, that brings up a philosophy
question on what the directory should look like (I was going for a
modular library with lots of small routines loaded on demand, but
others are going for fewer files that tend to drag sometimes used
routines. They later resist features with "thats a lot of code"). And
with the read_only libfdt pending, the remaining code maybe considered
too trivial not to replicate in the platforms that need it.
milton
^ permalink raw reply
* RE: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Li Tony @ 2007-12-14 8:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Phillips Kim, Jin Zhengxiong
In-Reply-To: <97EB3576-6952-4F36-A243-4EBF981A117F@kernel.crashing.org>
=20
Hi,
I think it is possible to make common code to support both IPIC and =
MPIC.
Currently, the MPIC has already implemented MSI which is different from =
IPIC and embedded into the mpic code body.
If want to unifiy MSI code, we need to remove the current MPIC MSI =
implementation.
Micheal, what is your opinion ??
Jin is working on 86xx msi now.=20
Tony
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: 2007=C4=EA12=D4=C214=C8=D5 13:45
> To: Li Tony
> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev
> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
>=20
>=20
> On Dec 4, 2007, at 4:39 AM, Li Li wrote:
>=20
> > Modified based on discussion on list.
> >
> > 1. Adopt virq_to_hw routine
> > 2. Correct a legacy bug
> >
> > Implements the IPIC MSI as two level interrupt controller.
> >
> > Signed-off-by: Tony Li <tony.li@freescale.com>
>=20
> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism? =20
> The 2nd level PIC handling seems like its pretty similar=20
> between IPIC and MPIC. Would like to see if we could somehow=20
> make the code common for to handle MSIs from both?
>=20
> - k
>=20
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Kumar Gala @ 2007-12-14 8:52 UTC (permalink / raw)
To: Li Tony; +Cc: linuxppc-dev list, Phillips Kim, Olof Johansson, Jin Zhengxiong
In-Reply-To: <995B09A8299C2C44B59866F6391D2635DB0633@zch01exm21.fsl.freescale.net>
On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>
> Hi,
>
> I think it is possible to make common code to support both IPIC and =20=
> MPIC.
> Currently, the MPIC has already implemented MSI which is different =20
> from IPIC and embedded into the mpic code body.
> If want to unifiy MSI code, we need to remove the current MPIC MSI =20
> implementation.
The MPIC is going to have to support several MSI styles (IBM/U3, =20
PaSemi, and FSL) since we all seem to handle it differently.
> Micheal, what is your opinion ??
>
> Jin is working on 86xx msi now.
What PCIe cards are you using to test MSIs?
- k
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: 2007=C4=EA12=D4=C214=C8=D5 13:45
>> To: Li Tony
>> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev
>> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
>>
>>
>> On Dec 4, 2007, at 4:39 AM, Li Li wrote:
>>
>>> Modified based on discussion on list.
>>>
>>> 1. Adopt virq_to_hw routine
>>> 2. Correct a legacy bug
>>>
>>> Implements the IPIC MSI as two level interrupt controller.
>>>
>>> Signed-off-by: Tony Li <tony.li@freescale.com>
>>
>> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism?
>> The 2nd level PIC handling seems like its pretty similar
>> between IPIC and MPIC. Would like to see if we could somehow
>> make the code common for to handle MSIs from both?
>>
>> - k
>>
^ permalink raw reply
* Re: [PATCH 4/15] [POWERPC] pci32: Add flags modifying the PCI code behaviour
From: Benjamin Herrenschmidt @ 2007-12-14 9:00 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071214084343.GC28118@lixom.net>
> On Fri, Dec 14, 2007 at 03:56:05PM +1100, Benjamin Herrenschmidt wrote:
>
> > --- linux-merge.orig/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:28.000000000 +1100
> > +++ linux-merge/arch/powerpc/kernel/pci_32.c 2007-12-14 15:49:29.000000000 +1100
> > @@ -48,7 +51,7 @@ static u8* pci_to_OF_bus_map;
> > /* By default, we don't re-assign bus numbers. We do this only on
> > * some pmacs
> > */
> > -int pci_assign_all_buses;
> > +static int pci_assign_all_buses;
> >
>
> Why not remove it alltogether, there's still the function to test the
> flag that's just as cheap (load + test + branch).
I don't remember... felt like I had a good reason back then but I don't
remember it :-) I'll have another look.
> > Index: linux-merge/include/asm-powerpc/pci-bridge.h
> > ===================================================================
> > --- linux-merge.orig/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:01.000000000 +1100
> > +++ linux-merge/include/asm-powerpc/pci-bridge.h 2007-12-14 15:49:29.000000000 +1100
> > @@ -13,6 +13,26 @@
> >
> > struct device_node;
> >
> > +extern unsigned int ppc_pci_flags;
>
> Should the below be a named enum and the type for the above be the same
> for nicer decode in gdb?
>
> > +enum {
> > + /* Force re-assigning all resources (ignore firmware
> > + * setup completely)
> > + */
> > + PPC_PCI_REASSIGN_ALL_RSRC = 0x00000001,
>
> This should be ..._RSRCS (resources, not resource)
>
> > + /* Re-assign all bus numbers */
> > + PPC_PCI_REASSIGN_ALL_BUS = 0x00000002,
>
> And this should be ..._BUSSES
>
> > + /* Do not try to assign, just use existing setup */
> > + PPC_PCI_PROBE_ONLY = 0x00000004,
>
> My first reaction was "what's the difference between setting this and
> keeping the two other cleared". Looks like the difference is the
> assignment of unassigned resources. Not sure how to better represent
> that so it's obvious from the naming (without doing something as
> excessive as PPC_PCI_REASSIGN_UNASSIGNED_RSRCS :)
Well... hence "RE" in "REASSIGN" ...
By default, we assign only unassigned resources... (or the ones that
collide). I could add a comment to that effect.
> > +
> > + /* Don't bother with ISA alignment unless the bridge has
> > + * ISA forwarding enabled
> > + */
> > + PPC_PCI_CAN_SKIP_ISA_ALIGN = 0x00000008,
> > +};
Ben.
^ permalink raw reply
* [PATCH] Fix build break caused by "ide: remove ideprobe_init()"
From: Olof Johansson @ 2007-12-14 9:09 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, akpm, linuxppc-dev
In-Reply-To: <200711182325.09262.bzolnier@gmail.com>
Fix build break of powerpc holly_defconfig:
In file included from arch/powerpc/platforms/embedded6xx/holly.c:24:
include/linux/ide.h:1206: error: 'CONFIG_IDE_MAX_HWIFS' undeclared here (not in a function)
There's no need to have a sized array in the prototype, might as well
turn it into a pointer.
It could probably be argued that large parts of the include file can be
covered under #ifdef CONFIG_IDE, but that's a larger undertaking.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
On Sun, Nov 18, 2007 at 11:25:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> * Rename ide_device_add() to ide_device_add_all() and make it accept
> 'u8 idx[MAX_HWIFS]' instead of 'u8 idx[4]' as an argument.
>
> * Add ide_device_add() wrapper for ide_device_add_all().
>
> * Convert ide_generic_init() to use ide_device_add_all().
>
> * Remove no longer needed ideprobe_init().
>
> There should be no functionality changes caused by this patch.
This patch broke builds of powerpc holly_defconfig in -mm. It has
CONFIG_EMBEDDED=y, CONFIG_IDE=n but includes linux/ide.h:
Index: mm/drivers/ide/ide-probe.c
===================================================================
--- mm.orig/drivers/ide/ide-probe.c
+++ mm/drivers/ide/ide-probe.c
@@ -1335,7 +1335,7 @@ static void hwif_register_devices(ide_hw
}
}
-int ide_device_add_all(u8 idx[MAX_HWIFS])
+int ide_device_add_all(u8 *idx)
{
ide_hwif_t *hwif;
int i, rc = 0;
Index: mm/include/linux/ide.h
===================================================================
--- mm.orig/include/linux/ide.h
+++ mm/include/linux/ide.h
@@ -1203,7 +1203,7 @@ void ide_unregister_region(struct gendis
void ide_undecoded_slave(ide_drive_t *);
-int ide_device_add_all(u8 idx[MAX_HWIFS]);
+int ide_device_add_all(u8 *idx);
int ide_device_add(u8 idx[4]);
static inline void *ide_get_hwifdata (ide_hwif_t * hwif)
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Li Li @ 2007-12-14 9:13 UTC (permalink / raw)
To: Kumar Gala
Cc: Phillips Kim, linuxppc-dev list, Jin Zhengxiong, Li Tony,
Olof Johansson
In-Reply-To: <90B908AC-E879-4046-AAFC-FE79EB78A932@kernel.crashing.org>
On Fri, 2007-12-14 at 16:52 +0800, Kumar Gala wrote:
>=20
> On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>=20
> >=20
> > Hi,=20
> >=20
> > I think it is possible to make common code to support both IPIC
> and =20
> > MPIC.=20
> > Currently, the MPIC has already implemented MSI which is different =20
> > from IPIC and embedded into the mpic code body.=20
> > If want to unifiy MSI code, we need to remove the current MPIC MSI =20
> > implementation.
>=20
> The MPIC is going to have to support several MSI styles (IBM/U3, =20
> PaSemi, and FSL) since we all seem to handle it differently.
>=20
Yes, you are right. I misunderstands here.
> > Micheal, what is your opinion ??=20
> >=20
> > Jin is working on 86xx msi now.
>=20
> What PCIe cards are you using to test MSIs?
>=20
Intel PRO1000 PCIE network card and SysKonnect card.
> - k
>=20
> >> -----Original Message-----=20
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> >> Sent: 2007=E5=B9=B412=E6=9C=8814=E6=97=A5 13:45=20
> >> To: Li Tony=20
> >> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev=20
> >> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support=20
> >>=20
> >>=20
> >> On Dec 4, 2007, at 4:39 AM, Li Li wrote:=20
> >>=20
> >>> Modified based on discussion on list.=20
> >>>=20
> >>> 1. Adopt virq_to_hw routine=20
> >>> 2. Correct a legacy bug=20
> >>>=20
> >>> Implements the IPIC MSI as two level interrupt controller.=20
> >>>=20
> >>> Signed-off-by: Tony Li <tony.li@freescale.com>=20
> >>=20
> >> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism?=20
> >> The 2nd level PIC handling seems like its pretty similar=20
> >> between IPIC and MPIC. Would like to see if we could somehow=20
> >> make the code common for to handle MSIs from both?=20
> >>=20
> >> - k=20
> >>
>=20
^ permalink raw reply
* RE: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Jin Zhengxiong @ 2007-12-14 9:39 UTC (permalink / raw)
To: Kumar Gala, Li Tony; +Cc: linuxppc-dev list, Phillips Kim, Olof Johansson
In-Reply-To: <90B908AC-E879-4046-AAFC-FE79EB78A932@kernel.crashing.org>
=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Friday, December 14, 2007 4:52 PM
> To: Li Tony
> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev list;=20
> Jin Zhengxiong; Olof Johansson
> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
>=20
>=20
> On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>=20
> >
> > Hi,
> >
> > I think it is possible to make common code to support both IPIC and=20
> > MPIC.
> > Currently, the MPIC has already implemented MSI which is different=20
> > from IPIC and embedded into the mpic code body.
> > If want to unifiy MSI code, we need to remove the current MPIC MSI=20
> > implementation.
>=20
> The MPIC is going to have to support several MSI styles=20
> (IBM/U3, PaSemi, and FSL) since we all seem to handle it differently.
I enabled the MSI interrrupts on 85xx/86xx board similar to the IBM/U3 =
board.
Did not enable another host as on 83xx board. Put the 256 MSI interrupts =
after the=20
256 system interrupts and use the same mpic host. This can work and can =
reuse most
of the mpic_msi codes. but since the host_map of MSI is something =
different with MPIC.
I also think it's good idea to make a 2 level PIC handling mechanism for =
MSI on 85xx/86xx board and=20
common the code to support for both IPIC and MPIC for fsl board.
=20
> > Micheal, what is your opinion ??
> >
> > Jin is working on 86xx msi now.
>=20
> What PCIe cards are you using to test MSIs?
I used a SysKonnect 1000M PCIe ether card and the SATA driver to test =
the MSI on 85xx/86xx board.
Best Regards,
Jason
> - k
>=20
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: 2007=C4=EA12=D4=C214=C8=D5 13:45
> >> To: Li Tony
> >> Cc: Phillips Kim; michael@ellerman.id.au; linuxppc-dev
> >> Subject: Re: [PATCH 2/2] powerpc: Add IPIC MSI support
> >>
> >>
> >> On Dec 4, 2007, at 4:39 AM, Li Li wrote:
> >>
> >>> Modified based on discussion on list.
> >>>
> >>> 1. Adopt virq_to_hw routine
> >>> 2. Correct a legacy bug
> >>>
> >>> Implements the IPIC MSI as two level interrupt controller.
> >>>
> >>> Signed-off-by: Tony Li <tony.li@freescale.com>
> >>
> >> Tony, have you looked at the 85xx/86xx PCIe MSI mechanism?
> >> The 2nd level PIC handling seems like its pretty similar=20
> between IPIC=20
> >> and MPIC. Would like to see if we could somehow make the=20
> code common=20
> >> for to handle MSIs from both?
> >>
> >> - k
> >>
>=20
>=20
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add IPIC MSI support
From: Michael Ellerman @ 2007-12-14 9:40 UTC (permalink / raw)
To: Kumar Gala
Cc: Olof Johansson, linuxppc-dev list, Phillips Kim, Jin Zhengxiong,
Li Tony
In-Reply-To: <90B908AC-E879-4046-AAFC-FE79EB78A932@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
On Fri, 2007-12-14 at 02:52 -0600, Kumar Gala wrote:
> On Dec 14, 2007, at 2:47 AM, Li Tony wrote:
>
> >
> > Hi,
> >
> > I think it is possible to make common code to support both IPIC and
> > MPIC.
> > Currently, the MPIC has already implemented MSI which is different
> > from IPIC and embedded into the mpic code body.
> > If want to unifiy MSI code, we need to remove the current MPIC MSI
> > implementation.
>
> The MPIC is going to have to support several MSI styles (IBM/U3,
> PaSemi, and FSL) since we all seem to handle it differently.
I haven't really looked at the similarities or differences, but I think
Kumar is right, MPIC is going to have to (and already does) support
different styles.
If there's some commonality that can be shared I'm all ears, patches
welcome ;)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: any more patches for 2.6.24?
From: Étienne Bersac @ 2007-12-14 11:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18274.3076.467791.719752@cargo.ozlabs.ibm.com>
Hi,
I posted a patch adding windfarm-pm121 driver, i wish it were included
in 2.6.24 . Can you review it ?
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/047641.html
Regards,
Étienne.
^ permalink raw reply
* Re: apm_emulation regression
From: Johannes Berg @ 2007-12-14 12:18 UTC (permalink / raw)
To: benh; +Cc: Rafael J. Wysocki, linuxppc-dev list, linux-pm, ralf
In-Reply-To: <1197590712.15741.197.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
> > It can use the new notifier that happens before freezing yes. Johannes,
> > I think that's pretty much what my old powermac implementation did
> > (using my private notifier scheme I had there), might be worth reviving
> > that bit and sticking it into the generic apm_emu ...
>
> Note that you may want to improve on it with a timeout in case userspace
> doesn't ack...
Yeah heh. I'll take a look, shouldn't be too hard. Except I'm not
exactly sure how to test it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] OProfile: remove dependency on spufs module
From: Arnd Bergmann @ 2007-12-14 14:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Woodhouse, Paul Mackerras, jk, Bob Nelson
In-Reply-To: <18274.3076.467791.719752@cargo.ozlabs.ibm.com>
From: Bob Nelson <rrnelson@linux.vnet.ibm.com>
This is a patch removes an OProfile dependency on the spufs module.
This was causing a problem for multiplatform systems that are
built with support for Oprofile on Cell but try to load the
oprofile module on another system.
Signed-off-by: Bob Nelson <rrnelson@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
On Friday 14 December 2007, Paul Mackerras wrote:
> Currently I have just this one bugfix queued up to go to Linus for
> 2.6.24:
>
> Stephen Rothwell (1):
> [POWERPC] iSeries: don't printk with HV spinlock held
>
> Does anyone else have bugfixes that need to go in 2.6.24?
A few people have asked me for including this one, I'd like
it to get that in still. It was broken ever since you could
enable support for spu oprofile.
Jeremy, please ack the spufs changes if you are ok with the patch.
Sorry for delaying this patch so long on my side everyone.
Arnd <><
arch/powerpc/platforms/cell/Kconfig | 2 +-
arch/powerpc/platforms/cell/Makefile | 1 +
arch/powerpc/platforms/cell/spu_notify.c | 67 ++++++++++++++++++++++++++
arch/powerpc/platforms/cell/spu_syscalls.c | 14 +++++
arch/powerpc/platforms/cell/spufs/context.c | 16 ------
arch/powerpc/platforms/cell/spufs/sched.c | 29 +++--------
arch/powerpc/platforms/cell/spufs/syscalls.c | 1 +
include/asm-powerpc/spu.h | 4 ++
8 files changed, 95 insertions(+), 39 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/spu_notify.c
Index: linux-2.6-new/arch/powerpc/platforms/cell/Kconfig
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/Kconfig
+++ linux-2.6-new/arch/powerpc/platforms/cell/Kconfig
@@ -88,3 +88,8 @@ config CBE_CPUFREQ_PMI
but also at lower core voltage.
endmenu
+
+config OPROFILE_CELL
+ def_bool y
+ depends on PPC_CELL_NATIVE && (OPROFILE = m || OPROFILE = y)
+
Index: linux-2.6-new/arch/powerpc/platforms/cell/Makefile
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/Makefile
+++ linux-2.6-new/arch/powerpc/platforms/cell/Makefile
@@ -19,6 +19,7 @@ spu-manage-$(CONFIG_PPC_CELLEB) += spu_
spu-manage-$(CONFIG_PPC_CELL_NATIVE) += spu_manage.o
obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
+ spu_notify.o \
spu_syscalls.o \
$(spu-priv1-y) \
$(spu-manage-y) \
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_notify.c
===================================================================
--- /dev/null
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_notify.c
@@ -0,0 +1,67 @@
+/*
+ * Move OProfile dependencies from spufs module to the kernel so it
+ * can run on non-cell PPC.
+ *
+ * Copyright (C) IBM 2005
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#undef DEBUG
+
+#include <linux/module.h>
+#include <asm/spu.h>
+#include "spufs/spufs.h"
+
+static BLOCKING_NOTIFIER_HEAD(spu_switch_notifier);
+
+void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
+{
+ blocking_notifier_call_chain(&spu_switch_notifier,
+ ctx ? ctx->object_id : 0, spu);
+}
+EXPORT_SYMBOL_GPL(spu_switch_notify);
+
+int spu_switch_event_register(struct notifier_block *n)
+{
+ int ret;
+ ret = blocking_notifier_chain_register(&spu_switch_notifier, n);
+ if (!ret)
+ notify_spus_active();
+ return ret;
+}
+EXPORT_SYMBOL_GPL(spu_switch_event_register);
+
+int spu_switch_event_unregister(struct notifier_block *n)
+{
+ return blocking_notifier_chain_unregister(&spu_switch_notifier, n);
+}
+EXPORT_SYMBOL_GPL(spu_switch_event_unregister);
+
+void spu_set_profile_private_kref(struct spu_context *ctx,
+ struct kref *prof_info_kref,
+ void (* prof_info_release) (struct kref *kref))
+{
+ ctx->prof_priv_kref = prof_info_kref;
+ ctx->prof_priv_release = prof_info_release;
+}
+EXPORT_SYMBOL_GPL(spu_set_profile_private_kref);
+
+void *spu_get_profile_private_kref(struct spu_context *ctx)
+{
+ return ctx->prof_priv_kref;
+}
+EXPORT_SYMBOL_GPL(spu_get_profile_private_kref);
+
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_syscalls.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_syscalls.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_syscalls.c
@@ -145,6 +145,20 @@ int elf_coredump_extra_notes_write(struc
return ret;
}
+void notify_spus_active(void)
+{
+ struct spufs_calls *calls;
+
+ calls = spufs_calls_get();
+ if (!calls)
+ return;
+
+ calls->notify_spus_active();
+ spufs_calls_put(calls);
+
+ return;
+}
+
int register_spu_syscalls(struct spufs_calls *calls)
{
if (spufs_calls)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spufs/context.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spufs/context.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spufs/context.c
@@ -190,19 +190,3 @@ void spu_release_saved(struct spu_contex
spu_release(ctx);
}
-void spu_set_profile_private_kref(struct spu_context *ctx,
- struct kref *prof_info_kref,
- void ( * prof_info_release) (struct kref *kref))
-{
- ctx->prof_priv_kref = prof_info_kref;
- ctx->prof_priv_release = prof_info_release;
-}
-EXPORT_SYMBOL_GPL(spu_set_profile_private_kref);
-
-void *spu_get_profile_private_kref(struct spu_context *ctx)
-{
- return ctx->prof_priv_kref;
-}
-EXPORT_SYMBOL_GPL(spu_get_profile_private_kref);
-
-
Index: linux-2.6-new/arch/powerpc/platforms/cell/spufs/sched.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spufs/sched.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spufs/sched.c
@@ -166,15 +166,7 @@ static int node_allowed(struct spu_conte
return rval;
}
-static BLOCKING_NOTIFIER_HEAD(spu_switch_notifier);
-
-void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
-{
- blocking_notifier_call_chain(&spu_switch_notifier,
- ctx ? ctx->object_id : 0, spu);
-}
-
-static void notify_spus_active(void)
+void do_notify_spus_active(void)
{
int node;
@@ -200,22 +192,15 @@ static void notify_spus_active(void)
mutex_unlock(&cbe_spu_info[node].list_mutex);
}
}
+EXPORT_SYMBOL_GPL(do_notify_spus_active);
-int spu_switch_event_register(struct notifier_block * n)
-{
- int ret;
- ret = blocking_notifier_chain_register(&spu_switch_notifier, n);
- if (!ret)
- notify_spus_active();
- return ret;
-}
-EXPORT_SYMBOL_GPL(spu_switch_event_register);
-
-int spu_switch_event_unregister(struct notifier_block * n)
+#ifndef MODULE
+void notify_spus_active(void)
{
- return blocking_notifier_chain_unregister(&spu_switch_notifier, n);
+ do_notify_spus_active();
}
-EXPORT_SYMBOL_GPL(spu_switch_event_unregister);
+EXPORT_SYMBOL_GPL(notify_spus_active);
+#endif
/**
* spu_bind_context - bind spu context to physical spu
Index: linux-2.6-new/arch/powerpc/platforms/cell/spufs/syscalls.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spufs/syscalls.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spufs/syscalls.c
@@ -86,5 +86,6 @@ struct spufs_calls spufs_calls = {
.spu_run = do_spu_run,
.coredump_extra_notes_size = spufs_coredump_extra_notes_size,
.coredump_extra_notes_write = spufs_coredump_extra_notes_write,
+ .notify_spus_active = do_notify_spus_active,
.owner = THIS_MODULE,
};
Index: linux-2.6-new/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6-new.orig/include/asm-powerpc/spu.h
+++ linux-2.6-new/include/asm-powerpc/spu.h
@@ -246,6 +246,7 @@ struct spufs_calls {
__u32 __user *ustatus);
int (*coredump_extra_notes_size)(void);
int (*coredump_extra_notes_write)(struct file *file, loff_t *foffset);
+ void (*notify_spus_active)(void);
struct module *owner;
};
@@ -298,6 +299,9 @@ struct notifier_block;
int spu_switch_event_register(struct notifier_block * n);
int spu_switch_event_unregister(struct notifier_block * n);
+extern void notify_spus_active(void);
+extern void do_notify_spus_active(void);
+
/*
* This defines the Local Store, Problem Area and Privlege Area of an SPU.
*/
^ permalink raw reply
* Re: [PATCH 1/7] bootwrapper: Add a firmware-independent "raw" target.
From: Grant Likely @ 2007-12-14 15:23 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <f7eb0ae3da29213720e6b0049deca335@bga.com>
On 12/14/07, Milton Miller <miltonm@bga.com> wrote:
> On Fri Dec 14 10:43:27 EST 2007, Stephen Neuendorffer wrote:
>
> > From: Grant Likely <grant.likely at secretlab.ca>
> >
> > This target produces a flat binary rather than an ELF file,
> > fixes the entry point at the beginning of the image, and takes
> > a complete device tree with no fixups needed.
> >
> > The device tree must have labels on /#address-cells, the timebase
> > frequency, and the memory size.
> >
> > Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
For the record; this patch was lifted from my dev tree and in turn I
stole it from Scott Wood.
>
> > +$(obj)/zImage.raw: vmlinux $(dts) $(wrapperbits)
> > + $(call if_changed,wrap,raw,$(dts))
> >
>
> This should be handled by the standard zImage% rule.
It's weird. On my system the standard zImage rule wouldn't do this
target. I had to add this rule just to get it to compile. I've not
yet been motivated to revisit and fix it.
> I'm not sure exactly what platform you are using this on. Apparently
> it is a legacy firmware that loads the image and jumps to it leaving
> interrupts on and not invalidating the cache.
Heh; actually it's a platform with *no* firmware. :-)
It's on a Xilinx FPGA. SDRAM is initialized by the FPGA design and
the kernel image is loaded either with a debugger, or via the
SystemACE device. In either case, the kernel is the first thing to
run after reset.... oh, and reset is not as complete as one would
normally expect.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Scott Wood @ 2007-12-14 15:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EB293853-B27A-4B0E-AEEB-8D3F09E8F12D@kernel.crashing.org>
On Thu, Dec 13, 2007 at 11:19:33PM -0600, Kumar Gala wrote:
> Can we make this a /dts-v1/; since its new.
It's not really new; it's just been collecting dust for a while. :-P
Are there any tools to autoconvert (preferably without losing comments)?
> >+/ {
> >+ model = "EP8248E";
> >+ compatible = "fsl,ep8248e";
> >+ #address-cells = <1>;
> >+ #size-cells = <1>;
>
> Add a aliases { } and can we use that instead of linux,network-index
> and linux,planetcore-label.
I don't see any support in the current bootwrapper for aliases.
-Scott
^ permalink raw reply
* Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Scott Wood @ 2007-12-14 16:09 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-ide, Paul Mundt, Arnd Bergmann, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071214082313.GA28118@lixom.net>
On Fri, Dec 14, 2007 at 02:23:13AM -0600, Olof Johansson wrote:
> On Wed, Dec 05, 2007 at 12:39:12PM -0600, Scott Wood wrote:
> > Why is it dependent on anything other than platform bus support and ATA?
>
> There's no way to specify dependency on platform bus as a config option,
> that's likely what EMBEDDED was meant to do. Some platforms have platform
> bus in spite of being !EMBEDDED, arch/arm/configs/rpc_defconfig seems
> to be among those. PPC too.
If platform bus can't be configged out, then the only dependency should
be the implicit one on ATA (is there anything else whose absence will
stop the code from building, or working if the appropriate platform
device is passed in?).
-Scott
^ permalink raw reply
* Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Olof Johansson @ 2007-12-14 16:33 UTC (permalink / raw)
To: Scott Wood
Cc: linux-ide, Paul Mundt, Jeff Garzik, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20071214160928.GA16607@ld0162-tx32.am.freescale.net>
On Fri, Dec 14, 2007 at 10:09:28AM -0600, Scott Wood wrote:
> On Fri, Dec 14, 2007 at 02:23:13AM -0600, Olof Johansson wrote:
> > On Wed, Dec 05, 2007 at 12:39:12PM -0600, Scott Wood wrote:
> > > Why is it dependent on anything other than platform bus support and ATA?
> >
> > There's no way to specify dependency on platform bus as a config option,
> > that's likely what EMBEDDED was meant to do. Some platforms have platform
> > bus in spite of being !EMBEDDED, arch/arm/configs/rpc_defconfig seems
> > to be among those. PPC too.
>
> If platform bus can't be configged out, then the only dependency should
> be the implicit one on ATA (is there anything else whose absence will
> stop the code from building, or working if the appropriate platform
> device is passed in?).
Sure, sounds good to me.
-Olof
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Kumar Gala @ 2007-12-14 16:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071214155341.GB16269@ld0162-tx32.am.freescale.net>
On Dec 14, 2007, at 9:53 AM, Scott Wood wrote:
> On Thu, Dec 13, 2007 at 11:19:33PM -0600, Kumar Gala wrote:
>> Can we make this a /dts-v1/; since its new.
>
> It's not really new; it's just been collecting dust for a while. :-P
Its new to us on the list :P
> Are there any tools to autoconvert (preferably without losing
> comments)?
Not sure of jon had a perl script or something.
>>> +/ {
>>> + model = "EP8248E";
>>> + compatible = "fsl,ep8248e";
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>
>> Add a aliases { } and can we use that instead of linux,network-index
>> and linux,planetcore-label.
>
> I don't see any support in the current bootwrapper for aliases.
Yeah, I was hoping you'd code something up :)
- k
^ permalink raw reply
* Re: [PATCH 05/10] powerpc: Add crash kernel support for 85xx
From: Kumar Gala @ 2007-12-14 16:48 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20071122154619.GA26471@xyzzy.farnsworth.org>
On Nov 22, 2007, at 9:46 AM, Dale Farnsworth wrote:
> Add the ability to build a ppc_85xx kernel to run at a physical
> address of 32MB.
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/head_fsl_booke.S | 23 ++++++++++++++++++-----
> arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
> 3 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 805b4d1..d405298 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -253,7 +253,7 @@ config KEXEC
>
> config CRASH_DUMP
> bool "Build a kdump crash kernel (EXPERIMENTAL)"
> - depends on PPC_MULTIPLATFORM && EXPERIMENTAL
> + depends on (PPC_MULTIPLATFORM || PPC_85xx) && EXPERIMENTAL
> help
> Build a kernel suitable for use as a kdump capture kernel.
> The kernel will be linked at a different address than normal, and
> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/
> kernel/head_fsl_booke.S
> index 4b98227..1c9685f 100644
> --- a/arch/powerpc/kernel/head_fsl_booke.S
> +++ b/arch/powerpc/kernel/head_fsl_booke.S
> @@ -41,6 +41,12 @@
> #include <asm/asm-offsets.h>
> #include "head_booke.h"
>
> +#ifdef CONFIG_CRASH_DUMP
> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_64M)
> +#else
> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_16M)
> +#endif
I'm ok with bumping the first page to 64M in all cases.
>
> +
> /* As with the other PowerPC ports, it is expected that when code
> * execution begins here, the following registers contain valid, yet
> * optional, information:
> @@ -75,6 +81,7 @@ _ENTRY(_start);
> * boot loader and load a single entry in TLB1[0] to map the
> * first 16M of kernel memory. Any boot info passed from the
> * bootloader needs to live in this first 16M.
> + * Note that for crash (kdump) kernels, the first 64M is mapped.
> *
> * Requirement on bootloader:
> * - The page we're executing in needs to reside in TLB1 and
> @@ -167,7 +174,7 @@ skpinv: addi r6,r6,1 /* Increment */
> mtspr SPRN_MAS0,r7
> tlbre
>
> - /* Just modify the entry ID and EPN for the temp mapping */
> + /* Just modify the entry ID, EPN and RPN for the temp mapping */
> lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */
> rlwimi r7,r5,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r5) */
> mtspr SPRN_MAS0,r7
> @@ -177,9 +184,12 @@ skpinv: addi r6,r6,1 /* Increment */
> ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_4K))@l
> mtspr SPRN_MAS1,r6
> mfspr r6,SPRN_MAS2
> - li r7,0 /* temp EPN = 0 */
> + lis r7,PHYSICAL_START@h
> rlwimi r7,r6,0,20,31
> mtspr SPRN_MAS2,r7
> + mfspr r6,SPRN_MAS3
> + rlwimi r7,r6,0,20,31
> + mtspr SPRN_MAS3,r7
> tlbwe
>
> xori r6,r4,1
> @@ -222,11 +232,11 @@ skpinv: addi r6,r6,1 /* Increment */
> lis r6,0x1000 /* Set MAS0(TLBSEL) = TLB1(1), ESEL = 0 */
> mtspr SPRN_MAS0,r6
> lis r6,(MAS1_VALID|MAS1_IPROT)@h
> - ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_16M))@l
> + ori r6,r6,(MAS1_TSIZE(INITIAL_BOOKE_PAGESZ))@l
> mtspr SPRN_MAS1,r6
> li r7,0
> - lis r6,KERNELBASE@h
> - ori r6,r6,KERNELBASE@l
> + lis r6,PAGE_OFFSET@h
> + ori r6,r6,PAGE_OFFSET@l
> rlwimi r6,r7,0,20,31
> mtspr SPRN_MAS2,r6
> li r7,(MAS3_SX|MAS3_SW|MAS3_SR)
> @@ -234,6 +244,9 @@ skpinv: addi r6,r6,1 /* Increment */
> tlbwe
>
> /* 7. Jump to KERNELBASE mapping */
> + lis r6,KERNELBASE@h
> + ori r6,r6,KERNELBASE@l
> + rlwimi r6,r7,0,20,31
> lis r7,MSR_KERNEL@h
> ori r7,r7,MSR_KERNEL@l
> bl 1f /* Find our address */
> diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/
> fsl_booke_mmu.c
> index 17139da..c93a966 100644
> --- a/arch/powerpc/mm/fsl_booke_mmu.c
> +++ b/arch/powerpc/mm/fsl_booke_mmu.c
> @@ -165,15 +165,15 @@ void invalidate_tlbcam_entry(int index)
> void __init cam_mapin_ram(unsigned long cam0, unsigned long cam1,
> unsigned long cam2)
> {
> - settlbcam(0, KERNELBASE, PPC_MEMSTART, cam0, _PAGE_KERNEL, 0);
> + settlbcam(0, PAGE_OFFSET, PPC_MEMSTART, cam0, _PAGE_KERNEL, 0);
> tlbcam_index++;
> if (cam1) {
> tlbcam_index++;
> - settlbcam(1, KERNELBASE+cam0, PPC_MEMSTART+cam0, cam1,
> _PAGE_KERNEL, 0);
> + settlbcam(1, PAGE_OFFSET+cam0, PPC_MEMSTART+cam0, cam1,
> _PAGE_KERNEL, 0);
> }
> if (cam2) {
> tlbcam_index++;
> - settlbcam(2, KERNELBASE+cam0+cam1, PPC_MEMSTART+cam0+cam1, cam2,
> _PAGE_KERNEL, 0);
> + settlbcam(2, PAGE_OFFSET+cam0+cam1, PPC_MEMSTART+cam0+cam1, cam2,
> _PAGE_KERNEL, 0);
> }
> }
The rest looks good. Does this mean we can boot a e500 kernel at a
non-zero physical address? (can we run or is the non-zero phy just
for a short period of init time).
- k
^ permalink raw reply
* Re: [PATCH 05/10] powerpc: Add crash kernel support for 85xx
From: Dale Farnsworth @ 2007-12-14 17:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7AF0D992-6B4E-475C-949B-FAE4DDE03D3A@kernel.crashing.org>
On Fri, Dec 14, 2007 at 10:48:58AM -0600, Kumar Gala wrote:
> On Nov 22, 2007, at 9:46 AM, Dale Farnsworth wrote:
>
> > Add the ability to build a ppc_85xx kernel to run at a physical
> > address of 32MB.
> >
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > ---
> > arch/powerpc/Kconfig | 2 +-
> > arch/powerpc/kernel/head_fsl_booke.S | 23 ++++++++++++++++++-----
> > arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
> > 3 files changed, 22 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 805b4d1..d405298 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -253,7 +253,7 @@ config KEXEC
> >
> > config CRASH_DUMP
> > bool "Build a kdump crash kernel (EXPERIMENTAL)"
> > - depends on PPC_MULTIPLATFORM && EXPERIMENTAL
> > + depends on (PPC_MULTIPLATFORM || PPC_85xx) && EXPERIMENTAL
> > help
> > Build a kernel suitable for use as a kdump capture kernel.
> > The kernel will be linked at a different address than normal, and
> > diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/
> > kernel/head_fsl_booke.S
> > index 4b98227..1c9685f 100644
> > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > @@ -41,6 +41,12 @@
> > #include <asm/asm-offsets.h>
> > #include "head_booke.h"
> >
> > +#ifdef CONFIG_CRASH_DUMP
> > +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_64M)
> > +#else
> > +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_16M)
> > +#endif
>
> I'm ok with bumping the first page to 64M in all cases.
OK, I'll make that change in the next rev. Thanks.
<snip>
> The rest looks good. Does this mean we can boot a e500 kernel at a
> non-zero physical address? (can we run or is the non-zero phy just
> for a short period of init time).
Yes, with this series of patches, we can boot and run with a classic ppc
or e500 kernel at 32MB physical (0xc2000000 virtual). Note that on
classic, we still need memory at phys 0 for the exception vectors.
On e500 IIRC, we don't use the vectors at phys 0, but we still write
the trampoline vectors there. I just didn't bother making that conditional.
I'll post an updated series soon, with hopes of getting it into 2.6.25
-Dale
^ 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