Re: Raspberry Pi ACT LED

[Stephan <stephanwib%googlemail.com@localhost>]

Okay, LED_ON() and LED_OFF() is pseudo-code and should have indicated
the place to put the control functions in. The next question would be
how to control the LED - for example by utilizing the GPIO framework
or driver, which might be too much overhead. Another way could be
writing directly to the corresponding register. I guess the given code
snipped runs in process context and waits on a CV which gets signalled
from the interrupt context?!


Either way, it might be good to know how it is impleneted in Linux but
I couldn´t find the appropriate place yet. The ultra-fragmented nature
of Linux isn´t very helpful with finding things.

2015-04-21 14:24 GMT+02:00 Greg Troxel <gdt%ir.bbn.com@localhost>:
>
> 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.)