I don't disagree with the fact gpiolib is a good idea etc, however more often than not, if I'm hired to make a firmware for a particular device, the work required to tailor a driver for best efficiency is worth it, and will be minimal compared to the rest. You can always #ifdef the changes too...
If you use GPIOs for a couple LED, pin configuration and stuff like that it's perfectly adequate, and won't require a driver anyway. If your GPIO expander is on i2c then you clearly are not worrying about latency anyway, so gpiolib is just fine.
If you make a driver to use the gpios for more critical time sensitive things (overcurrent/thermal protections and that sort of things, or bitbanging), and then realize that actually, it's pretty crap and you'd be better off mmaping /dev/mem and poke at the registers directly from userland to get the performance/latency that is needed, your driver was a waste of time if you went that way first...
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.
for overcurrent and thermal protection, shouldn't you make an hwmon interface get lmsensors to look at it? Also how time sensitive are you looking at for those things?
Comments
I don't disagree with the fact gpiolib is a good idea etc, however more often than not, if I'm hired to make a firmware for a particular device, the work required to tailor a driver for best efficiency is worth it, and will be minimal compared to the rest. You can always #ifdef the changes too...
If you use GPIOs for a couple LED, pin configuration and stuff like that it's perfectly adequate, and won't require a driver anyway. If your GPIO expander is on i2c then you clearly are not worrying about latency anyway, so gpiolib is just fine.
If you make a driver to use the gpios for more critical time sensitive things (overcurrent/thermal protections and that sort of things, or bitbanging), and then realize that actually, it's pretty crap and you'd be better off mmaping /dev/mem and poke at the registers directly from userland to get the performance/latency that is needed, your driver was a waste of time if you went that way first...
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.
for overcurrent and thermal protection, shouldn't you make an hwmon interface get lmsensors to look at it? Also how time sensitive are you looking at for those things?