Is it means that other actual wire-based IRQ uses the least amount of time locking a core which leads the core can’t process my gpio interrupt request?Actually I already realize it’s the reason,beacuse I have tried to just registed a gpio interrupts and make my irq funtion empty,do nothing in my driver,and I compare my gpio interrupts numbers by cat/proc/interrupts with input pulse numbers,interrupts numbers is less than pulse numbers, it seems CPU even process my gpio irq request.
So is there no way to solve this problem?
Spoiler: Question for NVIDIA at the end. I don’t have a reasonable answer.
I’m not sure if there is a simple solution. From what you said, I’m wondering if CPU0 is simply not available at some particular moment. Some parts of kernel code are atomic and uninterruptible, and it is possible that the CPU core is not available at the moment of interrupt, and that the interrupt is not able to preempt what is running at that moment. Without hardware to buffer the GPIO pin state change (leading edge, trailing edge, or level), and assuming the event passes before the core is available, I don’t know how it would be possible to process the GPIO state change. This would have to be internal to the design of the driver. Does GPIO buffer events? I don’t know.
Normally I would say to increase the thread or process priority, possibly via the RT extensions you mentioned (RT patches don’t cause improved performance, but allow choosing priority among classes if and only if you’ve defined such classes to pick which one wins or loses time slices), but you are saying that there is no user space associated with this and thus there is no such ID (and there is no software interrupt either, and so ksoftirqd can’t be used to increase some of the work priority). How would one change the priority of a thread or process which has no ID to classify using that mechanism and without actually modifying the scheduler itself?
Ultimately, I don’t know enough about the NVIDIA GPIO kernel code and associated hardware and an answer requires knowing details of both. Your use-case never goes to user space software, which in turn means the priority mechanism you might normally use without modifying the kernel itself is not available. When a user space program talks to the kernel it becomes a system call (which can be traced via “strace”). It is really that system call which is given some priority.
For NVIDIA:
- Is there any kind of internal buffer associated with GPIO pins, especially when set up for use as an interrupt?
- Indirectly, is there any guarantee that a GPIO pin event will be recognized even if the CPU core is busy at the moment of an event (a question equivalent to the previous question about buffering)?
- Does the GPIO code in the kernel result in a system call similar to a user space program such that priority can be elevated without modifying scheduling code?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.