Scott Wood wrote:
> On Thu, 14 Oct 2010 11:27:09 +0800
> "tiejun.chen" wrote:
>
>> tiejun.chen wrote:
>>> Scott Wood wrote:
On Wed, 13 Oct 2010 09:17:01 +0800
"tiejun.chen" wrote:
> Scott Wood wrote:
>> The crash is happening somewhere in mpic_set_irq_type():
> Agreed.
> Well, it was a coworker who added the workaround, so I assume we're
> already aware of the issue.
>
> The description of NIRQ is vague enough that it's hard to argue that
> Linux's expectations of what it means are justified.
>
Well, I now can actually interrupt the PPC from my host processor!
On Thu, 14 Oct 2010 12:20:55 -0500
wrote:
> > It comes from FRR[NIRQ]. It seems that this chip takes a
> > less-than-useful interpretation of what that field means -- it gives
> > the actual number of sources, not the size of the sparsely populated
> > array.
> Perhaps you might want to have a t
Hallelujah and Huzzah! I finally got my vector!
I back-ported the MPIC_BROKEN_FRR_NIRQS flag and code to our kernel, and
the kernel is now letting me have my vector! Now I can actually see if the
dang thing works!
THANK YOU EVERYBODY for putting up with me on this!
> It comes from FRR[NIRQ]. It
On Thu, 14 Oct 2010 11:22:45 -0500
wrote:
> As I read the code:
> /* Read feature register, calculate num CPUs and, for non-ISU
>* MPICs, num sources as well. On ISU MPICs, sources are counted
>* as ISUs are added
>*/
> greg_feature = mpic_read(mpic->gregs, M
I may have a clue (you might not think so, but...):
I've configured the init thusly:
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN ,
0, 256,
" MPIC ");
Which, as I read the code, should disable the ISU stuff.
I've seeing this on b
On Thu, 14 Oct 2010 11:27:09 +0800
"tiejun.chen" wrote:
> tiejun.chen wrote:
> > Scott Wood wrote:
> >> On Wed, 13 Oct 2010 09:17:01 +0800
> >> "tiejun.chen" wrote:
> >>
> >>> Scott Wood wrote:
> The crash is happening somewhere in mpic_set_irq_type():
> >>> Agreed. That is just where I poi
tiejun.chen wrote:
> Scott Wood wrote:
>> On Wed, 13 Oct 2010 09:17:01 +0800
>> "tiejun.chen" wrote:
>>
>>> Scott Wood wrote:
The crash is happening somewhere in mpic_set_irq_type():
>>> Agreed. That is just where I pointed out on my email replied for OOPS. To
>>> enable
>>> DBG to figure ou
Scott Wood wrote:
> On Wed, 13 Oct 2010 09:17:01 +0800
> "tiejun.chen" wrote:
>
>> Scott Wood wrote:
>>> The crash is happening somewhere in mpic_set_irq_type():
>> Agreed. That is just where I pointed out on my email replied for OOPS. To
>> enable
>> DBG to figure out 'src' and 'mpic->irq_count
> On Wed, 13 Oct 2010 12:08:16 -0500
> I'd just rip the whole thing out of the board code, and pass zero in
> isu_size to mpic_alloc(), if you can undo whatever is depending on the
> remapping.
OK, what I did was to change
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | M
On Wed, 13 Oct 2010 12:08:16 -0500
wrote:
> Do you have any suggestions on where to find out what parameters I should
> pass to mpic_assign_isu() to map the interrupts? It's another of those
> charmingly undocumented functions, even in the most recent git pull of the
> mainline kernel.
I'd just
Do you have any suggestions on where to find out what parameters I should
pass to mpic_assign_isu() to map the interrupts? It's another of those
charmingly undocumented functions, even in the most recent git pull of the
mainline kernel.
___
Linuxppc-de
On Wed, 13 Oct 2010 09:17:01 +0800
"tiejun.chen" wrote:
> Scott Wood wrote:
> > The crash is happening somewhere in mpic_set_irq_type():
>
> Agreed. That is just where I pointed out on my email replied for OOPS. To
> enable
> DBG to figure out 'src' and 'mpic->irq_count' from the file,
> arch/p
Scott Wood wrote:
> On Tue, 12 Oct 2010 15:55:28 -0500
> wrote:
>
>> I wonder about the next lines:
>>
>>
>> mpic_assign_isu(mpic1, 0, res.start + 0x1);
>>
>> /* 48 Internal Interrupts */
>> mpic_assign_isu(mpic1, 1, res.start + 0x10200);
>> mpic_assign_isu(mpic1, 2, res.s
On Mon, 2010-10-11 at 09:44 -0500, david.hag...@gmail.com wrote:
> > 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 Tue, 12 Oct 2010 15:55:28 -0500
wrote:
> I wonder about the next lines:
>
>
> mpic_assign_isu(mpic1, 0, res.start + 0x1);
>
> /* 48 Internal Interrupts */
> mpic_assign_isu(mpic1, 1, res.start + 0x10200);
> mpic_assign_isu(mpic1, 2, res.start + 0x10400);
>
> There's mpic stuff in the call trace, so the NULL host was OK.
>
> Look in arch/powerpc/platforms/86xx/pic.c. What is the second-to-last
> parameter of mpc86xx_init_irq() in your kernel tree? It's 256 in
> current upstream -- this is the number of IRQ sources the MPIC driver
> will handle.
>
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.
>
>
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 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
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
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
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:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0016540
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP N
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 256th specifier in the interrupts property
> On Thu, 7 Oct 2010 15:12:26 -0500.
>
> BTW, the MSIs are already described in an msi node in the device tree.
As far as I can tell, ONLY in root complex mode, not in endpoint mode,
which is what I am working with.
What I want is a means by which the system root complex can generate one
or more i
On Thu, 7 Oct 2010 15:12:26 -0500
wrote:
> > On Tue, 21 Sep 2010 17:37:15 -0400
> > The MPIC interrupt numberspace in the device tree (which is not
> > virtual; it is a private numberspace to MPIC) is based on the offset of
> > the registers for that interrupt source. External interrupts start at
> On Tue, 21 Sep 2010 17:37:15 -0400
> The MPIC interrupt numberspace in the device tree (which is not
> virtual; it is a private numberspace to MPIC) is based on the offset of
> the registers for that interrupt source. External interrupts start at
> zero (which is valid), internal at 16, and speci
, Trevor
> Cc: david.hag...@gmail.com; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Questions on interrupt vector assignment on MPC8641D
>
> On Tue, 21 Sep 2010 17:37:15 -0400
> "Anderson, Trevor" wrote:
>
> > IRQ assignments for MPC8641D are "virtual",
&g
On Tue, 21 Sep 2010 17:37:15 -0400
"Anderson, Trevor" wrote:
> IRQ assignments for MPC8641D are "virtual",
This is true for powerpc in general.
> meaning "made up" and quite difficult to determine by looking through code.
> But I believe the plan goes something like this:
>
> IRQ
>
IRQ assignments for MPC8641D are "virtual", meaning "made up" and quite
difficult to determine by looking through code.
But I believe the plan goes something like this:
IRQ
-
0 No interrupt
1 - 15External interrupts (only 1..12 would be used)
16 - 127 Inte
37 matches
Mail list logo
