From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1GgO4b-00062i-0a
	for qemu-devel@nongnu.org; Sat, 04 Nov 2006 11:08:45 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1GgO4a-000629-25
	for qemu-devel@nongnu.org; Sat, 04 Nov 2006 11:08:44 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1GgO4Z-000626-TC
	for qemu-devel@nongnu.org; Sat, 04 Nov 2006 11:08:43 -0500
Received: from [64.233.162.205] (helo=nz-out-0102.google.com)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1GgO4Z-00014o-Id
	for qemu-devel@nongnu.org; Sat, 04 Nov 2006 11:08:43 -0500
Received: by nz-out-0102.google.com with SMTP id 9so766579nzo
	for <qemu-devel@nongnu.org>; Sat, 04 Nov 2006 08:08:42 -0800 (PST)
Message-ID: <b921df970611040808m4c446c75q6c2771442a9d54d3@mail.gmail.com>
Date: Sat, 4 Nov 2006 17:08:42 +0100
From: "Alessandro Corradi" <ale.corradi@gmail.com>
Subject: Re: [Qemu-devel] Interrupt request info
In-Reply-To: <200611012331.38312.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_22144_15628287.1162656522452"
References: <200611011205.1gFjwA1qs3Nl3pX2@cave.mail.atl.earthlink.net>
	<002e01c6fe0d$0d434460$7e00a8c0@DELL3G>
	<200611012331.38312.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org

------=_Part_22144_15628287.1162656522452
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thank you very much for the answer,
so the only think to do to raise correctly an interrupt (I think) is only to
raise it when a read funciton is completed (in case of my simple memory)
because it will alarm the process in waiting status to read the value in the
register.

the workaround of a read operation of a cell of this memory is:
1)write address of the cell that I want to read in the address register,
2)send the execution request to get the value of the cell indicated by the
address reg (write on the command register the read opcode),
3)wait for control register response untill read operation is executed.
4)read the data register.

so I think that interrupt request must be between point 3 and 4.
Do you agree with my consideration?

I hope that writed something understandable :)

Thanks

Ale


2006/11/2, Paul Brook <paul@codesourcery.com>:
>
> On Wednesday 01 November 2006 23:25, Roger Lathrop wrote:
> > Alessandro,
> >
> > All you should need to do to raise an IRQ in your code is:
> > pic_set_irq(s->irq,1);
> >
> > When the irq is serviced (in one of your ioport traps, I would assume),
> > knock the irq down:
> > pic_set_irq(s->irq,0);
>
> No. You should use pic_set_irq_new. Otherwise your code will break on
> machines
> with multiple interrupt controllers.
>
> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

------=_Part_22144_15628287.1162656522452
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thank you very much for the answer,<br>so the only think to do to raise correctly an interrupt (I think) is only to raise it when a read funciton is completed (in case of my simple memory) because it will alarm the process in waiting status to read the value in the register.
<br><br>the workaround of a read operation of a cell of this memory is:<br>1)write address of the cell that I want to read in the address register,<br>2)send the execution request to get the value of the cell indicated by the address reg (write on the command register the read opcode),
<br>3)wait for control register response untill read operation is executed.<br>4)read the data register.<br><br>so I think that interrupt request must be between point 3 and 4.<br>Do you agree with my consideration?<br><br>
I hope that writed something understandable :)<br><br>Thanks<br><br>Ale<br><br><br><div><span class="gmail_quote">2006/11/2, Paul Brook &lt;<a href="mailto:paul@codesourcery.com">paul@codesourcery.com</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wednesday 01 November 2006 23:25, Roger Lathrop wrote:<br>&gt; Alessandro,<br>&gt;<br>&gt; All you should need to do to raise an IRQ in your code is:<br>&gt; pic_set_irq(s-&gt;irq,1);<br>&gt;<br>&gt; When the irq is serviced (in one of your ioport traps, I would assume),
<br>&gt; knock the irq down:<br>&gt; pic_set_irq(s-&gt;irq,0);<br><br>No. You should use pic_set_irq_new. Otherwise your code will break on machines<br>with multiple interrupt controllers.<br><br>Paul<br><br><br>_______________________________________________
<br>Qemu-devel mailing list<br><a href="mailto:Qemu-devel@nongnu.org">Qemu-devel@nongnu.org</a><br><a href="http://lists.nongnu.org/mailman/listinfo/qemu-devel">http://lists.nongnu.org/mailman/listinfo/qemu-devel</a><br></blockquote>
</div><br>

------=_Part_22144_15628287.1162656522452--