Hello Jorge,

AFAIK, if the lines are really hardwired, you can never seperate them,
as there is no way to detect which device generated the interrupt,
other than executing the interrupt handler of both devices. Only the
driver can tell by checking the interrupt status registers of the
device.
A piece of hardware that has no knowledge about the devices, can not
distinguish the source, you have to look in the device registers to
check if that device has generated the interrupt.

But, Interrupt lines that are NOT hardwired to each other, can still
be mapped (e.g. by BIOS) to the same virtual interrupt lines. In that
case they can be seperated by configuring the hardware. But, if you
already use the LAPIC and IOAPIC, my experience is that the lines are
already seperated as much as possible, but you have to verify that.

I had similar problems in the past, and as I am using the RT-kernel, I
have threaded interrupts. I implemented a real-interrupt tophalf
(IRQF_NODELAY flag) that is capable of detecting the source of the
interrupt, and wakes the corresponding high-priority kernel thread
that handles the interrupt. All within a few microseconds latency.

When it comes to sharing with other devices I have made the choice to
close down 1 USB controller that shared the interrupt with my
IO-board. USB still works in my case, but 1 onboard
controller/connector is dead)

Kind Regards,

Remy


2007/2/6, Jorge Almeida <j-almeida@criticalsoftware.com>:
quoted text
> Em Tuesday, 6 de February de 2007 18:43, o Remy Bohmer escreveu:
> > Hello Jorge,
> Hello Remy,
> >
> > It is not uncommon that interrupt lines are hardwired to each other on
> > a standard PC-board.
> > Therefor it is not always feasible to get rid of interrupt sharing.
> > Especially on-board USB adapters can easily use up to 5 interrupt
> > lines on a standard main-board. Also, sharing of interrupt lines (by
> > hardwiring them) between on-board devices and PCI slots is also common
> > practice.
> >
> > The PCI specification explicitly states that PCI devices can share
> > interrupt lines, and that your drivers must be capable of handling
> > this.
> >
> > Why is sharing a problem for you?
> >
> > If you do not have special realtime requirements, it usually should be
> > no problem...
>
> Thats the problem.
> I have real time requirements.
>
> The physic IRQ line can be shared, the only thing i need is the virtual 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 <j-almeida@criticalsoftware.com>:
> > >
> > > 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 changing the slot position of
> each
> > > board is not enought, to get something like (for example):
> > >         1 ethernet board IRQ = 169;
> > >         1 ADC card IRQ         = 170;
> > >
> > > Where in the kernel i can see the algorithms for the APIC system where the
> > > virtual IRQs are distributed? Or exist already any patch that permits to
> > > solve my problem?
> > >
> > > I'm using kernel 2.6.16.27, in a single machine with Intel pentium IV
> > > processor and chipset ICH4.
> > >
> > > Thanks for any reply.
> > > Greetings.
> > >
> > > --
> > > Jorge Almeida
> > > j-almeida@criticalsoftware.com
> > > DISCLAIMER: This message may contain confidential information or
> privileged material and is intended only for the individual(s) named. If you
> are not a named addressee and mistakenly received this message you should not
> copy or otherwise disseminate it: please delete this e-mail from your system
> and notify the sender immediately. E-mail transmissions are not guaranteed to
> be secure or without errors as information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the
> sender does not accept liability for any errors or omissions in the contents
> of this message that arise as a result of e-mail transmissions. Please
> request a hard copy version if verification is required. Critical Software,
> SA.
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
> --
> Jorge Almeida
> j-almeida@criticalsoftware.com
> DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.
>
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/