icswx is a PowerPC co-processor instruction to send data to a
co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
the owning process are registered in the window context of the
co-processor at initial time. When the icswx instruction is executed,
the L2 generates a cop-reg transa
Scott Wood wrote:
> On Mon, 11 Oct 2010 12:02:15 -0500
> wrote:
>
>> Re-ordering your questions a bit:
>>
>>> What board are you using? What kernel?
>> One of 2 boards: Either an Embedded Planet or a Performance Tech uTCA
>> board based on the MPC8641D, running the 2.6.26 as supplied by EP.
>
>
Hi Grant,
On Fri, Oct 8, 2010 at 4:34 AM, Grant Likely wrote:
> Reaching way back into the past
Indeed
> John, did you ever solve your issue here? Comments below.
The fix in our case was to explicitly add child nodes to the PCI
controller, with interrupt-parent and interrupts properties.
tiejun.chen wrote:
> david.hag...@gmail.com wrote:
>> OK, using 224 as the MPIC interrupt number, and attempting to map it via
>> irq_create_mapping(0,224) gives me a kernel seg fault:
>
> This should not be correct without initialing MSI for MPIC host. As I comment
> on
> another email, please r
Scott Wood wrote:
> On Mon, 11 Oct 2010 17:51:39 +0800
> "tiejun.chen" wrote:
>
>> Maybe you can check the file, ppc4xx_pci.c since ppc4xx also can support EP
>> as I
>> previously said. And sounds Scott will do something to support EP for
>> Freescale
>> chip.
>
> What did I get signed up for
On 10/11/2010 03:33 PM, Thomas Gleixner wrote:
> On Tue, 12 Oct 2010, Benjamin Herrenschmidt wrote:
>
>> On Mon, 2010-10-11 at 13:11 -0700, Tim Pepper wrote:
>>> I'm not necessarily wanting to open up the age old question of "what is
>>> a good HZ", but we were doing some testing on timer tick ove
On Mon 11 Oct at 22:32:06 +0200 t...@linutronix.de said:
> On Mon, 11 Oct 2010, Tim Pepper wrote:
>
> > I'm not necessarily wanting to open up the age old question of "what is
> > a good HZ", but we were doing some testing on timer tick overheads for
> > HPC applications and this came up...
>
> Y
I'm not necessarily wanting to open up the age old question of "what is
a good HZ", but we were doing some testing on timer tick overheads for
HPC applications and this came up...
Below is a minimal hack at enabling lower HZ values. The kernel builds
and boots for me on x86_64 (simple laptop and
On 2010-10-11 21:13, Dan Carpenter wrote:
> This should pass "buf" to bvec_kunmap_irq() instead of "bv". The api is
> like kmap_atomic() instead of kmap().
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
> index e9da874..03688c2 100644
> --- a
On Tue, 12 Oct 2010, Benjamin Herrenschmidt wrote:
> On Mon, 2010-10-11 at 13:11 -0700, Tim Pepper wrote:
> > I'm not necessarily wanting to open up the age old question of "what is
> > a good HZ", but we were doing some testing on timer tick overheads for
> > HPC applications and this came up...
On Mon, 2010-10-11 at 13:11 -0700, Tim Pepper wrote:
> I'm not necessarily wanting to open up the age old question of "what is
> a good HZ", but we were doing some testing on timer tick overheads for
> HPC applications and this came up...
Note that this is also very useful when working on CPU prot
(cc linuxppc-dev@lists.ozlabs.org)
On Mon, 11 Oct 2010 15:30:22 +0100
Mel Gorman wrote:
> On Sat, Oct 09, 2010 at 04:57:18AM -0500, pac...@kosh.dhis.org wrote:
> > (What a big Cc: list... scripts/get_maintainer.pl made me do it.)
> >
> > This will be a long story with a weak conclusion, sorry a
On Mon, 11 Oct 2010, Tim Pepper wrote:
> I'm not necessarily wanting to open up the age old question of "what is
> a good HZ", but we were doing some testing on timer tick overheads for
> HPC applications and this came up...
Yeah. This comes always up when the timer tick overhead on HPC is
tested
This should pass "buf" to bvec_kunmap_irq() instead of "bv". The api is
like kmap_atomic() instead of kmap().
Signed-off-by: Dan Carpenter
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index e9da874..03688c2 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@
Hi,
We have found a poorly documented jumper on our boards that force pci-mode
to 32bit instead of 64bit. It seems to have an effect on RapidIO aswell
since the host now completes the enumeration process including finding the
other board. However, as soon as the agent starts the peer discovery
pro
On Mon, 11 Oct 2010 12:02:15 -0500
wrote:
> Re-ordering your questions a bit:
>
> > What board are you using? What kernel?
>
> One of 2 boards: Either an Embedded Planet or a Performance Tech uTCA
> board based on the MPC8641D, running the 2.6.26 as supplied by EP.
That's a very old kernel.
On Mon, 11 Oct 2010 17:55:07 +0800
"tiejun.chen" wrote:
> david.hag...@gmail.com wrote:
> > OK, using 224 as the MPIC interrupt number, and attempting to map it via
> > irq_create_mapping(0,224) gives me a kernel seg fault:
>
> This should not be correct without initialing MSI for MPIC host. As
Re-ordering your questions a bit:
> What board are you using? What kernel?
One of 2 boards: Either an Embedded Planet or a Performance Tech uTCA
board based on the MPC8641D, running the 2.6.26 as supplied by EP.
> On Sat, 9 Oct 2010 10:52:49 -0500
> Documentation/powerpc/dts-bindings/fsl/mpic.
On Sat, 9 Oct 2010 10:52:49 -0500
wrote:
> First of all - where is all of this documented? There seems to be a great
> deal of "oral tradition" type knowledge here, but is any of it actually
> written down somewhere? (see below for examples)
Documentation/powerpc/dts-bindings/fsl/mpic.txt
Plus
On Mon, 11 Oct 2010 17:51:39 +0800
"tiejun.chen" wrote:
> Maybe you can check the file, ppc4xx_pci.c since ppc4xx also can support EP
> as I
> previously said. And sounds Scott will do something to support EP for
> Freescale
> chip.
What did I get signed up for? :-)
-Scott
__
> You should define MSI device nodes on your target dts. And you can refer
> to the
> file, mpc8572ds.dts.
I see nothing in that file that defines any MSIs. I see code that looks
like it maps ROOT COMPLEX MODE interrupts on regular PCI interfaces, which
IS NOT WHAT I AM DOING.
Since it seems I h
Hi Grant,
On 10/08/2010 07:06 PM, Grant Likely wrote:
> On Fri, Oct 08, 2010 at 10:50:50AM +0200, Holger brunck wrote:
>>> On Wed, Oct 6, 2010 at 3:53 AM, Heiko Schocher wrote:
>>
Wouldn;t it be good, just if we need a PHY (on calling fs_enet_open)
to look if there is one?
Som
> BUT if we take into consideration that:
> 1. Freescale is a serious dude in the hood and on the whole does a good
> job with its products and their Linux support.
Sure but that's irrelevant to the technical problem at hand :-)
> 2. The P2020 does state it has an MSI mechanism support (althoug
On Mon, 2010-10-11 at 17:51 +0800, tiejun.chen wrote:
>
> You should define MSI device nodes on your target dts. And you can refer to
> the
> file, mpc8572ds.dts.
>
> Often U-Boot dose not generate MSI information and embed that to dtb.
>
> >
> > But even assuming you can define these nodes at
Benjamin Herrenschmidt wrote:
- pcie_portdrv_probe() will be called for every BRIDGE class PCI device. P2020 PCIe is a PCI-PCI BRIDGE class so no problem here.
- The code will continue to check that we have PCI_CAP_ID_EXP capability, which we have and continue to pcie_port_device_register().
david.hag...@gmail.com wrote:
> OK, using 224 as the MPIC interrupt number, and attempting to map it via
> irq_create_mapping(0,224) gives me a kernel seg fault:
This should not be correct without initialing MSI for MPIC host. As I comment on
another email, please refer to the file, arch/powerpc/s
david.hag...@gmail.com wrote:
> First of all - where is all of this documented? There seems to be a great
> deal of "oral tradition" type knowledge here, but is any of it actually
> written down somewhere? (see below for examples)
>
>> On Thu, 7 Oct 2010 15:12:26 -0500
>> This is asking for the 25
27 matches
Mail list logo
