Re: Raspberry Pi ACT LED

[Jean-Baka Domelevo Entfellner <domelevo%gmail.com@localhost>]

Hi there,

Has anybody made any progress in having this ACT led to work and
indicate SD card activity? That would be really nice! I'm keen to test
any bit of experimental code on my RPi B+, if necessary :)

Thanks and regards,
   JB

On Thu, Apr 23, 2015 at 2:22 PM, Jared McNeill <jmcneill%invisible.ca@localhost> wrote:
> Sorry, ignore that. I've misunderstood the meaning of the _function
> functions. Try this instead:
>
> void
> bcm2835gpio_pin_write(u_int pin, u_int val)
> {
>         const bus_space_tag_t iot = &bcm2835_bs_tag;
>         const bus_space_handle_t ioh =
> BCM2835_IOPHYSTOVIRT(BCM2835_GPIO_BASE);
>         bus_size_t reg;
>
>         if (val) {
>                 reg = BCM2835_GPIO_GPSET(pin /
> BCM2835_GPIO_GPSET_PINS_PER_REGISTER);
>         } else {
>                 reg = BCM2835_GPIO_GPCLR(pin /
> BCM2835_GPIO_GPCLR_PINS_PER_REGISTER);
>         }
>
>         bus_space_write_4(iot, ioh, reg, 1 << (pin %
> BCM2835_GPIO_GPSET_PINS_PER_REGISTER));
>
> }
>
>
> On Thu, 23 Apr 2015, Jared McNeill wrote:
>
>> Set the value of a GPIO pin. Something like this (not compile tested):
>>
>> void
>> bcm2835gpio_function_write(u_int pin, u_int val)
>> {
>>         const bus_space_tag_t iot = &bcm2835_bs_tag;
>>         const bus_space_handle_t ioh =
>> BCM2835_IOPHYSTOVIRT(BCM2835_GPIO_BASE);
>>         const u_int mask = (1 << BCM2835_GPIO_GPFSEL_BITS_PER_PIN) - 1;
>>         const u_int regid = (pin / BCM2835_GPIO_GPFSEL_PINS_PER_REGISTER);
>>         const u_int shift = (pin % BCM2835_GPIO_GPFSEL_PINS_PER_REGISTER)
>> *
>>             BCM2835_GPIO_GPFSEL_BITS_PER_PIN;
>>         uint32_t v;
>>
>>         v = bus_space_read_4(iot, ioh, BCM2835_GPIO_GPFSEL(regid));
>>         v &= ~(mask << shift);
>>         v |= (val << shift);
>>         bus_space_write_4(iot, ioh, BCM2835_GPIO_GPFSEL(regid), v);
>> }
>>
>>
>> On Thu, 23 Apr 2015, Stephan wrote:
>>
>>> One thing is unclear to me: What is bcm2835gpio_function_write supposed
>>> to do?
>>>
>>> 2015-04-21 23:24 GMT+02:00 Jared McNeill <jmcneill%invisible.ca@localhost>:
>>>>
>>>> I would do this:
>>>>
>>>>  - Add bcm2835gpio_function_write to bcm2835_gpio_subr.[ch]
>>>>  - Pass the gpio pin from rpi_device_register to the mmc driver as a
>>>>    device property.
>>>>  - In the MMC driver, if the pin property is set, use it to toggle the
>>>> LED
>>>>    state. You've selected the right place to do it.
>>>>
>>>> Since this is all MD code (and we don't have a MI KPI for gpio access,
>>>> unfortunately) this approach should be fine.
>>>>
>>>>
>>>> On Tue, 21 Apr 2015, Stephan wrote:
>>>>
>>>>> 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.)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>