Port-arm archive

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

Re: Raspberry Pi ACT LED

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

Attachment: pgphk3vM6ypTk.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index