[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151030173240.GJ31073@leverpostej>
Date: Fri, 30 Oct 2015 17:32:40 +0000
From: Mark Rutland <mark.rutland@....com>
To: Brijesh Singh <brijeshkumar.singh@....com>
Cc: devicetree@...r.kernel.org, arnd@...db.de, pawel.moll@....com,
ijc+devicetree@...lion.org.uk, mchehab@....samsung.com,
galak@...eaurora.org, guohanjun@...wei.com,
linux-kernel@...r.kernel.org, andre.przywara@....com,
robh+dt@...nel.org, bp@...en8.de, dougthompson@...ssion.com,
sboyd@...eaurora.org, linux-arm-kernel@...ts.infradead.org,
linux-edac@...r.kernel.org
Subject: Re: [PATCH v4] EDAC: Add ARM64 EDAC
> > > * Interaction with firmware
> > > - When/do we handle interrupts?
> >
> > We can a properties in dt bindings:
> >
> > 1) "num-interrupts = 1" - number of interrupt count. One interrupts per cluster
> > e.g if you have 4 cluster then num-interrupts=4.
> > 2) interrupts = <0, 92, 0> <0, 94, 0> <0, 96, 0> <0, 98, 0> // interrupt mapping
> >
> > If num-interrupts = 0, then firmware handles interrupts. Optionally we can use HEST FIRMWARE-FIRST
> > bit, if bit is set then firmware is handling the interrupt otherwise use DT information.
>
> You won't have the HEST and DT information at the same time, given that
> at runtime the kernel uses one of ACPI or DT.
>From a quick look at the HEST definition, I don't doesn't seem like it's
possible to describe this feature -- there's no error source descriptor
for it and the generic hardware error source is not applicable.
So I'm worried that it may not be possible to use this feature with
ACPI.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists