On Wed, 5 Mar 2014, Russell King - ARM Linux wrote:
> On Wed, Mar 05, 2014 at 03:42:34PM +0100, Thomas Gleixner wrote:
> > On Wed, 5 Mar 2014, Russell King - ARM Linux wrote:
> > > This results in the RTC alarm test receiving exactly one interrupt for
> > > each alarm expiry, as it should do. Thoughts?
> >
> > You are worried about clearing an interrupt which is transitory and
> > not kept active at the device level until you handled it for real,
> > right?
>
> Yep. Let's take the code:
>
> ldr r0, [r1] ; read the interrupt cause register
> and r0, r0, r2 ; clear interrupts we've serviced
> str r0, [r1] ; write it back
>
> The problem here is if a transitory interrupt is received between the
> load and store, the write can clear it back to zero. There's nothing
> which can be done to get around that - which is why I'd prefer to do
> this as infrequently as necessary.
Yes, that's the only sensible thing you can do. Is there any transient
interrupt connected to that irq controller or is this as vague as the
rest of the documentation?
> > Is the datasheet for this stuff public available?
>
> Thankfully, it is, but like many such things, it'll leave you with /lots/
> of questions. In the case of this register, the documentation only goes
> as far as describing the bits, but doesn't really describe their behaviour.
> Much of that can only come via experimentation with the hardware. :(
Sigh. I really want to understand why SoC companies waste lots of
resources to implement pointless and disfunctional variants of
interrupt controllers (or timers) over and over.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
