Re: Questions on interrupt vector assignment on MPC8641D
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 boot: mpic: Setting up MPIC MPIC version 1.2 at e004, max 2 CPUs mpic: ISU size: 88, shift: 7, mask: 7f mpic: Initializing for 88 sources Now, since the interrupt number I want is 224, which, last time I checked, was 88, this may be the root cause. 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, MPIC_INFO(GREG_FEATURE_0)); mpic-num_cpus = ((greg_feature MPIC_GREG_FEATURE_LAST_CPU_MASK) MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1; if (isu_size == 0) mpic-num_sources = ((greg_feature MPIC_GREG_FEATURE_LAST_SRC_MASK) MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1; So it would seem to me that the greg_feature is saying I have 88 interrupts. I've tried setting the ISU size to 256: mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN , 256, 256, MPIC ); And that kills the kernel as we init the mpic. SO, I guess the question in, what sets greg_feature, as it would seem to be incorrect. Or, am I on the wrong trail? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 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 talk with your cow-orkers there, Scott, since this is a Freescale part. It's not very clear to me what distinction the MPIC code is trying to make between irq_count and num_sources in the first place, though. /me looks at Scott's email again. If you, working FOR Freescale, and following the Linux development (presumably for some time) are confused, imagine what I've been going through! Hot damn, and time for a quick version control commit, a hot lunch, and really testing the code. Thanks again! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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! (well, it segfaulted, but's my fault for not actually initializing my work queue structure. But I can get the interrupt into the part!) So thanks to all. I hope to get my code working, get past my delivery deadline on it, clean it up so it matches The One True Way Of Laying Out Kernel Code, and post it here for everybody to point and laugh at. Maybe around Christmas. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN, 16, 256, MPIC ); to mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN, 0, 256, MPIC ); and remove all the calls to mpic_assign_isu. When I did this, the board booted, but when I then tried to map my interrupt, I got a segfault: unsigned mpic_vector = mpic_reg_to_irq(MSIVPR0); printk(KERN_INFO Endpoint %s: got MPIC IRQ %d\n,name,mpic_vector); dis-irq = irq_create_mapping(0,mpic_vector); Led to: Using EP8641A machine description Total memory = 1024MB; using 2048kB for hash table (at cfa0) snip mpic: Setting up MPIC MPIC version 1.2 at e004, max 2 CPUs mpic: ISU size: 88, shift: 7, mask: 7f mpic: Initializing for 88 sources snip RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 164k init mpic_enable_irq timeout PCI endpoint driver. Ver. 0.01 Copyright (C) 2010, Aeroflex, Inc compiled Oct 12 2010 15:26:57 Endpoint: PORBMSR 8F31, PORDEVSR 0AA58740 Endpoint: PORPLLSR 002A Endpoint: PORDEVSR 0AA58740 Endpoint: PORDBGMSR 0E00 Endpoint: PORIMPCR 007F Endpoint: PORCIR 2CFF SerDes1 PEX, SerDes2 sRIO 3.125Gbps EP: from to 1FFF is DDR1 EP: from F000 to is LBC EP: from C000 to DFFF is sRIO EP: from A000 to BFFF is PEX1 EP: from E200 to E2FF is PEX1 EP: from 2000 to 3FFF is DDR2 Endpoint PEX1 eedb1800: PEX_CONFIG 0028 Endpoint PEX1: alloc LAW space A000 - AFFF Endpoint PEX1: got MPIC IRQ 224 Unable to handle kernel paging request for data at address 0x0c00 Faulting instruction address: 0xc0016540 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT SMP NR_CPUS=2 EP8641A Modules linked in: Endpoint_driver(+) NIP: c0016540 LR: c0050b38 CTR: c00163b8 REGS: eed41ab0 TRAP: 0300 Not tainted (2.6.26.2-ep1.10) MSR: 1032 ME,IR,DR CR: 24024482 XER: DAR: 0c00, DSISR: 4000 TASK = eed82050[59] 'insmod' THREAD: eed4 CPU: 0 GPR00: 0c00 eed41b60 eed82050 ffea c035c17c 00e0 GPR08: 0040 c035c020 0c00 24024422 100a7264 0095 GPR16: 0095 000d 0124 f102fdb8 c004a4fc f102c000 GPR24: 001a f1038428 c031e610 fffa 9032 c031e5e0 00e0 NIP [c0016540] mpic_set_irq_type+0x188/0x1c4 LR [c0050b38] set_irq_type+0x84/0xc8 Call Trace: [eed41b60] [c0050b1c] set_irq_type+0x68/0xc8 (unreliable) [eed41b80] [c001572c] mpic_host_map+0xec/0xf4 [eed41b90] [c00064a0] irq_setup_virq+0x60/0x98 [eed41bb0] [c00065dc] irq_create_mapping+0x104/0x114 [eed41bd0] [f1034798] Endpoint_device_ctor+0x258/0x3b4 [Endpoint_driver] [eed41c10] [f1034d3c] Endpoint_device_find+0x448/0x63c [Endpoint_driver] [eed41e40] [f103a028] Endpoint_init_module+0x28/0x60 [Endpoint_driver] [eed41e60] [c004bcb4] sys_init_module+0xd4/0x1c1c [eed41f40] [c0011278] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff787ec LR = 0x10010e2c Instruction dump: 90080018 41bdff34 4bd4 7c0938ae 2f80 540b073e 5400073a 40befef8 4bfffeec 7d26482e 7c095a14 7c0004ac 7d29582e 0c09 4c00012c 5520028e ---[ end trace a3d033ca1998c9f0 ]--- note: insmod[59] exited with preempt_count 1 Otherwise, I'm guessing from the lines that you posted that you want to add: mpic_assign_isu(mpic1, 14, res.start + 0x11c00); Actually, I tried this first. So I guess the second parameter is interrupt vector #16, and the third is the address base of the registers to generate that interrupt. When I did this, the kernel wouldn't even boot - it seg'ed on that line. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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.
One, thanks for your help - I do appreciate it.
In the tree I am working from, the call to mpc86xx_init_irq() function is
in a BSP file (ep8641a.c), and the line was
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
16, NR_IRQS-4,
MPIC );
I tried changing that to
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
16, 256,
MPIC );
With no meaningful changes.
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);
mpic_assign_isu(mpic1, 3, res.start + 0x10600);
/* 16 External interrupts
* Moving them from [0 - 15] to [64 - 79]
*/
mpic_assign_isu(mpic1, 4, res.start + 0x1);
Looking at the code, and where it appears to be faulting, it looks like
its in kernel/irq/chip.c:
int set_irq_type(unsigned int irq, unsigned int type)
{
struct irq_desc *desc;
unsigned long flags;
int ret = -ENXIO;
if (irq = NR_IRQS) {
printk(KERN_ERR Trying to set irq type for IRQ%d\n, irq);
return -ENODEV;
}
desc = irq_desc + irq;
if (desc-chip-set_type) {
spin_lock_irqsave(desc-lock, flags);
ret = desc-chip-set_type(irq, type);
spin_unlock_irqrestore(desc-lock, flags);
}
return ret;
}
My conjecture is that desc-chip isn't set. Is mpic_assign_isu the
function that does that?
(yes, I know - update your kernel. I am 2 weeks from a delivery, I have to
merge driver changes to sRIO in along with all of this)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 run time, as far as I can see, you are right back to the question of and how do I know what the mappings are so I can create the node? You haven't answered the question, you've just moved where you are asking it. I think you can check fsl_msi.c to figure out what you want. snip Often most latest classic books/articles always use x86 code as an example to clarify Linux. So you have to understand something on PPC via codes. But I think you will benefit more information from the codes than documents :) RTFS. That wouldn't be bad advice, if the source were actually commented. None of these APIS have any meaningful comments in them, around them, or anywhere near them. You'd think we were back in the old BASIC days, when comments occupied run-time memory. Code can tell me WHAT is being done, but not WHY, and not what assumptions are being made. So when you say You should define MSI device nodes on your target dts. we go right back to my comment of You haven't answered the question, you've just moved where you are asking it. Firstly you should use irq_of_parse_and_map()/irq_create_mapping() to map the real hardware irq to virtual irq. Then use request_irq() with the virtual irq to hook your interrupt handler. And when I do that, I get a segfault as my follow-on mail reports. 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. I will look at that file. Looks you want to your host root complex to trigger MSI to mpc8641 EP target? If so I'm a bit confused since MSIs should be delivered to to the Root Complex resided on your host. I want the host to be able to interrupt the PPC. Since this is PCIe, the only way that will be working is for the root complex to do a write to somewhere on the PPC. This is basically the same mechanism as MSI, only with the PPC as the target of the write rather than the root complex. Obviously, the rest of the PCI devices will be sending interrupts to the root complex, some via MSI. That has nothing to do with this discussion. Since the PPC is in endpoint mode, the MSI hardware on the PPC won't be used. The hardware is writable from the root complex via the PPC BAR0, so I see no reason not to reuse it to trigger interrupts on the PPC from the Root complex. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 have been unclear, let me state this as clearly as possible. I AM DOING ENDPOINT MODE. I think you can check fsl_msi.c to figure out what you want. Except that file doesn't exist in the 2.6.26 kernel with which I am working. Firstly you should use irq_of_parse_and_map()/irq_create_mapping() to map the real hardware irq to virtual irq. Then use request_irq() with the virtual irq to hook your interrupt handler. Except I have no device to pass irq_of_parse_and_map, and when I call irq_create_mapping it seg faults. Maybe you can check the file, ppc4xx_pci.c since ppc4xx also can support EP as I previously said. It only supports EP mode in the sense that it sets the hardware up to export a BAR, and does nothing else. It doesn't provide any means for any other code to actually DO anything in that mode. It doesn't define a way to be interrupted by the root complex, nor to do anything when that interrupt happens. It doesn't supply any meaningful framework to get any data from the Root Complex. That's the whole reason I am trying to make a piece of code that actually WILL make those things available in a useful fashion. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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.txt Not present in the version I have. Plus the chip manual, for the register offsets. I have that now, so at least one part of the fog is a bit less dense. If it's not in the dts, add it. If for whatever reason that's not an option, you can use irq_create_mapping() as I mentioned in the previous e-mail. And as I've said previously, I have no good info on HOW to add the nodes, WHAT to add, or WHERE. You may as well be saying Bargle the Narbog. And when I try to use irq_create_mapping() it seg faults, which doesn't exactly help me get my interrupt hooked up. (crotchety old man mode)Kids these day - when I was a kid, you just grabbed the IRQ vector into your assembly code and away you went. Now GET OFF MY YARD!(/crotchety old man mode). If you grep arch/powerpc/boot/dts for msi in a reasonably recent kernel you should find msi nodes. ddhag...@wic-102362:..Workspace/Linux_Kernel_for_PPC grep msi arch/powerpc/boot/dts -ir arch/powerpc/boot/dts/glacier.dts: enable-msi-hole; arch/powerpc/boot/dts/taishan.dts: enable-msi-hole; arch/powerpc/boot/dts/canyonlands.dts: enable-msi-hole; arch/powerpc/boot/dts/katmai.dts: enable-msi-hole; What did I get signed up for? :-) It sounds like Tiejun thinks you might be working on, well, basically what I am working on - a generic interface to allow user space to support being a endpoint, with the ability to generate interrupts to the host root complex, get interrupts from the host root complex, provide memory to be accessed by the host root complex via the PPC's BARs, and to access the host root complex's PCI address space via the OATMU windows. Something to allow a person to use a PPC SOC as an endpoint, and to get on with the job of providing functionality rather than having to deal with esoterica. I'm hoping to make an interface generic enough to support not only the PPC, but other devices as well (things I cannot go into due to NDAs at this time). As a systems programmer, I am tired of re-inventing the wheel when dealing with being an endpoint - I want to invent the wheel, and push it uphill to the greater Linux community so that a) others are spared the pain I am suffering, and b) maybe other SOC vendors will implement my interface (and thus I won't have to). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 in the mpic node -- not what you want. That was from some of the previous emails in this thread. Ideally you would have a node for your device with an interrupt specifier that you could look up with irq_of_parse_and_map(). OK, and how do these devices come into being? From what I can tell, they are defined by uBoot, and if uBoot doesn't define it, then you are out of luck. But even assuming you can define these nodes at run time, as far as I can see, you are right back to the question of and how do I know what the mappings are so I can create the node? You haven't answered the question, you've just moved where you are asking it. The vector/priority register (MSIVPR0) is at offset 0x51c00. Each interrupt source is 32 bytes. The first interrupt source is at 0x5. So the interrupt number is (0x51c00 - 0x5) / 32 = 224. OK, so that's how you get the MPIC IRQ number. It's a pity that the key piece of information - MPIC IRQ Numbers are defined by the interrupt vector table starting at 0x5 and incrementing by 0x20 - see table 9.3 of the MPD8641D manual for details wasn't spelled out anywhere I could find. Given the data I had: the kernel sources, the MPD8641D manual, and not much else, I had three unknowns: * a table of config registers, that could map an set of events into an arbitrary vector number. * The standard kernel request_irq API that takes that arbitrary vector number * A set of APIs (irq_of_parse_and_map(), irq_create_mapping) that were, for all intents, undocumented (just here's the parameters, no description of when and how to use them), that took a and returned a (because, with the documentation I had, that's basically all I could say about them). There was no documentation that said how to compute the MPIC interrupt vector, no documentation that said which API to use to convert that to an kernel IRQ, nothing. BTW, the MSIs are already described in an msi node in the device tree. As I stated previously - not that I can see. Neither does /proc/device_tree contain such a listing, nor does doing a of_find_node_by_name(0,msi); nor of_find_node_by_type(0,msi); find them. It may be they are defined in PCI Root Complex mode, but again - I am writing code to handle Endpoint mode, which, as far as I can tell from the kernel sources, is NOT handled in any standardized way. Again, it would be nice were this sort of thing documented somewhere. If it is, I'd love a link - I've tried every combination of search terms I can think of to find it to no avail. If it isn't documented, might I suggest that either a) creating a dedicated Programming PPC Embedded devices and their components under Linux be created, or b) an appropriate chapter or chapters be drafted and submitted to the Linux Device Drivers book. Don't take this message the wrong way - I do want to say THANK YOU FOR THE HELP! - I am just trying to point out why somebody with a fair amount of Linux kernel experience and a great deal of general embedded experience is having great trouble doing a simple thing. I'll try creating a mapping, binding to it, and seeing what happens. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 NR_CPUS=2 EP8641A Modules linked in: Endpoint_driver(+) NIP: c0016540 LR: c0050b38 CTR: c00163b8 REGS: ef8c1ab0 TRAP: 0300 Not tainted (2.6.26.2-ep1.10) MSR: 1032 ME,IR,DR CR: 24024482 XER: DAR: , DSISR: 4000 TASK = eedec6a0[60] 'insmod' THREAD: ef8c CPU: 1 GPR00: ef8c1b60 eedec6a0 ffea c035c17c 00e0 GPR08: 0040 c035c020 24024422 100a7264 0095 GPR16: 0095 000d 0124 f102fd98 c004a4fc f102c000 GPR24: 001a f1038400 c031e610 fffa 9032 c031e5e0 00e0 NIP [c0016540] mpic_set_irq_type+0x188/0x1c4 LR [c0050b38] set_irq_type+0x84/0xc8 Call Trace: [ef8c1b60] [c0050b1c] set_irq_type+0x68/0xc8 (unreliable) [ef8c1b80] [c001572c] mpic_host_map+0xec/0xf4 [ef8c1b90] [c00064a0] irq_setup_virq+0x60/0x98 [ef8c1bb0] [c00065dc] irq_create_mapping+0x104/0x114 [ef8c1bd0] [f1034798] Endpoint_device_ctor+0x258/0x3b8 [Endpoint_driver] Reading the source (since these calls don't seem to have any other documentation), it *looks* like it ought to be valid to call irq_create_mapping with a null irq_host *host - which is good, since I can't see anything obvious that would give me some other irq_host (again, since none of this seems to be documented anywhere). I am assuming the default host used by the system would be correct. However, then I get this fault. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 special things like MSIs at higher numbers (I don't think it's quite 256). OK, so I'm slowly wrapping my head around this (OT: Has anybody considered sending this information to the folks doing the Linux Device Drivers books? They are just a bit x86 centric right now...). As I understand, what I have to do is somehow get a device_node *, then make a call to irq_of_parse_and_map() to convert that into a system IRQ. What I am doing right now is: device_node *mpic = of_find_node_by_type(0,open-pic); irq = irq_of_parse_and_map(mpic,256); While I get a pointer from of_find_node_by_type, when I try to map IRQ #256 via the irq_of_parse_and_map function, I get a zero back from it. So I guess my questions would be: 1) should I be frobbing the PIC for this, or should I be looking up some other device? 2) How do I know for certain that 256 is the right value for the first MSI signaled via MSIR0? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
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 interrupts INTO the 8641 when it is operating in endpoint mode. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC8641D PCI Endpoint incoming interrupts?
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 read it, on the host side, I'd do one of: 1) a write to the PPC's BAR0, offset 0x41400 (MSGR0) with some message value 2) a write to BAR0 offset 0x41600 (MSIR0) and set a bit within it. 3) a write to 0x41740 (MSIIR) to set a bit in MSIR0 So question #1 is which of those should I use? (or should I use something else?) Then, as I read it, I'd have to somehow convert the interrupt vector the PIC uses into a virtual interrupt number suitable for request_irq. I've seen mentions of irq_of_parse_and_map(), but I've not found a good description of how to use it. Does anybody have any (non-null) pointers on this? Once I get to request_irq I'm on familiar ground. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Doubt about Linux PCIe infraestructure
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, you supply a list of VID/DID pairs for
which your driver is applicable, and if those devices are on the bus, your
probe will be called.
I am loading a PCI driver that register itself using
pci_register_driver() but the probe function isn't called.
If you didn't indicate your driver was for the VID/DID of the device, your
probe won't be called - why should it? As far as you told the kernel,
there's no hardware pertaining to your driver.
The old days of every driver probes every device are gone.
Here's an example code fragment:
/* define the list of devices we support */
static struct pci_device_id ppc_ep_device_ids[] =
{
{PCI_DEVICE(PCI_VENDOR_ID_FREESCALE,PCI_DEVICE_ID_MPC8641D)},
{0} /* end of list indicator */
};
MODULE_DEVICE_TABLE(pci, ppc_ep_device_ids); /* tell udev to load our
module for these devices */
pci_register_driver(ppc_ep_device_driver); /* tell the kernel we handle
these devices */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Parsing a bus fault message?
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) or if the fault is happening on the PCIe side of things. Are there any good how-tos on interpreting the kernel machine check error for the PPC, that might help me know where to look for the problem? Alternatively, can somebody see a hint in the message that I don't know enough to pick out? At this point, my code is trying to memcpy() from the PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is either a) the ATMU is not accessible b) the ATMU is accessible but not mapped (which I would have thought the ioremap call I made would have handled) or c) the chip is not able to bus master on the PCI bus. Machine check in kernel mode. Caused by (from SRR1=149030): Transfer error ack signal Oops: Machine check, sig: 7 [#1] SMP NR_CPUS=2 EP8641A Modules linked in: Endpoint_driver rionetlink NIP: c0014e80 LR: f102d434 CTR: 0200 REGS: ef05fdf0 TRAP: 0200 Not tainted (2.6.26.2-ep1.10) MSR: 00149030 EE,ME,IR,DR CR: 24004482 XER: TASK = ef05b310[76] 'cat' THREAD: ef05e000 CPU: 0 GPR00: ef05fea0 ef05b310 eed06000 f14dfffc 1000 eed05ffc 8000 GPR08: 1000 c0014e60 1000 100a7264 0100 0001 GPR16: 004005b4 007fff00 c029 c02f ef05ff20 bfba5978 eed06000 GPR24: eed14ce0 ef02c678 eed61910 efb8d4b0 fffb 1000 NIP [c0014e80] memcpy+0x20/0x9c LR [f102d434] Endpoint_atmu_read+0x4c/0x90 [Endpoint_driver] Call Trace: [ef05fea0] [ef05609c] 0xef05609c (unreliable) [ef05feb0] [c00cf2c0] read+0xd8/0x1c8 [ef05fef0] [c007ff40] vfs_read+0xcc/0x16c [ef05ff10] [c008074c] sys_read+0x4c/0x90 [ef05ff40] [c0011174] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff697f0 LR = 0x10007008 Instruction dump: 4200fff0 4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028 70c3 7ce903a6 40820054 80e40004 85040008 90e60004 95060008 4200fff0 ---[ end trace e0620da52f69882d ]--- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC8641D PEX: programming OWBAR in Endpoint mode?
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. Are you sure? Yes. As my first test I've been using 4k and 64k sizes, aligned on 16M boundaries. And did you try to configure OutBound REGS when RC mode? If so I'm afraid we may miss some errata on EP. In RC mode the built-in drivers take over. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
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 REQUIRES programming an outbound ATMU to access the host's APIC. Moreover, ANY PCI endpoint SHOULD be able to do bus master access, and that is done by the outbound ATMUs. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
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 inbound ATMUs such that the BARS are updated when the host (re-)scans them, but I cannot for the life of me get What value are configured to IntBound REGs? I can program them at run time via sysfs on the PPC's side, so there is no single set of values. However, I am pointing them at the PPC's RAM space, and as I stated above, I can read the PPC's RAM from the host side via the BARs. How do you configure OWS of PEXOWAR? I means you still access that if OWS is match the whole target memory size even when '0' is as the internal platform address. As I understand it, not if the OWS is not correctly mapped on the PPC side - the PEX outbound ATMU's OWBAR must be mapped to a region of the PPCs address space that is also mapped to PEX in the LAW. The LAW does NOT indicate that PPC address 0 is mapped to the PEX. Out_be32 should be fine for atmu REGs. And also you can refe to the function, setup_pci_atmu setup_one_atmu, on the file, arch/powerpc/sysdev/fsl_pci.c, to know how to access atmu REGs. Often you should disable them, configure then enable/invoke atmu antry as normal configuring sequent. I have tried disabling the outbound ATMU when I program it, with no change. I have looked at the functions you mention, and that is a part of my confusion, as they aren't doing anything different than I am. Additionally I'm a bit afraid your initial phase :) As you know PCIe would be used as RC mode on Freescale PowerPC kernel. So I don't know if you also drop this path on your kernel to conflict each other :) I have tried doing this under a kernel built without PCI support with no change. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
-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 PPC to bus master to the root complex's memory space on PCIe. I am NOT attempting to program the IWBARs - as you noted, they get programmed by the root complex via PCI config operations. And as my above comment I'm afraid you mix up InBound and OutBound on EP mode? No, I am NOT confusing the two - that is why I am being VERY EXPLICIT about accessing the OUTBOUND ATMUs. The only reason I mention the inbound ATMUs is to demonstrate that the physical layer is working. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC8641D PEX: programming OWBAR in Endpoint mode?
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, but I cannot for the life of me get the PPC's Outbound ATMUS to work. When I attempt to program them, I can program ALL the registers EXCEPT the OWBAR - which steadfastly remains 0 no matter what I write to it. As a result, when I attempt to bus master out from the PPC to the PCIe address spaces via the outbound ATMUs, I get a bus fault on the PPC as there is no device at the address I am accessing. I've double-checked the LAWs to make sure the PEX is mapped into local space, I've put the OWBAR in that address space, I've tried different outbound ATMUs, and NOTHING works. Not ATMU0, not ATMU1, etc. I've been trying to work with our Freescale rep, but I am getting nowhere on that front. Does anybody have any suggestions on what I might be doing wrong? I mean, it looks like it should be a simple out_be32(addr_of_OWBAR,value), just like all the other accesses to the ATMU registers that seem to be working (as in, I read back what I wrote). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 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-tos are really targeting the x86 and PCI, so I've been unable to find a good document on that which is not an X86. 2) Are there any good guides to programming the PPC generally, and the MPC8641 specifically, that I can go read to answer my other questions? I'm trying to write a driver to map the 8641D's PCIe controllers *as endpoints* into something frobablbe from user space - to allow setting the BARs and outbound address translation units via sysfs files, and to allow mapping of inbound interrupts to sysfs doorbell-style files. If I can get it worked out I want to submit it back to the kernel for general distribution. If anybody has any insights, I'd greatly appreciate it if you'd copy my work email (david.hagood at aeroflex.com) as well (I am using my personal email as work insisted upon adding a one paragraph wart to all outbound email that isn't acceptable for a list like this.) Also, if anybody out there has experience with the 8641D PEX's in endpoint mode and wouldn't mind answering a couple of questions about programming the OWBARs, I'd be greatly obliged. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RapidIO - general questions
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 list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
