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
>
> david.hag...@gmail.com
> Sent: Tuesday, September 21, 2010 7:12 AM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: Questions on interrupt vector assignment on MPC8641D
>
> I'm new to developing on the PPC (most of my experience is on x86), and I
> have a couple of questions abo
I'm new to developing on the PPC (most of my experience is on x86), and I
have a couple of questions about mapping of interrupts on the PPC,
specifically on the Freescale 8641D embedded CPU.
1) How does one allocate interrupt vectors for the embedded devices, such
as the MPIC? All the kernel how-t
38 matches
Mail list logo
