From: Artyom Tarasenko <atar4qemu@googlemail.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset
Date: Fri, 4 Jun 2010 22:30:40 +0200 [thread overview]
Message-ID: <AANLkTimIECcGHDEZQSjXtOPaL4a7A2OAMFt9VDXko711@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimg7DIuGVhXlCIbWA-H9T-i6HNuW6LWn3erqFxt@mail.gmail.com>
2010/6/4 Blue Swirl <blauwirbel@gmail.com>:
> On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>:
>>> On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko
>>> <atar4qemu@googlemail.com> wrote:
>>>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>:
>>>>> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko
>>>>> <atar4qemu@googlemail.com> wrote:
>>>>>> lower interrupt during chip reset. Otherwise the ESP_RSTAT register
>>>>>> may get out of sync with the IRQ line status. This effect became
>>>>>> visible after commit 65899fe3
>>>>>
>>>>> Hard reset handlers should not touch qemu_irqs, because on cold start,
>>>>> the receiving end may be unprepared to handle the signal.
>>>>
>>>> Wouldn't the real hardware lower irq on the hardware reset?
>>>
>>> Yes, but since qemu_irqs have no state, and on a cold start or system
>>> reset all other devices are guaranteed to be reset, the callback would
>>> be useless.
>>>
>>>> And if it would not, would it still clear the corresponding bit in
>>>> the ESP_RSTAT register?
>>>
>>> All registers are set to zero in the lines below.
>>>
>>>>
>>>>> See
>>>>> 0d0a7e69e853639b123798877e019c3c7ee6634a,
>>>>> bc26e55a6615dc594be425d293db40d5cdcdb84b and
>>>>> 42f1ced228c9b616cfa2b69846025271618e4ef5.
>>>>>
>>>>> For ESP there are two other sources of reset: signal from DMA and chip
>>>>> reset command. On those cases, lowering IRQ makes sense.
>>>>>
>>>>> So the correct fix is to refactor the reset handling a bit. Does this
>>>>> patch also fix your test case?
>>>>
>>>> It does, but
>>>>
>>>> +static void esp_soft_reset(DeviceState *d)
>>>> +{
>>>> + ESPState *s = container_of(d, ESPState, busdev.qdev);
>>>> +
>>>> + qemu_irq_lower(s->irq);
>>>>
>>>> Shouldn't it be esp_lower_irq(s)? What's going to happen to the
>>>> DMA_INTR bit if dma was the source of the irq?
>>>
>>> Again, the registers are zeroed in esp_hard_reset().
>>
>> How does it zero the _DMA_ registers? And sparc32_dma does share the
>> IRQ line with ESP, doesn't it?
>
> I'd suppose DMA registers are separate and they would not be cleared
> by for example ESP chip reset command. The IRQ goes from ESP to DMA,
> DMA has another line going to interrupt controller.
But do we have separate DMA lines in qemu? If we do, I'm absolutely fine with
qemu_irq_lower(s->irq) . If we don't, imagine the following scenario: DMA
rises an IRQ, then esp chip reset happens, and then... DMA can't rise
the IRQ anymore.
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
next prev parent reply other threads:[~2010-06-08 18:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-30 22:35 [Qemu-devel] [PATCH] sparc32 esp fix spurious interrupts in chip reset Artyom Tarasenko
2010-06-01 17:42 ` [Qemu-devel] " Blue Swirl
2010-06-01 19:56 ` Artyom Tarasenko
2010-06-01 20:09 ` Blue Swirl
2010-06-01 20:16 ` Artyom Tarasenko
2010-06-04 19:13 ` Blue Swirl
2010-06-04 20:30 ` Artyom Tarasenko [this message]
2010-06-09 20:35 ` Blue Swirl
2010-06-10 8:15 ` Artyom Tarasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimIECcGHDEZQSjXtOPaL4a7A2OAMFt9VDXko711@mail.gmail.com \
--to=atar4qemu@googlemail.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).