Chris Johns commented on a discussion on cpukit/include/dev/gpio/gpio.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159804 > + * > + * The pin must already be configured with a trigger other than > + * #RTEMS_GPIO_TRIGGER_NONE. > + * > + * @param fd is the descriptor for the controller's device node. > + * > + * @param pin is the logical pin whose interrupt to deliver. > + * > + * @param handler is the handler to call. > + * > + * @param arg is the argument to pass to the handler. > + * > + * @retval 0 Successful operation. > + * @retval -1 An error occurred. The errno is set to indicate the error. > + */ > +int rtems_gpio_pin_irq_enable(int fd, uint32_t pin, Should this API attempt to be closely coupled to GPIO hardware? Maybe it should not. If there is a need to bitbash I2C or SPI over a GPIO pin this API would present an upper clock rate and maybe that type of code handles the pin directly? If this is the case I would drop the interrupt API calls and move to a block model where a user waits in an `ioctl` call until the pin event and then returns? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159804 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-8iflqzogu44pdbyiuj8q8bm60-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
