Again, gpiolib lets you redefine gpio_get_value, gpio_set_value, gpio_cansleep and gpio_to_irq in the BSP to be specialized inline macros if you want to, it means that for a specific board you can just straight to the hardware if you want to avoid any kind of indirection. I don't see what you could possibly do to make it even faster, gpiolib or not.
But even if you don't do that the only cost will mostly be an indirect function pointer call to the GPIO controller's driver, we're talking nanoseconds here (assuming it's in cache). Might be worth it for bitbanging applications.
At any rate, while I totally believe there are situations where the gpiolib doesn't quite cut it I don't think it's good advice to tell kernel beginners (the audience of TFA) to avoid it on principle alone. In my experience 99% of the time I use GPIOs to de-reset a chip, read a switch/button or, when I feel fancy, light up a LED.
Comments
Can you point out exactly why it's pretty crap?
Again, gpiolib lets you redefine gpio_get_value, gpio_set_value, gpio_cansleep and gpio_to_irq in the BSP to be specialized inline macros if you want to, it means that for a specific board you can just straight to the hardware if you want to avoid any kind of indirection. I don't see what you could possibly do to make it even faster, gpiolib or not.
But even if you don't do that the only cost will mostly be an indirect function pointer call to the GPIO controller's driver, we're talking nanoseconds here (assuming it's in cache). Might be worth it for bitbanging applications.
At any rate, while I totally believe there are situations where the gpiolib doesn't quite cut it I don't think it's good advice to tell kernel beginners (the audience of TFA) to avoid it on principle alone. In my experience 99% of the time I use GPIOs to de-reset a chip, read a switch/button or, when I feel fancy, light up a LED.