[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL] Standard SD host controller model

From: Igor Mitsyanko
Subject: Re: [Qemu-devel] [PULL] Standard SD host controller model
Date: Fri, 29 Jun 2012 19:22:52 +0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 06/29/2012 07:01 PM, Peter Maydell wrote:
On 29 June 2012 15:52, Igor Mitsyanko <address@hidden> wrote:
On 06/29/2012 02:59 PM, Peter Maydell wrote:
The irq code looks dubious: we seem to have a single output
irq, but the code does things like:
     qemu_set_irq(sdhci->irq, sdhci->errintsigen & sdhci->errintsts);
but in other code paths:
     qemu_set_irq(sdhci->irq, sdhci->norintsigen & sdhci->norintsts);
It seems much more likely that the hardware has various interrupt
conditions which are effectively ORed together than that there
are some cases where the interrupt line is driven by one condition
and some where it's driven by the other.
Sure, full interrupt trigger condition would be
if ((s->norintsts & s->norintsigen) || (s->errintsts & s->errintsigen) ||
        ((s->norintsts & SDHC_NIS_INSERT) && (s->wakcon & SDHC_WKUP_ON_INS))
        ((s->norintsts & SDHC_NIS_REMOVE) && (s->wakcon & SDHC_WKUP_ON_RMV)))

but there's no point in using full check everywhere, if execution of some
specific code block could result in generation of normal interrupt request
only (bits in norintsts) or error interrupt request only (bits in
errintsts), then its the only condition we need to check.
But what if there was already a norintsts interrupt asserted, and this
code path is for the errintsts? Then if the errintsigen is such that
the errintsts is masked, you've just set the irq line to 0 and dropped
the norintsts interrupt, haven't you?

-- PMM

Yeah, I have) it should be qemu_set_irq(sdhci->irq, sdhci->slotint) then

reply via email to

[Prev in Thread] Current Thread [Next in Thread]