Ugh. Clicked reply without being done writing the reply! On Thu, Jun 8, 2017 at 3:52 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > Edge vs level, active high vs active low. Typically some of these are > programmable, and are described as flags in the interrupt-specifier. > > See the examples in: > > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt Ok. Those are not really relevant to the PLIC. It has a flat interrupt namespace and the way you handle all four kinds of interrupts in the driver is uniform. I don't think we want to architecturally expose this to the operating system. > So do any CSRs affect the state of the PLIC? If it's just MMIO, the > mention of CSRs above is just a little confusing. HLIC = CSR only. PLIC = MMIO only. > It might be best to just say "The PLIC is connect to the HLIC embedded > in each RISC-V core". Fair enough. > It sounds like we'd need these to distinguish edge/level interrupts, > unless that's fixed at integration time and you can determine it from > the PLIC itself? They are fixed at integration time and the PLIC driver does not need to care. > It's not too much of a problem, but if we end up having to change > anything else from the proposed bindings, those trees are going to > require updates anyway. I'll talk to the other stakeholders. > Please update the binding to explicitly define the ordering requirement. The ordering requirement is that the first interrupts-extended entry corresponds to the first context, second to second, etc. If a context is unused for some reason, that's when you need a -1. The contexts are linear and contiguous in the MMIO address map. > Does this mean that you expect Linux logical CPU IDs to be equal to > physical CPU IDs in all cases? No. There is no 'physical CPU ID' anyway, except the mhartid CSR which is unavailable to linux. The SBI conveys your CPU ID by passing it as the first argument to the linux kernel. The interrupts-extended in the PLIC uses a phandle to reference the matching CPU in DTS. The num in cpu@<num> only need correspond to the first register argument to the kernel. If for some reason there end up too many -1 holes in the PLIC (b/c you virtualized a 128-core machine down to say 2), you can always virtualize the PLIC device and provide a matching simplified DTB.
