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.
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
On Wed, 5 Mar 2014, Russell King - ARM Linux wrote:
> In some ways, this is good news - it shows that the bits in this register
> latch '1' when an interrupt is pending, and remain '1' while the block
> continues to assert its interrupt signal - but can we say that the other
> interrupt functions
On Wed, Mar 5, 2014 at 1:41 AM, Russell King - ARM Linux
wrote:
> On Tue, Mar 04, 2014 at 05:32:40AM +, Jason Cooper wrote:
>
> Jason, Thomas,
>
> I've just been giving the above a whirl here with the RTC, and it
> doesn't seem to quite work as it should. Not your problem, because it's
> as
> >From the spec, it looks like this is probably true of DFSDone as well.
The cpufreq driver makes use of DFSDone. I've never had it loop
endlessly. There is also no action needed to clear it in the DFS
hardware.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe
From the spec, it looks like this is probably true of DFSDone as well.
The cpufreq driver makes use of DFSDone. I've never had it loop
endlessly. There is also no action needed to clear it in the DFS
hardware.
Andrew
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Mar 5, 2014 at 1:41 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Mar 04, 2014 at 05:32:40AM +, Jason Cooper wrote:
Jason, Thomas,
I've just been giving the above a whirl here with the RTC, and it
doesn't seem to quite work as it should. Not your problem,
On Wed, 5 Mar 2014, Russell King - ARM Linux wrote:
In some ways, this is good news - it shows that the bits in this register
latch '1' when an interrupt is pending, and remain '1' while the block
continues to assert its interrupt signal - but can we say that the other
interrupt functions in
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
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?
On Tue, Mar 04, 2014 at 05:32:40AM +, Jason Cooper wrote:
> -static void dove_pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
> -{
> - struct irq_domain *d = irq_get_handler_data(irq);
> - struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
> - u32 stat =
On Tue, Mar 04, 2014 at 05:32:40AM +, Jason Cooper wrote:
-static void dove_pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- struct irq_domain *d = irq_get_handler_data(irq);
- struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
- u32 stat =
This reverts commit 40b367d95fb3d60fc1edb9ba8f6ef52272e48936.
Russell King has raised the idea of creating a proper PMU driver for
this SoC that would incorporate the functionality currently in this
driver. It would also cover the use case for the graphics subsystem on
this SoC.
To prevent
This reverts commit 40b367d95fb3d60fc1edb9ba8f6ef52272e48936.
Russell King has raised the idea of creating a proper PMU driver for
this SoC that would incorporate the functionality currently in this
driver. It would also cover the use case for the graphics subsystem on
this SoC.
To prevent
14 matches
Mail list logo
