Re: [ORLinux] [PATCH v2] openrisc: irq: use irqchip framework

[Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>]

On Thu, May 22, 2014 at 09:48:00AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 22, 2014 at 9:32 AM, Jonas Bonn <jonas@southpole.se> wrote:
> > On 05/21/2014 09:50 PM, Stefan Kristiansson wrote:
> >> I see two paths to go to get there though, and here's where I'd like some input.
> >> 1) Define the three different implementations as seperate irqchips,
> >>    with accompanying IRQCHIP_DECLARE.
> >> 2) Add custom device-tree bindings and determine the chip type from that.
> >
> > I think 1) above is the way to go.  Something alone the lines of
> > "opencores,or1k-pic-level", "opencores,or1k-pic-edge", and
> > "opencores,or1200-pic".
> 
> Sounds fine to me. The only thing I'm still wondering about is whether
> to have both "opencores,or1k-pic-*" variants, or just ""opencores,or1k-pic"
> and an (optional) property for edge/level selection.
> 
> Is edge support planned to stay in future versions of the specifications?
> If not, go with the optional property to select edge.
> If yes, have two variants.
> 

There have been no discussion about removing the edge triggered options.

Adding an optional property would afaict in practice be option 2),
as we would need to add a custom device-tree binding for it.
There are the pre-existing 'flags' in the 'interrupts' binding,
but it has slighty different semantics, since it is per interrupt-line and
not per interrupt controller.
Besides, using that property would mean that we would need to change
#interrupt-cells from 1 to 2, which would break pre-existing device-tree
descriptions.

> > The first two match the behaviour of the or1k specification; the third
> > one, however, is really a misimplementation of the spec and is kind of
> > tied to the actual implementation of the OR1200... I wonder if we don't
> > need to version this one like we version the CPU identifier (*-rtlsvnXXXXX).
> 
> Is this planned to be fixed for OR1200?
> If yes, how? If this will be done by switching to the version that follows the
> or1k spec, the compatible value in DT can just be changed to one of the
> "opencores,or1k-pic-*" variants.
> 

I agree, I think the or1200-pic identifier is enough to mark the "special" pic.
If the or1200 would be fixed, it certainly be according to the or1k spec.
But, apart from the or1200 itself, there are other implementations
(e.g. mor1kx) that can be configured to be "or1200 pic compatible",
to enable them to be suitable as drop-in replacements.

Stefan