From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=51867 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OGsHb-0003bL-P6
	for qemu-devel@nongnu.org; Tue, 25 May 2010 07:26:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <jan.kiszka@siemens.com>) id 1OGsHa-0002Xu-Hd
	for qemu-devel@nongnu.org; Tue, 25 May 2010 07:26:51 -0400
Received: from goliath.siemens.de ([192.35.17.28]:21554)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <jan.kiszka@siemens.com>) id 1OGsHa-0002Xn-76
	for qemu-devel@nongnu.org; Tue, 25 May 2010 07:26:50 -0400
Message-ID: <4BFBB3F3.20902@siemens.com>
Date: Tue, 25 May 2010 13:26:43 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFT][PATCH 09/15] hpet/rtc: Rework RTC IRQ
	replacement by HPET
References: <cover.1274732025.git.jan.kiszka@web.de>
	<201005251205.02782.paul@codesourcery.com>
	<4BFBB23E.20800@siemens.com>
	<201005251223.14409.paul@codesourcery.com>
In-Reply-To: <201005251223.14409.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: blue Swirl <blauwirbel@gmail.com>, Jan Kiszka <jan.kiszka@web.de>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Juan Quintela <quintela@redhat.com>

Paul Brook wrote:
>> Paul Brook wrote:
>>>>> This is wrong. The hpet device should expose this as an IO pin.
>>>> Will look into this.
>>>>
>>>> BTW, I just realized that the GPIO handling is apparently lacking
>>>> support for attaching an output to multiple inputs. Or am I missing
>>>> something?
>>> Use an explicit mux.
>>>
>>> Incidentally I suspect your handling of the ISA IRQs is broken. You may
>>> never have more than one source connected to a sink.  Shared IRQ lines
>>> must be done explicitly.
>> No, the other way around: one source (RTC) multiple sinks (HPET, ACPI).
>> Will probably draft a generic irq/gpio mux.
> 
> I realise that. However I'd expect things to break if the guest OS devices to 
> share an IRQ line between the HPET and some other device.

The guest would share IRQ8, not the RTC output. So there would be no
difference to the current situation.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux