* Re: [PATCH 2.6.19 4/4] ehca: ehca_av.c use constant for max mtu
From: Roland Dreier @ 2006-11-08 23:08 UTC (permalink / raw)
To: Hoang-Nam Nguyen; +Cc: linuxppc-dev, linux-kernel, openib-general
In-Reply-To: <200611052142.56722.hnguyen@de.ibm.com>
Thanks, I've applied 1 through 4.
^ permalink raw reply
* Re: [PATCH] powerpc iseries link error in allmodconfig
From: Stephen Rothwell @ 2006-11-08 23:20 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20061108173429.GB14991@shell0.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Wed, 8 Nov 2006 09:34:29 -0800 Judith Lebzelter <judith@osdl.org> wrote:
>
> Choose rpa_vscsi.c over iseries_vscsi.c when building both
> pseries and iseries. This fixes a link error.
>
> Signed-off-by: Judith Lebzelter <judith@osdl.org>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 0/7] Powerpc MSI Implementation
From: Michael Ellerman @ 2006-11-08 23:33 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, linuxppc-dev, linux-pci, David S. Miller
In-Reply-To: <m1fycu5j4o.fsf@ebiederm.dsl.xmission.com>
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
On Wed, 2006-11-08 at 03:26 -0700, Eric W. Biederman wrote:
> Michael Ellerman <michael@ellerman.id.au> writes:
>
> >> Oh, and I think your first two patches can be applied now to the tree
> >> (header file changes). Any objection to me doing this?
> >
> > There's a trivial bug in 1/7 (HT #defines), so hold back on that one
> > until I resend. The movement of MSI-X #defines is good to go. I also
> > sent you the patch to add HT_SUBCAP_OFFSET yesterday that I think is
> > ready to merge.
>
> Actually now that I am thinking about it I'm not at all certain about
> the HT_SUBCAP_OFFSET patch. The basic issue is that it suggests that
> the field that specifies which type of hypertransport capability has a
> fixed number of bits. While in reality the encoding is variable
> length.
Yeah OK, I did notice that was a bit weird, I had a quick look and
assumed that because all the HT_CAPTYPE's were #defined as byte values
it was OK.
Looking closer most of them are 5 bits, the high 5 bits, and happen to
sit next to reserved fields (which must be zero), so reading the byte
should work in practice. But for a few of them you'll get cruft in the
low bits.
I don't know what they were thinking when they decided to have 3 and 5
bit capability fields, and then specify some of them as being a byte
wide as well. Perhaps the spec committee had a big night out ;)
I was going to write a generic version of pci_find_ht_capability() (as
suggested by Segher), so along with that I'll clean up the #defines to
just be the 3 or 5 bit capability codes, and then have a shift for
getting the capability out of the byte.
Users will still need to know if they're looking for a 3 or 5 bit
capability, but we can encapsulate that in pci_find_ht_capability() and
hopefully most people won't have to see the difference.
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: [RFC/PATCH 5/7] RTAS MSI implementation
From: Michael Ellerman @ 2006-11-08 23:35 UTC (permalink / raw)
To: Jake Moilanen
Cc: Greg Kroah-Hartman, linuxppc-dev, Eric W. Biederman, linux-pci,
David S. Miller
In-Reply-To: <1163016960.9913.276.camel@goblue>
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
On Wed, 2006-11-08 at 14:16 -0600, Jake Moilanen wrote:
> On Tue, 2006-11-07 at 18:21 +1100, Michael Ellerman wrote:
> > Powerpc MSI support via RTAS. Based on Jake's code.
> >
>
> Missing the CAS flags to indicate to firmware that we support MSI.
>
> Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
Thanks, I'll stick that in the series. Unless Paulus wants to merge it
straight away.
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: [PATCH] Changed gianfar device tree definition to make it more flexible
From: Andy Fleming @ 2006-11-08 23:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44B423FD-D411-4C80-A4BC-F74AFC942BFD@kernel.crashing.org>
On Nov 8, 2006, at 00:28, Kumar Gala wrote:
>>
>> diff --git a/Documentation/powerpc/booting-without-of.txt b/
>> Documentation/powerpc/booting-without-of.txt
>> index 27b457c..bb1a402 100644
>> --- a/Documentation/powerpc/booting-without-of.txt
>> +++ b/Documentation/powerpc/booting-without-of.txt
>> @@ -1193,6 +1193,7 @@ platforms are moved over to use the flat
>>
>> - device_type : Should be "network"
>> - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
>> + (This is deprecated in favor of the feature bits)
>> - compatible : Should be "gianfar"
>> - reg : Offset and length of the register set for the device
>> - mac-address : List of bytes representing the ethernet
>> address of
>> @@ -1206,6 +1207,30 @@ platforms are moved over to use the flat
>> services interrupts for this device.
>> - phy-handle : The phandle for the PHY connected to this
>> ethernet
>> controller.
>> + - interface : The interface this ethernet is using. Current
>> options are:
>> + GMII, MII, RGMII, SGMII, TBI, RMII, and RTBI
>> +
>> + Optional properties (features):
>> + - gigabit : Indicates support for 1000 Mbit operation
>> + - coalescing : Indicates support for interrupt coalescing
>> + - rmon : Indicates support for RMON-style counters
>> + - checksumming : Indicates support for hardware TCP/UDP
>> checksumming
>> + - vlan-insertion : Indicates support for hardware vlan header
>> insertion
>> + - extended-hash : Indicates support for using the Individual
>> + Address Hash registers to extend the Group Address Hash
>> registers
>> + - padding : Indicates support for padding between the FCB and
>> + the frame
>> + - filer : Indicates support for the Filer
>
> What exactly does parseL2, L3, L4 actually mean? (what feature is
> this)
It's just fine-grained feature control for the parser. Someone here
suggested that I might want separate bits for L2, L3, and L4
functionality. It cost me nothing to add them, so I did. Currently,
the Linux driver does nothing to support them.
>
>> + - parseL2 : Indicates support for parsing L2 headers
>> + - parseL3 : Indicates support for parsing L3 headers
>> + - parseL4 : Indicates support for parsing L4 headers
>> + - multi-queue : Indicates support for sending and receiving
>> + into multiple queues
>> +
>
> Shouldn't we have a flag for L2 stashing as well? (83xx TSECs don't
> support it since no L2 on the parts :)
Yes, good. I will add one for stashing. And locking.
^ permalink raw reply
* [PATCH] powerpc: Remove dtb file created by wrapper script
From: Mark A. Greer @ 2006-11-09 0:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
When the wrapper script is passed a dts file, it runs 'dtc' to create
a dtb file. This patch deletes that dtb file once its no longer needed.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
wrapper | 3 +++
1 file changed, 3 insertions(+)
---
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index b5fb1fe..024e4d4 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -184,6 +184,9 @@ fi
if [ -n "$dtb" ]; then
addsec $tmp "$dtb" .kernel:dtb
+ if [ -n "$dts" ]; then
+ rm $dtb
+ fi
fi
if [ "$platform" != "miboot" ]; then
^ permalink raw reply related
* [PATCH] powerpc: Remove arch/powerpc/boot/zImage file.
From: Mark A. Greer @ 2006-11-09 0:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The bootwrapper Makefile does not clean up the 'zImage' file that
may be left laying around. This patch removes it when cleaning that
directory.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index df1e1df..f077ef8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -76,7 +76,7 @@ $(obj)/zImage.lds $(obj)/zImage.coff.lds
@cp $< $@
clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
- empty.c zImage.coff.lds zImage.lds zImage.sandpoint
+ empty.c zImage zImage.coff.lds zImage.lds zImage.sandpoint
quiet_cmd_bootcc = BOOTCC $@
cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
^ permalink raw reply related
* Re: Freescale combined ethernet driver
From: Robin Gilks @ 2006-11-09 1:31 UTC (permalink / raw)
To: Jim Heck; +Cc: ppc embedded list
In-Reply-To: <45525367.10502@heckheck.com>
Jim Heck wrote:
> Assuming you have a filesystem and can get some software onto it (with
> the network not up...), the package 'iproute' contains the 'ip' tool
> that would quickly show you the name of the device using the command.
>
I've given up on the Freescale driver as its obviously broken and gone
back to the intermediate one (not the 8xx_io one!!) so I have a network
connection now (on eth0).
No filesystem yet as I've yet to write a platform support map for the
flash, initrd (ramfs) fails with an oops and root nfs fails as well even
though it manages the mount, it says it can't find an init (same fs on
2.4 is fine!!).
My head hurts...
--
Robin
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* [patch 1/3] ppc: booke reg MCSR msg misquoted
From: akpm @ 2006-11-09 3:52 UTC (permalink / raw)
To: paulus; +Cc: akpm, nkalmala, linuxppc-dev
From: nkalmala <nkalmala@gmail.com>
PPC/booke reg MCSR value misquoted
Signed-off-by: nkalmala <nkalmala@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <linuxppc-dev@ozlabs.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/ppc/kernel/traps.c~ppc-booke-reg-mcsr-msg-misquoted arch/ppc/kernel/traps.c
--- a/arch/ppc/kernel/traps.c~ppc-booke-reg-mcsr-msg-misquoted
+++ a/arch/ppc/kernel/traps.c
@@ -316,7 +316,7 @@ void machine_check_exception(struct pt_r
if (reason & MCSR_BUS_RBERR)
printk("Bus - Read Data Bus Error\n");
if (reason & MCSR_BUS_WBERR)
- printk("Bus - Read Data Bus Error\n");
+ printk("Bus - Write Data Bus Error\n");
if (reason & MCSR_BUS_IPERR)
printk("Bus - Instruction Parity Error\n");
if (reason & MCSR_BUS_RPERR)
_
^ permalink raw reply
* [patch 2/3] ppc4xx: Compilation fixes for PCI-less configs
From: akpm @ 2006-11-09 3:52 UTC (permalink / raw)
To: paulus; +Cc: akpm, wojtekka, linuxppc-dev
From: Wojtek Kaniewski <wojtekka@toxygen.net>
Fix compilation without PCI support for Bubinga, CPCI405 and EP405.
bios_fixup() for these boards uses functions available only with
CONFIG_PCI, so linker fails.
Signed-off-by: Wojtek Kaniewski <wojtekka@toxygen.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <linuxppc-dev@ozlabs.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc/platforms/4xx/bubinga.c | 2 ++
arch/ppc/platforms/4xx/cpci405.c | 2 ++
arch/ppc/platforms/4xx/ep405.c | 2 ++
3 files changed, 6 insertions(+)
diff -puN arch/ppc/platforms/4xx/bubinga.c~ppc4xx-compilation-fixes-for-pci-less-configs arch/ppc/platforms/4xx/bubinga.c
--- a/arch/ppc/platforms/4xx/bubinga.c~ppc4xx-compilation-fixes-for-pci-less-configs
+++ a/arch/ppc/platforms/4xx/bubinga.c
@@ -116,6 +116,7 @@ bubinga_early_serial_map(void)
void __init
bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
{
+#ifdef CONFIG_PCI
unsigned int bar_response, bar;
/*
@@ -212,6 +213,7 @@ bios_fixup(struct pci_controller *hose,
printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
#endif
+#endif
}
void __init
diff -puN arch/ppc/platforms/4xx/cpci405.c~ppc4xx-compilation-fixes-for-pci-less-configs arch/ppc/platforms/4xx/cpci405.c
--- a/arch/ppc/platforms/4xx/cpci405.c~ppc4xx-compilation-fixes-for-pci-less-configs
+++ a/arch/ppc/platforms/4xx/cpci405.c
@@ -126,6 +126,7 @@ cpci405_setup_arch(void)
void __init
bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
{
+#ifdef CONFIG_PCI
unsigned int bar_response, bar;
/* Disable region first */
@@ -167,6 +168,7 @@ bios_fixup(struct pci_controller *hose,
PCI_FUNC(hose->first_busno), bar,
&bar_response);
}
+#endif
}
void __init
diff -puN arch/ppc/platforms/4xx/ep405.c~ppc4xx-compilation-fixes-for-pci-less-configs arch/ppc/platforms/4xx/ep405.c
--- a/arch/ppc/platforms/4xx/ep405.c~ppc4xx-compilation-fixes-for-pci-less-configs
+++ a/arch/ppc/platforms/4xx/ep405.c
@@ -68,6 +68,7 @@ ep405_setup_arch(void)
void __init
bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
{
+#ifdef CONFIG_PCI
unsigned int bar_response, bar;
/*
* Expected PCI mapping:
@@ -130,6 +131,7 @@ bios_fixup(struct pci_controller *hose,
PCI_FUNC(hose->first_busno), bar, bar_response);
}
/* end work arround */
+#endif
}
void __init
_
^ permalink raw reply
* Re: [PATCH 2.6.19 2/4] ehca: hcp_phyp.c: correct page mapping in 64k page mode
From: Paul Mackerras @ 2006-11-09 6:36 UTC (permalink / raw)
To: Christoph Raisch
Cc: linuxppc-dev, Roland Dreier, linux-kernel, openib-general
In-Reply-To: <OF60EFC2CD.F8FB1D23-ONC1257220.00315F90-C1257220.0038B8E3@de.ibm.com>
Christoph Raisch writes:
> ioremap maps 4k pages on 4k kernels and on 64k pages on 64k kernels. So far
> the theory.
>
> This is true for memory.
And for I/O. :) ioremap updates the (Linux) page tables that map the
vmalloc/ioremap area, and that is at page granularity. So there is in
fact no difference in the end result in the page tables whether you
ask to map a small amount inside a page, or the whole page.
> On POWER the ebus memory is mapped by H_ENTER.
> The hypervisor checks for 4k page size on H_ENTER, reason see above.
The next part of the story is that the low-level MMU code on System-P
(pSeries) machines only does the H_ENTER when you access an I/O
mapping. It does H_ENTER for 4k pages for non-cacheable mappings,
and it only does the H_ENTER for the 4k subpages of a 64k page that
the kernel actually accesses.
So Roland is correct in his comment about how ioremap is called.
Regards,
Paul.
^ permalink raw reply
* Re: [RFC/PATCH 0/7] Powerpc MSI Implementation
From: Segher Boessenkool @ 2006-11-09 7:36 UTC (permalink / raw)
To: michael
Cc: Greg KH, linuxppc-dev, Eric W. Biederman, linux-pci,
David S. Miller
In-Reply-To: <1163028836.7630.16.camel@localhost.localdomain>
> Looking closer most of them are 5 bits, the high 5 bits, and happen to
> sit next to reserved fields (which must be zero), so reading the byte
> should work in practice. But for a few of them you'll get cruft in the
> low bits.
>
> I don't know what they were thinking when they decided to have 3 and 5
> bit capability fields, and then specify some of them as being a byte
> wide as well. Perhaps the spec committee had a big night out ;)
>
> I was going to write a generic version of pci_find_ht_capability() (as
> suggested by Segher), so along with that I'll clean up the #defines to
> just be the 3 or 5 bit capability codes, and then have a shift for
> getting the capability out of the byte.
>
> Users will still need to know if they're looking for a 3 or 5 bit
> capability, but we can encapsulate that in pci_find_ht_capability()
> and
> hopefully most people won't have to see the difference.
Keep the defines the full 8 bits and put all the knowledge
about which bits are relevant into pci_find_ht_capability()?
If you do shifting you can get clashes (say, 0b00110 vs. 0b110),
and this would make for simpler code, too.
Segher
^ permalink raw reply
* Re: APUS and IOs question
From: Simon Richter @ 2006-11-09 14:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1162931605.28571.491.camel@localhost.localdomain>
Hi,
Benjamin Herrenschmidt schrieb:
> Can you give me a proper explanation of the whole memory map story on it
> so I get a better idea of how invasive handling it would be ?
On APUS systems, you have two (major) kinds of memory, that on the Amiga
board and that on the CPU board. The former is generally mapped at
address zero, but you don't want to use it except as DMA buffers when
talking to the internal hardware (because the internal hardware doesn't
see the memory on the CPU board).
The memory on the CPU board is the "main" memory for Linux (because
there is more of it, and the access is faster), but its location is
assigned dynamically during the boot process, and depends on the size of
the memory and on other boards installed.
My plan for moving APUS to arch/powerpc involves writing a new
bootloader (I'm currently hacking binutils to support AmigaOS binaries)
that builds a proper flattened device tree and calls the kernel, but I'm
not sure where the kernel virtual mapping that allows the kernel to run
from a fixed address should be set up -- if in the bootloader, the
kernel needs to be aware that changing the MMU settings will yield
interesting results, and if in the kernel, we need some platform
specific init code to handle that.
Simon
^ permalink raw reply
* Re: Freescale combined ethernet driver
From: Vitaly Bordug @ 2006-11-09 14:49 UTC (permalink / raw)
To: robin.gilks; +Cc: ppc embedded list
In-Reply-To: <45515913.3080206@tait.co.nz>
On Wed, 08 Nov 2006 17:12:03 +1300
Robin Gilks <robin.gilks@tait.co.nz> wrote:
> OK - I give up - whats the name of the device?
>
> I've tried eth0, fsl-cpm-fec0 (and other combinations) with a
> commandline of the form:
>
> ip=172.25.206.113:172.25.140.15::255.255.0.0:unset:fsl-cpm-fec0:off \
> panic=1 console=ttyCPM0
>
I am not following why you're touching netdev name here... Your problem clearly points to the unregistered platform device (which should be added to the identification code that maps system to the platform device list). In short, bsp code does name matching of the supported boards, and ties it to the enum of platform devices aught to be registered for this board. It registers nothing by default, and since fs_enet fail to found anything suitable on platform bus, not network devices created.
Yet it may be not the case of course - too less information to be sure.
Assuming it is not relevant to you anymore, just for archive purposes.
--
Sincerely,
Vitaly
^ permalink raw reply
* [RFC,PATCH 0/2] Oprofile-on-Cell prereqs
From: Kevin Corry @ 2006-11-09 14:58 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, oprofile-list, linux-kernel
Here are two patches that provide some prerequisites for the upcoming
Oprofile-on-Cell patches, which Maynard Johnson will be posting.
These patches are against the 2.6.18-arnd5 tree.
1. cbe_pmu_interrupts.diff
Add routines for managing the Cell PMU interrupts.
The following routines are added to arch/powerpc/platforms/cell/pmu.c:
cbe_clear_pm_interrupts()
cbe_enable_pm_interrupts()
cbe_disable_pm_interrupts()
cbe_query_pm_interrupts()
pm_init_IRQ()
This also adds two routines to arch/powerpc/platforms/cell/interrupt.c
to manipulate the IIC_IS and IIC_IR registers:
iic_clear_pmi_interrupt()
iic_set_interrupt_routing()
We are still working on how to clean up cbe_clear_pm_interrupts() and
cbe_enable_pm_interrupts() so we hopefully won't need to call the
iic_ routines (and also not need the additions to interrupt.c).
2. export_hrtimer_forward.diff
Add a symbol-export for kernel/hrtimer.c::hrtimer_forward(). This routine
is needed by the upcoming Oprofile-for-Cell patches, since Oprofile can
be built as a module.
--
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
^ permalink raw reply
* [RFC,PATCH 1/2] Oprofile-on-Cell prereqs
From: Kevin Corry @ 2006-11-09 15:01 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, oprofile-list, linux-kernel
In-Reply-To: <200611090858.11590.kevcorry@us.ibm.com>
Add routines for managing the Cell PMU interrupts.
The following routines are added to arch/powerpc/platforms/cell/pmu.c:
cbe_clear_pm_interrupts()
cbe_enable_pm_interrupts()
cbe_disable_pm_interrupts()
cbe_query_pm_interrupts()
pm_init_IRQ()
This also adds two routines to arch/powerpc/platforms/cell/interrupt.c
to manipulate the IIC_IS and IIC_IR registers:
iic_clear_pmi_interrupt()
iic_set_interrupt_routing()
We are still working on how to clean up cbe_clear_pm_interrupts() and
cbe_enable_pm_interrupts() so we hopefully won't need to call the
iic_ routines (and also not need the additions to interrupt.c).
Signed-Off-By: Kevin Corry <kevcorry@us.ibm.com>
Signed-Off-By: Carl Love <carll@us.ibm.com>
Index: linux-2.6.18-arnd5/arch/powerpc/platforms/cell/pmu.c
===================================================================
--- linux-2.6.18-arnd5.orig/arch/powerpc/platforms/cell/pmu.c
+++ linux-2.6.18-arnd5/arch/powerpc/platforms/cell/pmu.c
@@ -23,10 +23,12 @@
*/
#include <linux/types.h>
+#include <linux/interrupt.h>
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/reg.h>
#include <asm/spu.h>
+#include <asm/pmc.h>
#include "cbe_regs.h"
#include "interrupt.h"
@@ -339,3 +341,78 @@ void cbe_read_trace_buffer(u32 cpu, u64
}
EXPORT_SYMBOL_GPL(cbe_read_trace_buffer);
+/*
+ * Enabling/disabling interrupts for the entire performance monitoring unit.
+ */
+
+u32 cbe_clear_pm_interrupts(u32 cpu)
+{
+ u32 mask;
+
+ /* First read pm_status to clear the interrupt -- order is important! */
+ mask = cbe_read_pm(cpu, pm_status);
+
+ /* Then clear the PMI interrupt bit. */
+ iic_clear_pmi_interrupt(cpu);
+
+ return mask;
+}
+EXPORT_SYMBOL_GPL(cbe_clear_pm_interrupts);
+
+void cbe_enable_pm_interrupts(u32 cpu, u32 thread, u32 mask)
+{
+ /* Set which node and thread will handle the next interrupt */
+ iic_set_interrupt_routing(cpu, thread, 0);
+
+ /* Enable pm interrupts */
+ if (mask)
+ cbe_write_pm(cpu, pm_status, mask);
+}
+EXPORT_SYMBOL_GPL(cbe_enable_pm_interrupts);
+
+void cbe_disable_pm_interrupts(u32 cpu)
+{
+ cbe_write_pm(cpu, pm_status, 0);
+ cbe_clear_pm_interrupts(cpu);
+}
+EXPORT_SYMBOL_GPL(cbe_disable_pm_interrupts);
+
+u32 cbe_query_pm_interrupts(u32 cpu)
+{
+ return cbe_read_pm(cpu, pm_status);
+}
+EXPORT_SYMBOL_GPL(cbe_query_pm_interrupts);
+
+static irqreturn_t cbe_pm_irq(int irq, void *dev_id, struct pt_regs *regs)
+{
+ perf_irq(regs);
+ return IRQ_HANDLED;
+}
+
+int __init pm_init_IRQ(void)
+{
+ unsigned int irq;
+ int rc, node;
+
+ for_each_cbe_node(node) {
+ irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
+ (node << IIC_IRQ_NODE_SHIFT));
+ if (irq == NO_IRQ) {
+ printk("ERROR: Unable to allocate irq for node %d\n",
+ node);
+ return -EINVAL;
+ }
+
+ rc = request_irq(irq, cbe_pm_irq,
+ IRQF_DISABLED, "cbe-pmu-0", NULL);
+ if (rc) {
+ printk("ERROR: Request for irq on node %d failed\n",
+ node);
+ return rc;
+ }
+ }
+
+ return 0;
+}
+arch_initcall(pm_init_IRQ);
+
Index: linux-2.6.18-arnd5/arch/powerpc/platforms/cell/pmu.h
===================================================================
--- linux-2.6.18-arnd5.orig/arch/powerpc/platforms/cell/pmu.h
+++ linux-2.6.18-arnd5/arch/powerpc/platforms/cell/pmu.h
@@ -22,8 +22,8 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#ifndef __PERFMON_H__
-#define __PERFMON_H__
+#ifndef __CELL_PMU_H__
+#define __CELL_PMU_H__
enum pm_reg_name {
group_control,
@@ -54,4 +54,20 @@ extern void cbe_disable_pm(u32 cpu);
extern void cbe_read_trace_buffer(u32 cpu, u64 *buf);
-#endif
+extern void cbe_enable_pm_interrupts(u32 cpu, u32 thread, u32 mask);
+extern void cbe_disable_pm_interrupts(u32 cpu);
+extern u32 cbe_query_pm_interrupts(u32 cpu);
+extern u32 cbe_clear_pm_interrupts(u32 cpu);
+
+/* FIXME: Don't assume each node always has two logical CPUs.
+ * Also, we should definitely find a better header file to put these in.
+ */
+#define for_each_cbe_node(node) \
+ for ((node) = 0; (node) < num_possible_cpus() >> 1; (node)++)
+
+#define for_each_online_cbe_node(node) \
+ for ((node) = 0; (node) < num_online_cpus() >> 1; (node)++)
+
+#define cbe_cpu_to_node(cpu) ((cpu) >> 1)
+
+#endif /* __CELL_PMU_H__ */
Index: linux-2.6.18-arnd5/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linux-2.6.18-arnd5.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linux-2.6.18-arnd5/arch/powerpc/platforms/cell/interrupt.c
@@ -397,3 +397,27 @@ void __init iic_init_IRQ(void)
/* Enable on current CPU */
iic_setup_cpu();
}
+
+void iic_clear_pmi_interrupt(int cpu)
+{
+ /* Write 1 to PMI bit of the IIC_IS register to clear the interrupt. */
+ struct cbe_iic_regs __iomem *iic_regs = cbe_get_cpu_iic_regs(cpu);
+ out_be64(&iic_regs->iic_is, CBE_IIC_IS_PMI);
+}
+
+void iic_set_interrupt_routing(int cpu, int thread, int priority)
+{
+ struct cbe_iic_regs __iomem *iic_regs = cbe_get_cpu_iic_regs(cpu);
+ struct cbe_iic_ir iic_ir;
+ int node = cpu >> 1;
+
+ /* Set which node and thread will handle the next interrupt */
+ iic_ir.val = 0;
+ iic_ir.priority = priority;
+ iic_ir.dst_node_id = node;
+ if (thread == 0)
+ iic_ir.dst_unit_id = CBE_IIC_IR_PT0;
+ else
+ iic_ir.dst_unit_id = CBE_IIC_IR_PT1;
+ out_be64(&iic_regs->iic_ir.val, iic_ir.val);
+}
Index: linux-2.6.18-arnd5/arch/powerpc/platforms/cell/interrupt.h
===================================================================
--- linux-2.6.18-arnd5.orig/arch/powerpc/platforms/cell/interrupt.h
+++ linux-2.6.18-arnd5/arch/powerpc/platforms/cell/interrupt.h
@@ -83,5 +83,8 @@ extern u8 iic_get_target_id(int cpu);
extern void spider_init_IRQ(void);
+extern void iic_clear_pmi_interrupt(int cpu);
+extern void iic_set_interrupt_routing(int cpu, int thread, int priority);
+
#endif
#endif /* ASM_CELL_PIC_H */
^ permalink raw reply
* [RFC,PATCH 2/2] Oprofile-on-Cell prereqs: Export hrtimer_forward
From: Kevin Corry @ 2006-11-09 15:02 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, oprofile-list, linux-kernel
In-Reply-To: <200611090858.11590.kevcorry@us.ibm.com>
Add a symbol-export for kernel/hrtimer.c::hrtimer_forward(). This routine
is needed by the upcoming Oprofile-for-Cell patches, since Oprofile can
be built as a module.
Signed-Off-By: Kevin Corry <kevcorry@us.ibm.com>
Index: linux-2.6.18-arnd5/kernel/hrtimer.c
===================================================================
--- linux-2.6.18-arnd5.orig/kernel/hrtimer.c
+++ linux-2.6.18-arnd5/kernel/hrtimer.c
@@ -335,6 +335,7 @@ hrtimer_forward(struct hrtimer *timer, k
return orun;
}
+EXPORT_SYMBOL_GPL(hrtimer_forward);
/*
* enqueue_hrtimer - internal function to (re)start a timer
^ permalink raw reply
* Re: 2.6.19-rc5-mm1 -- ppc64 ohci-hdc.c compile failure
From: Andy Whitcroft @ 2006-11-09 15:04 UTC (permalink / raw)
To: Andrew Morton, Nicolas DET
Cc: Steve Fox, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20061108015452.a2bb40d2.akpm@osdl.org>
We are seeing compile failures on ppc64 in ohci-hcd.c as below:
In file included from drivers/usb/host/ohci-hcd.c:949:
drivers/usb/host/ohci-ppc-of.c: In function `ohci_hcd_ppc_of_init':
drivers/usb/host/ohci-ppc-of.c:272: warning: int format, different type
arg (arg 2)
drivers/usb/host/ohci-ppc-of.c:272: warning: int format, different type
arg (arg 3)
drivers/usb/host/ohci-ppc-of.c: At top level:
drivers/usb/host/ohci-ppc-of.c:282: error: redefinition of `__inittest'
drivers/usb/host/ohci-pci.c:252: error: `__inittest' previously defined here
drivers/usb/host/ohci-ppc-of.c:282: error: redefinition of `init_module'
drivers/usb/host/ohci-pci.c:252: error: `init_module' previously defined
here
drivers/usb/host/ohci-ppc-of.c:283: error: redefinition of `__exittest'
drivers/usb/host/ohci-pci.c:260: error: `__exittest' previously defined here
drivers/usb/host/ohci-ppc-of.c:283: error: redefinition of `cleanup_module'
drivers/usb/host/ohci-pci.c:260: error: `cleanup_module' previously
defined here
Seems that the patch below has introduced USB_OHCI_HCD_PPC_OF enabled by
default. When it and CONFIG_USB_OHCI_HCD_PPC_SOC are enabled which
occured by default on my config then we end up with two module_init()
calls, which is illegal.
powerpc-add-of_platform-support-for-ohci-bigendian-hc
I am guessing that we are only meant to be able to have one of these
defined at a time? I changed the default to n for this and I could at
least compile the kernel, but I am sure thats not the right fix.
Nicolas?
-apw
^ permalink raw reply
* MPC82xx : ECC and PCI problem
From: Laurent Lagrange @ 2006-11-09 15:11 UTC (permalink / raw)
To: 'Laurent Lagrange'; +Cc: linuxppc-embedded
Hello,
I work on a custom monarch PMC MPC82xx board.
This board embeds an ECC device which can be enabled or disabled.
When ECC is disabled all PCI accesses work fine.
When ECC is enabled and PCI disabled, all work fine.
But when ECC and PCI are enabled, the first PCI accesses give the following
:
>>>
Linux/PPC load: devfs=mount rootfstype=tmpfs root=/dev/ram rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.9-xxx (version gcc 3.2.3) #1 Thu Feb 16 12:02:39 CET 2006
Built 1 zonelists
Kernel command line: devfs=mount rootfstype=tmpfs root=/dev/ram rw
PID hash table entries: 1024 (order: 10, 16384 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 123904k available (1072k kernel code, 368k data, 72k init, 0k
highmem)
Calibrating delay loop... 177.15 BogoMIPS (lpj=88576)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
NET: Registered protocol family 16
PCI: Probing PCI hardware
Machine check in kernel mode.
Caused by (from SRR1=81032): Machine check signal
Oops: machine check, sig: 7 [#1]
NIP: C00137DC LR: C0013820 SP: C0491E40 REGS: c0491d90 TRAP: 0200 Not
tainted
MSR: 00081032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c08fcba0[1] 'swapper' THREAD: c0490000Last syscall: 120
GPR00: C008ECE8 C0491E40 C08FCBA0 00000000 00000000 FF010906 00000001
C0491E78
GPR08: 2F9DEB58 00000002 00000800 FF010904 C02B21DC 00015710 FDFFFFFF
FF010000
GPR16: FFFF7FFF EFFFDFFF 00200000 FFF7FFFF 00000000 BFFFEDBF 00000000
80000000
GPR24: 00000000 FFFFFF7E 00000000 00000001 C0491E98 00009032 C04A3280
C04A3280
NIP [c00137dc] indirect_read_config+0xc8/0x11c
LR [c0013820] indirect_read_config+0x10c/0x11c
Call trace:
[c008ece8] pci_bus_read_config_byte+0x40/0x60
[c01648a4] pci_scan_device+0x24/0x198
[c0164a30] pci_scan_single_device+0x18/0x70
[c0164ab8] pci_scan_slot+0x30/0x98
[c0164b4c] pci_scan_child_bus+0x2c/0xd0
[c0164db0] pci_scan_bus_parented+0x184/0x198
[c015e488] pcibios_init+0x64/0x134
[c015a87c] do_initcalls+0x5c/0xfc
[c015a93c] do_basic_setup+0x20/0x30
[c0003a08] init+0x2c/0xf0
[c000aae4] kernel_thread+0x44/0x60
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
>>>
Has anyone encountered same problems ?
Relationships between ECC, PCI, cache ?
Any idea would be welcome
Thanks all
Laurent
^ permalink raw reply
* [PATCH] Fix compile warnings with CONFIG_PM=n
From: Olaf Hering @ 2006-11-09 17:53 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Fix compile warnings with CONFIG_PM=n
arch/powerpc/platforms/powermac/feature.c:489: warning: 'save_gpio_levels' defined but not used
arch/powerpc/platforms/powermac/feature.c:490: warning: 'save_gpio_extint' defined but not used
arch/powerpc/platforms/powermac/feature.c:491: warning: 'save_gpio_normal' defined but not used
arch/powerpc/platforms/powermac/feature.c:492: warning: 'save_unin_clock_ctl' defined but not used
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/powerpc/platforms/powermac/feature.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/feature.c
+++ linux-2.6/arch/powerpc/platforms/powermac/feature.c
@@ -486,10 +486,6 @@ static long heathrow_sound_enable(struct
static u32 save_fcr[6];
static u32 save_mbcr;
-static u32 save_gpio_levels[2];
-static u8 save_gpio_extint[KEYLARGO_GPIO_EXTINT_CNT];
-static u8 save_gpio_normal[KEYLARGO_GPIO_CNT];
-static u32 save_unin_clock_ctl;
static struct dbdma_regs save_dbdma[13];
static struct dbdma_regs save_alt_dbdma[13];
@@ -1548,6 +1544,10 @@ void g5_phy_disable_cpu1(void)
#ifdef CONFIG_PM
+static u32 save_gpio_levels[2];
+static u8 save_gpio_extint[KEYLARGO_GPIO_EXTINT_CNT];
+static u8 save_gpio_normal[KEYLARGO_GPIO_CNT];
+static u32 save_unin_clock_ctl;
static void keylargo_shutdown(struct macio_chip *macio, int sleep_mode)
{
^ permalink raw reply
* Re: [Cbe-oss-dev] [RFC, PATCH 2/2] Oprofile-on-Cell prereqs: Export hrtimer_forward
From: Arnd Bergmann @ 2006-11-09 18:14 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, Kevin Corry, oprofile-list, linux-kernel
In-Reply-To: <200611090902.39714.kevcorry@us.ibm.com>
On Thursday 09 November 2006 16:02, Kevin Corry wrote:
> Add a symbol-export for kernel/hrtimer.c::hrtimer_forward(). This routine
> is needed by the upcoming Oprofile-for-Cell patches, since Oprofile can
> be built as a module.
>
> Signed-Off-By: Kevin Corry <kevcorry@us.ibm.com>
Applied, thanks. I'll forward it along with the other patches when
the set is complete.
Arnd <><
^ permalink raw reply
* Re: ppc32 PIO recovery mecanism
From: Olaf Hering @ 2006-11-09 18:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list
In-Reply-To: <20061106062559.GB4361@suse.de>
On Mon, Nov 06, Olaf Hering wrote:
> On Mon, Nov 06, David Woodhouse wrote:
>
> > Did ISAPnP get fixed?
>
> I have to check, only PReP systems have ISA slots.
isapnp_init() has your change. I loaded all the ISA network drivers,
none of them crashed the pismo.
Also, I do not plan to reenable CONFIG_ISA. And there is no autoprobing
for ISA hardware, so I dont think it will cause any trouble if distros
ship stuff like aha1542.ko for 32bit kernels.
^ permalink raw reply
* [PATCH] adding ROM chips to device tree: respin
From: Vitaly Wool @ 2006-11-09 18:41 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev
Hello folks,
inlined below is the patch which adds support for flash device
descriptions to the OF device tree. It's inspired by and partially
borrowed from Sergei's patch which can be found at
http://patchwork.ozlabs.org/linuxppc/patch?id=6526 but arranges things
in a different way.
It should be used together with the corresponding MTD layer extension
the current version of which was recently posted to linux-mtd list for
discussion and can be found at
http://lists.infradead.org/pipermail/linux-mtd/2006-November/016700.html.
In fact, currently this description can handle only flash devices mapped
into memory in a linear way.
This patch is a respin of the patch which can be found at
http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025133.html
with comments from Sergei and Josh taken into account.
Documentation/powerpc/booting-without-of.txt | 38 +++++++++++++++++++++++++++
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/rom.c | 33 +++++++++++++++++++++++
3 files changed, 72 insertions(+)
Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Index: powerpc/Documentation/powerpc/booting-without-of.txt
===================================================================
--- powerpc.orig/Documentation/powerpc/booting-without-of.txt
+++ powerpc/Documentation/powerpc/booting-without-of.txt
@@ -6,6 +6,8 @@
IBM Corp.
(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
Freescale Semiconductor, FSL SOC and 32-bit additions
+(c) 2006 MontaVista Software, Inc.
+ Flash chip node definition
May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
@@ -1693,6 +1695,42 @@ platforms are moved over to use the flat
};
};
+ g) Flash chip nodes
+
+ Flash chips (Memory Technology Devices) are often used for solid state
+ file systems on embedded devices.
+
+ Required properties:
+
+ - device_type : has to be "rom"
+ - compatible : Should be the name of the MTD driver. Currently, this is
+ most likely to be "physmap".
+ - regs : Offset and length of the register set (or memory mapping) for
+ the device.
+
+ Recommended properties :
+
+ - bank-width : Width of the flash data bus in bytes. Required
+ for the NOR flashes (compatible == "physmap" and others) ONLY.
+ - partitions : Several pairs of 32-bit values where the first value is
+ partition's offset from the start of the MTD device and the second
+ one is partition size in bytes with LSB used to signify a read only
+ partititon (so, the parition size should always be an even number).
+ - partition-names : The list of concatenated zero terminated strings
+ representing the partition names.
+
+ Example:
+
+ flash@ff000000 {
+ device_type = "rom";
+ compatible = "physmap";
+ regs = <ff000000 01000000>;
+ bank-width = <4>;
+ partitions = <00000000 00f80000
+ 00f80000 00080001>;
+ partition-names = "fs\0firmware";
+ };
+
More devices will be defined as this spec matures.
Index: powerpc/arch/powerpc/sysdev/Makefile
===================================================================
--- powerpc.orig/arch/powerpc/sysdev/Makefile
+++ powerpc/arch/powerpc/sysdev/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
+obj-$(CONFIG_MTD) += rom.o
ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_I8259) += i8259.o
Index: powerpc/arch/powerpc/sysdev/rom.c
===================================================================
--- /dev/null
+++ powerpc/arch/powerpc/sysdev/rom.c
@@ -0,0 +1,33 @@
+/*
+ * arch/powerpc/sysdev/flash.c
+ *
+ * Flash memory registration
+ *
+ * (C) 2006 MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/kernel.h>
+#include <asm/of_device.h>
+
+static int __init powerpc_flash_init(void)
+{
+ struct device_node *node = NULL;
+
+ /*
+ * Register all the devices which type is "rom"
+ */
+ while ((node = of_find_node_by_type(node, "rom")) != NULL) {
+ if (node->name == NULL) {
+ printk(KERN_WARNING "powerpc_flash_init: found 'rom' "
+ "device, but with no name, skipping...\n");
+ continue;
+ }
+ of_platform_device_create(node, node->name, NULL);
+ }
+ return 0;
+}
+
+arch_initcall(powerpc_flash_init);
^ permalink raw reply
* Re: Freescale combined ethernet driver
From: Robin Gilks @ 2006-11-09 20:27 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: ppc embedded list
In-Reply-To: <20061109174947.415c7f7f@vitb.ru.mvista.com>
Vitaly Bordug wrote:
> I am not following why you're touching netdev name here... Your problem clearly points to the unregistered platform device (which should be added to the identification code that maps system to the platform device list). In short, bsp code does name matching of the supported boards, and ties it to the enum of platform devices aught to be registered for this board. It registers nothing by default, and since fs_enet fail to found anything suitable on platform bus, not network devices created.
>
> Yet it may be not the case of course - too less information to be sure.
>
> Assuming it is not relevant to you anymore, just for archive purposes.
>
Is there a howto that explains in simple terms (i.e. not "do like board
X but I'm not going to tell which bits of the code are crap" but an
actual interface spec) on how to create this (as far as I can see
totally undocumented) platform device.
BTW: the code is NOT the documentation - that is the 'how' not the 'why'!
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* Re: Freescale combined ethernet driver
From: Andy Fleming @ 2006-11-09 20:47 UTC (permalink / raw)
To: robin.gilks; +Cc: ppc embedded list
In-Reply-To: <45538F14.5020205@tait.co.nz>
On Nov 9, 2006, at 14:27, Robin Gilks wrote:
>
> Is there a howto that explains in simple terms (i.e. not "do like
> board
> X but I'm not going to tell which bits of the code are crap" but an
> actual interface spec) on how to create this (as far as I can see
> totally undocumented) platform device.
>
> BTW: the code is NOT the documentation - that is the 'how' not the
> 'why'!
Documentation/driver-model/*
^ 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