an 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 remove mi
an 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 remove mi
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
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
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
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, see
https
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 through platform data
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 configuration in
the designware
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
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
> 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
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 is not stable with my chipset.
I ho
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 is not stable with my chipse
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: END_OF_CODE+37649e23/???
Trace: c01127ae timer_bh+2be/404
- 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
;
> 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 triggering.
That said,
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
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,
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,
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 driver's
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 triggering.
That said, if you have a device that shares interrupts, the driver
does not know and does
- 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, Mahadev K Cholachagudda wrote:
Hell
24 matches
Mail list logo
