> 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!
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
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 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
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
> 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.
>
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.
> 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
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 Fri, 2010-10-08 at 17:22 +0800, tiejun.chen wrote:
>
> I think it should be allowed to use two LAWs to map different space for PCIe
> since I ever saw more one LAWs are created for different RAM space.
>
> Sorry for this delay response.
>
> -Tiejun
It's my bad, as I'd worked out the problem:
> 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 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
I'm trying to use an MPC8641D as a PCIe endpoint device, and I'm trying to
work out how the host root complex CPU can interrupt the PPC core. It's
not very clear how to do all of this, and I'd like some help fitting the
pieces together. If there's a good how-to online I've yet to find it.
As I rea
> Scott Wood wrote:
> I also meet machine check exception if configure LAW improperly for PCI.
> (i.e.
> unmatched PCIe controller id.)
>
> From you log looks 0xexxx should be your PCI space. So you can check
> if that
> fall into appropriate LAW configuration. Maybe you can post your boot log
I finally found my problems accessing the PPC OWBAR registers as an
endpoint (copy/paste brown paper bag bug on my part), but I still get a
bus fault trying to access the device.
The problem is that I don't know if the fault is internal to the PPC (e.g.
I don't have something in the chip set up) o
> Hi,
>
> I have a simple doubt about linux PCI/PCIe infraestructure.
>
> When I register a PCI driver using pci_register_driver() will the
> probe function be automatically called or will it just be called if PCI
> infraestructure match a Vendor and Device id on bus?
When you register your driver,
On Sat, 2010-09-25 at 17:46 +0800, tiejun.chen wrote:
> As a summary you have no any issue to access InBound/BAR/LAW.
Correct: full access to the inbound.
> And I remember there is only one
> requirement to OutBound, and that is the window address should be aligned
> based
> on the size from OWS.
On Fri, 2010-09-24 at 07:09 +0200, Chen, Tiejun wrote:
>
> Right but this should be done for RC mode, not for EP mode we're
> discussing.
>
> Tiejun
According to the Freescale documentation, outbound is just as valid for
endpoint as for root complex - indeed, to generate MSIs from software
REQU
>> -Original Message-
via the BARs.
>
> I read your email again and something hint me. I notice you clarify you
> already condigure InBound successfully.
I am programming BOTH the inbound ATMUs to make PPC memory available to
the root complex, AND programming outbound ATMUs to enable the
On Thu, 2010-09-23 at 05:21 +0200, Chen, Tiejun wrote:
> > I can get the device to show up on the host's PCI bus, I can
>
> This only ensure you can access the PCIe configure space.
Not quite: I can also read the BARs that I program, and the memory
behind them on the PPC.
>
> > program the inbou
I am trying to get the PCIe interfaces of a Freescale MPC8641D working in
endpoint mode (i.e. as a PCI device rather than a PCI root complex host).
I can get the device to show up on the host's PCI bus, I can program the
inbound ATMUs such that the BARS are updated when the host (re-)scans
them, b
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
Do you know (and if you know, can you comment) if IDT is planning on
offering RIO (and more importantly to me sRIO) chipsets that can be used
on other architectures besides the various PPC chips with embedded sRIO
controllers?
___
Linuxppc-dev mailing
25 matches
Mail list logo
