0

I'm stuck on example 1 from this tutorial. I found the Raspberry Pi code for it here. I uncommented the gpio_set_debounce line and compiled the module, but my switch still bounces a ton, resulting in dozens of interrupt calls per switch press. I tried it with and without a pulldown resistor and I get the same result.

My kernel headers version is linux-headers-4.4.13+.

Can someone try this out and see if they get the same result on their Pi?

4

Looking at the header it appears gpio_set_debounce isnt actually implemented which would explain why your code changes didnt make a difference

static inline int gpio_set_debounce(unsigned gpio, unsigned debounce)
{
    return -ENOSYS;
}

Try checking/printing the return value of your call to verify it is indeed so. (I wasnt able to find the headers for the exact kernel version you have mentioned).

Update on how I traced

The linux kernel source code cross reference is available here. The Raspbian version here should be mostly the same. I searched for gpio_set_debounce on the linux cross reference site and traced the following sequence

include/linux/gpio.h conditionally includes asm-generic/gpio.h or asm/gpio.h but also provides a default implementation (returning -ENOSYS) as fallback in case there is no specialization for the particular chip/device.

static inline int gpio_set_debounce(unsigned gpio, unsigned debounce)
{
    return -ENOSYS;
}

This is what i had mentioned previously

Looking at include/asm-generic/gpio.h one should see

 static inline int gpio_set_debounce(unsigned gpio, unsigned debounce)
 {
    return gpiod_set_debounce(gpio_to_desc(gpio), debounce);
 }

gpiod_set_debounce is declared in drivers/gpio/gpiolib.h and implemented in drivers/gpio/gpiolib.c

like so

int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce)
{
         struct gpio_chip        *chip;

         if (!desc || !desc->chip) {
                 pr_warn("%s: invalid GPIO\n", __func__);
                 return -EINVAL;
         }

         chip = desc->chip;
         if (!chip->set || !chip->set_debounce) {
                 gpiod_dbg(desc,
                           "%s: missing set() or set_debounce() operations\n",
                           __func__);
                 return -ENOTSUPP;
         }

         return chip->set_debounce(chip, gpio_chip_hwgpio(desc), debounce);
}

from @Jason's comment below I believe return -ENOTSUPP; is the value being returned indicating there is no implementation/support.

the file asm/gpio.h specific to arm looks like this where there isnt a specialization either.

| improve this answer | |
  • That's what the function looks like in my gpio.h, but gpio_direction_output has the same body and when I call that function on a pin with an LED connected to it (and pass 1 to the value parameter), the LED lights up. – Jason Sep 21 '16 at 2:55
  • So gpio_set_debounce returned -524 which, according to this, stands for "Operation is not supported". That explains my issue. However, why does the gpio_direction_output function have the same body, yet it returns 0 and actually has an effect on the pin? – Jason Sep 21 '16 at 2:58
  • 1
    (re)traced and found the following sequence in /include/asm-generic/gpio.h , /drivers/gpio/gpiolib.h , drivers/gpio/gpiolib.c gpio_set_debounce in gpio.h calls gpiod_set_debounce in gpiolib.h which is implemented in gpiolib.c lines 1210 - 1229 gpio_direction_output in gpio.h calls gpiod_direction_output_raw declared in gpiolib.h which is implemented in gpiolib.c lines 1120 - 1155 beyond that there seems to be a device specific implementation i couldn't find – Shreyas Murali Sep 21 '16 at 3:23
  • 1
    @Jason if an answer worked for you, it would nice to accept it by clicking the tick mark near it. – Shreyas Murali Sep 21 '16 at 5:28
  • How did you "(re)trace" it? I want to try that out. Also, I understand the voting system. However, as I pointed out in my second comment, there is another function in the same header file with the same body that is clearly implemented. Your answer's observation that "it appears gpio_set_debounce isn't actually implemented" based on the body of it is therefore inconclusive and might confuse another reader looking for similar help. If you remove that part of your answer and perhaps add an explanation of how you traced the functions, I'd be more willing to vote for it and possibly accept it. – Jason Sep 21 '16 at 9:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.