On 29 June 2012 15:52, Igor Mitsyanko <i.mitsya...@samsung.com> 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
