Memory Controller driver never shared IRQ with any other driver and very
unlikely that it will. Hence there is no need to request IRQ sharing and
the corresponding flag can be dropped safely.
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/mc.c | 2 +-
1 file changed, 1 insertion(+), 1
27;t able to trace the code when desc->irq_data is getting set. The
flags values should be (as with old->flags):
IRQF_SHARED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
It could be a problem with a weird IRQ sharing in magician code, but
it's still failing the driver and the star
or "mismatch" error
>>>> the old variant of code works fine.
>>>>
>>>> The case for Magician machine is specific as the same interrupt line is
>>>> requested twice from the same driver (pda-power). But it still could
>>>> point to
or "mismatch" error
>>>> the old variant of code works fine.
>>>>
>>>> The case for Magician machine is specific as the same interrupt line is
>>>> requested twice from the same driver (pda-power). But it still could
>>>> point to
s should be (as with old->flags):
IRQF_SHARED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
It could be a problem with a weird IRQ sharing in magician code, but
it's still failing the driver and the start of the charging system.
IRQ definition in arch/arm/mach-pxa/magicia
uld
>> point to some hidden problem in the IRQ setup code.
>>
>> I wasn't able to trace the code when desc->irq_data is getting set. The
>> flags values should be (as with old->flags):
>>
>> IRQF_SHARED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
>>
>
ng set. The
> flags values should be (as with old->flags):
>
> IRQF_SHARED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
>
> It could be a problem with a weird IRQ sharing in magician code, but
> it's still failing the driver and the start of the charging
). But it still could
point to some hidden problem in the IRQ setup code.
I wasn't able to trace the code when desc->irq_data is getting set. The
flags values should be (as with old->flags):
IRQF_SHARED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
It could be a problem with a
On Wed, Jan 20, 2016 at 7:57 PM, William Breathitt Gray
wrote:
> The ACCES 104-IDI-48 can differentiate between its own and other
> devices' interrupt requests. Therefore, IRQ sharing is possible and
> should be permitted.
>
> Signed-off-by: William Breathitt Gray
Patch ap
The ACCES 104-IDI-48 can differentiate between its own and other
devices' interrupt requests. Therefore, IRQ sharing is possible and
should be permitted.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-idi-48.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
On Sat, 8 Dec 2007 18:44:39 -0500 (EST)
Justin Piszcz <[EMAIL PROTECTED]> wrote:
> Can some please explain with almost identical kernel .config's I see
> this on a p965 Intel board:
your bios programmed the machines differently...
the p965 has the higher performing settup, but still it's recomme
Can some please explain with almost identical kernel .config's I see this
on a p965 Intel board:
CPU0 CPU1 CPU2 CPU3
0: 2501669875 0 0 0 IO-APIC-edge timer
1: 8 0 0 0 IO-APIC-edge i8042
Hello,
currently, the parport_pc driver doesn't use IRQs automatically for
PCI devices. However, why is it not possible? It's no problem to find
out the corresponding IRQ, and it should also be possible to use IRQ
sharing. The following patch implements this.
Could somebody tell me wh
l IRQ to
be different for each device.
This way my real-time drivers already work great :)
So i need to change the APIC way of distribute virtual IRQs.
Jorge
>
>
> Remy
>
>
> 2007/2/6, Jorge Almeida <[EMAIL PROTECTED]>:
> >
> > Hello to all.
> >
> > I&#
> >
> > Hello to all.
> >
> > I'm running an application that uses several IO boards in a PCI bus.
> >
> > My main problem is the virtual IRQ sharing between several boards.
> > I mean for example:
> > 1 ethernet board IRQ = 169;
> >
realtime requirements, it usually should be
no problem...
Remy
2007/2/6, Jorge Almeida <[EMAIL PROTECTED]>:
Hello to all.
I'm running an application that uses several IO boards in a PCI bus.
My main problem is the virtual IRQ sharing between several boards.
I mean for example
Hello to all.
I'm running an application that uses several IO boards in a PCI bus.
My main problem is the virtual IRQ sharing between several boards.
I mean for example:
1 ethernet board IRQ = 169;
1 ADC card IRQ = 169;
I want to get ride of this behaviour, and cha
Alan Stern <[EMAIL PROTECTED]> writes:
> I can implement either a shutdown method or a reboot notifier for
> uhci-hcd. Note however that the upcoming changes to the PM core include a
> suspend call (PMSG_FREEZE) that does exactly what you want: quiesce the
> device, disable IRQ and DMA, but don't
On Monday 07 March 2005 2:08 pm, Eric W. Biederman wrote:
>
> The ongoing DMA transfers which are companions of the irq generating
> events are what really concern me, as we could get all kinds of
> interesting memory stomps. Do you think you could implement
> a reboot notifier or a shutdown() m
Alan Stern <[EMAIL PROTECTED]> writes:
> On 7 Mar 2005, Eric W. Biederman wrote:
>
> > Alan Stern <[EMAIL PROTECTED]> writes:
> >
> > > Shared IRQs will always be a problem. And the PCI subsystem doesn't
> > > implement shutdown() methods; that seems like a pretty big hole. I guess
> > > indi
int idecs_register (int arg1, int arg2, int irq)
+{
+hw_regs_t hw;
+ide_init_hwif_ports(&hw, (ide_ioreg_t) arg1, (ide_ioreg_t) arg2, NULL);
+hw.irq = irq;
+hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+return ide_register_hw(&hw, NULL);
On Fri, 01 Jun 2001, Matthias Andree wrote:
> Not sure if it's related to IRQ sharing or another initialization issue.
Looks like IRQ sharing is still in the play.
Yesterday, I purchased a pair of used 3C905TXs, replaced the RTL 8139 by
the 3C905, and got complaints by the 3C905 abo
[EMAIL PROTECTED] said:
> Do we have any [non-kernel] software that will read/analyze MPS
> tables?
I believe there's a port of http://people.freebsd.org/~fsmp/SMP/mptable/
somewhere. It's probably quicker to port it again yourself than search for
it.
--
dwmw2
-
To unsubscribe from this lis
> > I had a similar problem with the USB driver assigned to
> IRQ19 but not receiving any interrupts.
> >
> > Perhaps someone more knowledgable can explain why linux
> fails under MPS1.4.
>
> Linux is fine with MPS1.4. There are two possible causes I see
>
> 1.Some clown built a USB contr
> I had a similar problem with the USB driver assigned to IRQ19 but not receiving any
>interrupts.
>
> Perhaps someone more knowledgable can explain why linux fails under MPS1.4.
Linux is fine with MPS1.4. There are two possible causes I see
1. Some clown built a USB controller with only
Timur Tabi wrote:
> ** Reply to message from "Robert B. Easter" <[EMAIL PROTECTED]> on Thu,
> 12 Oct 2000 18:47:22 -0400
>
> > Since installing a
> > second CPU and recompiling the kernel for SMP and recompiling ALSA with
> > --with-smp=yes, the sound loops. I can hear the sound, but it doesn't
** Reply to message from "Robert B. Easter" <[EMAIL PROTECTED]> on Thu,
12 Oct 2000 18:47:22 -0400
> Since installing a
> second CPU and recompiling the kernel for SMP and recompiling ALSA with
> --with-smp=yes, the sound loops. I can hear the sound, but it doesn't
> continue to play normall
I'm using ALSA sound modules with a VIA 82C686A onboard audio chip on a MSI
694D-ProA motherboard. When I only had one cpu installed and the kernel and
ALSA were compiled for non-SMP, the sound worked fine. Since installing a
second CPU and recompiling the kernel for SMP and recompiling ALSA
28 matches
Mail list logo
