> it seems odd to have bits set in SDHC_EINTR_STATUS without
> SDHC_ERROR_INTERRUPT set in SDHC_NINTR_STATUS, and
> the two code paths seem different still
This is because the ESDHC doesn't set SDHC_ERROR_INTERRUPT in its
register since you've read SDHC_EINTR_STATUS and can see those bits
directly. So, for the sdhc driver, it needs to be emulated.
Don't we need to look at the error bits and take that into account
before the continue? As I read the code below, if SDHC_NINTR_STATUS
doesn't have SDHC_ERROR_INTERRUPT set, but some bits are set in
SDHC_EINTR_STATUS, then the continue (none for us) will still be taken.
Don't we still need to set the bit in status before that test? Isn't
that what the code did before? If I understand, the bug was not putting
SDHC_ERROR_INTERRUPT into xstatus for write-back/ack, and how the
synthetic SDHC_ERROR_INTERRUPT was generated for local consumption was
ok? (Sorry if I'm being dense - I'm finding this all a little hard to
follow.)
uint32_t xstatus = HREAD4(hp, SDHC_NINTR_STATUS);
status = xstatus;
error = xstatus >> 16;
if (!ISSET(status, SDHC_NINTR_STATUS_MASK))
continue; /* no interrupt for us */
/* Acknowledge the interrupts we are about to handle. */
xstatus |= (error ? SDHC_ERROR_INTERRUPT : 0);
HWRITE4(hp, SDHC_NINTR_STATUS, xstatus);
Attachment:
pgpf4XjCMZFyp.pgp
Description: PGP signature