On Tue, Jul 24, 2018 at 09:55:53AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2018-07-23 at 14:16 +1000, David Gibson wrote: > > > > > > Now, this is an ICS subclass, so why shouldn't it directly poke at the > > > target ICP ? > > > > That's ok in theory, but causing it to expose the icp interface to a > > new module isn't great. > > > > > It's an alternate to the normal ICS since it behaves a bit > > > differently (PQ bits & all). > > > > AFAICT the PQ bits are effectively another filtering layer on top of > > the same ICS logic as elsewhere. I think it's better if we can share > > that shared logic, rather than replicating it. > > I don't know, is there much shared logic ? And the shared bits are the > subclassing, that's handled that way... > > This is really a different piece of HW, a separate ICS implementation, > that has its own quirks, is configured via different registers, does > EOI differently etc... > > Even the resend stuff is done differently, the resend bitmap is > actually SW visible via an IODA table. > > I mean, we could (maybe we do these days not sure) have an ICS > superclass wrapper on the actual icp_irq() but that's really all there > is to it I think.
Hm, yeah, fair enough. I realized what I was suggesting would
actually need another layer of qirqs than we have, so it's not a good
idea after all. Ok, I'm happy proceeding with exposing icp_irq().
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
