Re: [PATCH V3 2/4] of: Add binding document for MIPS GIC

[James Hogan <james.hogan@imgtec.com>]

Hi Andrew,

On Wed, Oct 29, 2014 at 10:25:27AM -0700, Andrew Bresticker wrote:
> On Wed, Oct 29, 2014 at 10:13 AM, James Hogan <james.hogan@imgtec.com> wrote:
> > On 29/10/14 16:55, Andrew Bresticker wrote:
> >> On Wed, Oct 29, 2014 at 2:21 AM, James Hogan <james.hogan@imgtec.com> wrote:
> >>> Please lets not do this unless it's actually necessary (which AFAICT it
> >>> really isn't).
> >>
> >> The point of this was to future-proof these bindings and I though that
> >> CPU type was the best way to indicate version in the compatible
> >> string.  This is also how it's done for the ARM GIC and arch timers.
> >> Perhaps the best thing to do is to require both a core-specific
> >> ("mti,interaptiv-gic") and generic ("mti,gic") compatible string and
> >> just match on the generic one for now until there's a need to use the
> >> core-specific one.  Thoughts?
> >
> > FPGA boards like Malta are something else to consider (when it is
> > eventually converted to DT - Paul on CC knows more than me). You might
> > load an interAptiv, or a proAptiv, or a P5600 bitstream, and the gic
> > setup will be pretty much the same I think, since e.g. the address
> > depends on where it is convenient to put it in the address space of the
> > platform.
> 
> Ah, I didn't realize that the CPU bitstream could be changed
> independently of the GIC.

To clarify, the GIC is still closely bound to the CPU and contained
within the FPGA bitstream. The register interface should I believe
always comply with some version of the GIC architecture specification,
and I don't think anybody wants per-bitstream DT files / kernels, so in
practice the way the GIC is set up for Malta (how interrupt lines are
connected up and where in address space GIC can go) is unlikely to
become incompatible.

Cheers
James