Stephan <stephanwib%googlemail.com@localhost> writes:
> bcm_dmac_transfer(sc->sc_dmac);
> LED_ON();
> while (sc->sc_state == EMMC_DMA_STATE_BUSY) {
> error = cv_timedwait(&sc->sc_cv, &sc->sc_lock, hz * 10);
> if (error == EWOULDBLOCK) {
> device_printf(sc->sc.sc_dev, "transfer timeout!\n");
> bcm_dmac_halt(sc->sc_dmac);
> sc->sc_state = EMMC_DMA_STATE_IDLE;
> error = ETIMEDOUT;
> break;
> }
> }
> LED_OFF();
> mutex_exit(&sc->sc_lock);
>
> This also needs to be put in an #ifdef to be only included in a Pi build.
>
> Comments / hints / better ideas?
I wonder if it makes sense to generalize this, to have a bunch of naemd
(#define?) notification types, and macros to on/off, so that they get
defined to empty on systems where it doesn't make sense, and to
something sensible on various systems that have indicators. Surely the
RPI B isn't the only device where this makes sense, and there's probably
a lot different.
There was a comment about calling these "during the transfer" which was
too vague to be really helpful, but you might want to check the
locking/sleeping rules - generally one cannot call things that might
sleep from interrupts, etc. But given that the code is already calling
cv_timedwait, sleeping isn't really an issue (and I don't know what's
behind LED_ON()).
(A tangent: More generally, one of the harder things to figure out in
NetBSD (or anything) is what the locking/etc. rules are, and I think it
would help to have more explicit comments in each procedure about
assumptions.)
Attachment:
pgphk3vM6ypTk.pgp
Description: PGP signature