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: Thu, 10 Jun 2010 10:15:16 +0200 [thread overview]
Message-ID: <AANLkTinDDfsZxaUeVSdhlI-aMOb9bvctwdAe58-BPjWT@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikOKfC2N1McKR1qb1PRDd2plZDDYQotpwAFl8Dk@mail.gmail.com>
2010/6/9 Blue Swirl <blauwirbel@gmail.com>:
> On Fri, Jun 4, 2010 at 8:30 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> 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.
>
> What ESP does with its IRQ line does not stop DMA from using its line.
Then I'm fine with your patch.
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
prev parent reply other threads:[~2010-06-10 8:15 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
2010-06-09 20:35 ` Blue Swirl
2010-06-10 8:15 ` Artyom Tarasenko [this message]
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=AANLkTinDDfsZxaUeVSdhlI-aMOb9bvctwdAe58-BPjWT@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).