s such we can set cp0_perfcount_irq = cp0_compare_irq for pre-r2
systems and remove the perf_irq fallback in favor of always relying on
more standard interrupt sharing using IRQF_SHARED & multiple handlers.
A natural cleanup that ties in with no longer using perf_irq is that we
can re
On Fri, Feb 15, 2013 at 02:05:10PM +0100, Christian Ruppert wrote:
> On Fri, Feb 15, 2013 at 01:50:37PM +0200, Mika Westerberg wrote:
> > On Fri, Feb 15, 2013 at 11:11:50AM +0100, Christian Ruppert wrote:
> > > This patch implements interrupt sharing and SDA hold time configur
On Fri, Feb 15, 2013 at 01:50:37PM +0200, Mika Westerberg wrote:
> On Fri, Feb 15, 2013 at 11:11:50AM +0100, Christian Ruppert wrote:
> > This patch implements interrupt sharing and SDA hold time configuration in
> > the designware i2c driver. Both functions are enabled throug
On Fri, Feb 15, 2013 at 11:11:50AM +0100, Christian Ruppert wrote:
> This patch implements interrupt sharing and SDA hold time configuration in
> the designware i2c driver. Both functions are enabled through platform data
> or device tree. Tested with Linux-3.8rc4 (Synopsys ARC port, se
This patch implements interrupt sharing and SDA hold time configuration in
the designware i2c driver. Both functions are enabled through platform data
or device tree. Tested with Linux-3.8rc4 (Synopsys ARC port, see
https://github.com/foss-for-synopsys-dwc-arc-processors/linux/commits/arc-3.8
The interrupt status register for the natsemi chips is clear on read and
was read unconditionally from both the interrupt and from the NAPI poll
routine, meaning that if the interrupt service routine was called (for
example, due to a shared interrupt) while a NAPI poll was scheduled
interrupts cou
> Looking at the trace, I can see the cpu wasn't actually doing
> anything when it crashed. Well, an interrupt occured, and that
> apparently is fatal on my machine. Now I wonder why.
It's easy to explain the crash:
> >>EIP: Trace: c01127ae
Someone called add_timer with either an
u might
not use my bug report because of that, but I don't think RedHat would
change the interrupt handling of the kernel. They would rather add
features (such as USB support and AGP driver support). Anyway, I have
tried a standard kernel (2.2.16) with no success. Apparently interrupt
sharing i
checks to see if the _device_ it serves have
data, and handles that if necessary. Then the next handler for that
interrupt is called, and it will check its device and so on.
Note that you will never ever register two handlers for the same
interrupt from the _same_ device. That makes no sense. Int
- Original Message -
From: "Jeff Garzik" <[EMAIL PROTECTED]>
To: "Mahadev K Cholachagudda" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 25, 2000 7:00 PM
Subject: Re: Interrupt sharing
>
>
> On Mon, 25 Sep 2000, Ma
ISR.
>
> please help,
>
> any help is welcome,
>
> with regards,
> Mahadev
Interrupt sharing works only with level interrupts. Your choice of
a UART for an example is unfortunate because the IRQs that they use
(IRQ3 and IRQ4) are not normally configured for level triggeri
On Mon, 25 Sep 2000, Mahadev K Cholachagudda wrote:
> Hello to all,
>
> I have one doubt and is as below.
>
>
> Suppose say the two drivers driver1 and driver2 will install the ISR for a
> particular interrupt, say UART0.
> After some time the interrupt is generated. At this moment, which dr
Hello to all,
I have one doubt and is as below.
Suppose say the two drivers driver1 and driver2 will install the ISR for a
particular interrupt, say UART0.
After some time the interrupt is generated. At this moment, which driver's
ISR is going to execute ?.
If driver1 ISR is get executed, will
13 matches
Mail list logo
