[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
BOUNCE rtl@rtlinux.org: Approval required: Non-member submissionfrom [Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>] (fwd)
- To: rtl@rtlinux.org
- Subject: BOUNCE rtl@rtlinux.org: Approval required: Non-member submissionfrom [Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>] (fwd)
- From: Der Herr Hofrat <der.herr@hofr.at>
- Date: Mon, 18 Jun 2001 12:16:42 +0200 (CEST)
>From owner-rtl Mon Jun 18 04:18:09 2001
Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6])
by hq.fsmlabs.com (8.11.2/8.11.2) with ESMTP id f5IAI8e19236
for <rtl@fsmlabs.com>; Mon, 18 Jun 2001 04:18:08 -0600
Received: from smtpscan-nl3.philips.com (localhost.philips.com [127.0.0.1])
by gw-nl4.philips.com with ESMTP id MAA04932
for <rtl@fsmlabs.com>; Mon, 18 Jun 2001 12:11:59 +0200 (MEST)
(envelope-from Iwo.Mergler@soton.sc.philips.com)
Received: from smtpscan-nl3.philips.com(130.139.36.23) by gw-nl4.philips.com via mwrap (4.0a)
id xma004928; Mon, 18 Jun 01 12:11:59 +0200
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1])
by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA23348
for <rtl@fsmlabs.com>; Mon, 18 Jun 2001 12:11:53 +0200 (MET DST)
Received: from kilkenny.soton.sc.philips.com (mailgate.soton.sc.philips.com [130.141.89.1])
by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA13383
for <rtl@fsmlabs.com>; Mon, 18 Jun 2001 12:11:49 +0200 (MET DST)
Received: from scorpion.soton.sc.philips.com (root@[130.141.7.31])
by kilkenny.soton.sc.philips.com (8.11.3/8.11.3) with ESMTP id f5I9Shv01610
for <rtl@fsmlabs.com>; Mon, 18 Jun 2001 10:28:47 +0100
Received: from soton.sc.philips.com (becks [130.141.7.80])
by scorpion.soton.sc.philips.com (8.9.3/8.9.3) with ESMTP id LAA02384
for <rtl@fsmlabs.com>; Mon, 18 Jun 2001 11:11:43 +0100 (BST)
Sender: mergler@soton.sc.philips.com
Message-ID: <3B2DD3DF.47BD677A@soton.sc.philips.com>
Date: Mon, 18 Jun 2001 11:11:43 +0100
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Reply-To: Iwo.Mergler@soton.sc.philips.com
Organization: Philips Semiconductors
X-Mailer: Mozilla 4.51 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: rtl@fsmlabs.com
Subject: Re: [rtl] off-topic: PCI interrupts
References: <20010617060647.B6975@hq2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Victor Yodaiken wrote:
>
> My belief is that shared interrupts are not very useful for RT systems - does anyone
> think otherwise?
>
> If an interrupt is shared between RT and non RT devices, the RT driver must do
>
> catch_interrupt:
> examine my device
> if interrupt is mine
> do regular handling
> else
> pend interrupt for Linux/BSD
> find the interrupting non-RT device
> clear device interrupt
> re-enable interrupts from this source
>
> The key point is that the RT driver needs to look at all non-RT devices
> in order to clear the interrupt source.
> This is not too hard, but it seems not very RT.
>
Victor,
Thanks for your message, it cleared up a few things for me.
I agree with you that a RT driver shouldn't have to deal
with shared interrupts.
However, there are situations where you just can't avoid it.
I've got a motherboard here which doesn't shuffle the PCI
interrupts - intA is always on the same hardware interrupt line.
Changing slots doesn't help here.
Would it be possible to call the Linux interrupt chain from
within the RT handler? And rely on the original driver to reset
the interrupt? I know this murders the predictability but it would
allow the original driver to cope with its own hardware. Imagine
a device which clears the interrupt as a response to a data
register read, like a serial port. There might be no way to
clear the interrupt without seriously disrupting the function of
the original driver.
Can anyone think of a less horrible solution?
Kind regards,
Iwo
----- End of forwarded message from owner-rtl@fsmlabs.com -----