Hi, Thomas Gleixner <t...@linutronix.de> writes: > Felipe, > > On Wed, 30 Dec 2015, Felipe Balbi wrote: >> Thomas Gleixner <t...@linutronix.de> writes: >> > - Is there a "mapping" block between PRUSS and the host interrupt >> > controller >> > or is this "mapping" block part of PRUSS? >> >> The description in TRM is a bit "poor", but from what I can gather, the >> mapping is done on an interrupt controller inside the PRUSS. However, >> Linux is the one who's got the driver for that INTC (well, Linux will be >> the one with the soft ethernet/uart/whatever IP to talk to). All of its >> (INTC's) registers are memory mapped to the ARM side. > > Ok. And the INTC registers include the "mapping" configuration, right?
right. A bunch of 32 bit registers each with several 4 bit fields (one for each of the 64 events) where we write the physical IRQ number. >> > - We all know how well shared interrupts work. Is there a point of >> > supporting >> > 64 interrupts when you only have 10 irq lines available? >> >> I'm looking at these 64 events more like MSI kind of events. It's just > > Well, that's fine to look at them this way, but they will end up > shared no matter what. sure :-) >> that the events themselves can be routed to any of the 10 available HW >> IRQ lines. >> >> > - I assume that the PRUSS interrupt mapping is more or less a question of >> > the >> > firmware implementation. So you either have a fixed association in the >> > firmware which is reflected in the DT description of the IP block or you >> > need an interface to tell the PRUSS firmware which event it should map >> > to >> > which irq line. Is there actually a value in doing the latter? >> >> right, I'd say the mapping is pretty static. Unless Suman has some extra >> information which I don't. I guess the question was really to see if >> there was an easy way for doing this so we don't have to mess with DTS >> for every other FW and their neighbor. > > Well, you will need information about every other firmware simply because you > need to know which events the firmware is actually using and what the purpose > of the particular event is. > > Assume you have a simple uart with 3 events (RX, TX, status). So how will the > firmware tell you which event is which? You have a few options: > > 1) DT + fixed mapping scheme: > > Describe the PRUSS event number in DT and have a fixed mapping scheme like > the one you mentioned evt0 -> irq0 ..... > > 2) DT + DT mapping scheme > > Describe the PRUSS event number in DT and describe the mapping scheme in > DT as well > > 3) DT + dynamic mapping scheme > > Describe the PRUSS event number in DT and let your interrupt controller > associate the irq number dynamically. That's kind of similar to MSI with > the exception that it needs to support shared interrupts. > > 4) Fully dynamic association > > Have a query interface to the firmware which tells you which event it uses > for which particular purpose (RX, TX ...) and then establish a dynamic > mapping to one of the interrupts. > > Not sure which level of complexity you want :) I guess only 1, 2 are anything worth considering, most likely. 4 would just be too much headache :-p 3 might be doable too, though a bit more complex. Suman (who has been working on this for much longer than I have) might have some extra info to add, but he's on vacations for now. Hopefully, he'll add to this thread once he's back. cheers -- balbi
signature.asc
Description: PGP signature
