Afin de répondre à ta question il faut savoir que tu manipules deux types d'interruptions.
- Les interruptions matérielles, qui sont gérées par la couche matérielle GPIO je suppose. Ces interruptions sont remontées via un contrôleur matériel d'interruptions au processeur. Ce contrôleur peut être configuré pour masquer ou laisser passer certaines interruptions ainsi que gérer les priorités.
- Les interruptions logicielles, c'est la façon générique de manipuler les interruptions que reçoit le processeur donc après le passage dans le contrôleur d'interruption.
Les fonctions enable_irq / disable_irq vont certainement uniquement masquer les interruptions au niveau du contrôleur d'IT, ce qui veut dire que pendant que tu désactives les interruptions le matériel continue de recevoir des interruptions et de les remonter au contrôleur d'IT.
La solution que tu demandes consisterais à désactiver les interruptions matérielles pendant ton traitement. C'est possible mais je ne suis pas sûr que Linux te fournisse un lien entre ton interruption et la fonction de désactivation de la source de cette interruption (ça existe peut-être ceci dit)
Pourquoi Linux fonctionne de cette manière ? Car en général quand on désactive / réactive les interruptions c'est pour ne pas être interrompu pendant une section critique, ce genre de chose. Quand on réactive les interruptions on souhaite souvent être prévenu si un événement a eu lieu pendant ce temps.
En désactivant les interruptions matérielles tu dois être absolument certain qu'aucune race condition ne peut arriver. Si le volume d'interruptions est soutenable par le système je te conseille de ne pas chercher à désactiver les interruptions matérielles. Dans le pire des cas ton handler d'IT sera appelé quelques fois pour rien, ça ne devrait pas être grave.
Je te déconseille d'essayer d'utiliser le timestamp pour décider si une IT est à jeter ou non, c'est trop hasardeux car Linux n'est pas assez précis là dessus et que ça rajoute encore plus de race conditions.
ça te plaît qu'on te dise qu'il est urgent de ne rien faire ou la solution proposée ne convient vraiment pas à ton usage ? Si c'est le cas essaye de nous expliquer plus en détail ce que tu fais ça pourra nous aider à mieux répondre.
# Il est urgent de ne rien faire
Posté par teddyredm3cl . En réponse au message IRQ gpio sauvegarder pendant une disable_irq comment faire pour les reseter avant un enable_irq. Évalué à 1.
Afin de répondre à ta question il faut savoir que tu manipules deux types d'interruptions.
- Les interruptions matérielles, qui sont gérées par la couche matérielle GPIO je suppose. Ces interruptions sont remontées via un contrôleur matériel d'interruptions au processeur. Ce contrôleur peut être configuré pour masquer ou laisser passer certaines interruptions ainsi que gérer les priorités.
- Les interruptions logicielles, c'est la façon générique de manipuler les interruptions que reçoit le processeur donc après le passage dans le contrôleur d'interruption.
Les fonctions enable_irq / disable_irq vont certainement uniquement masquer les interruptions au niveau du contrôleur d'IT, ce qui veut dire que pendant que tu désactives les interruptions le matériel continue de recevoir des interruptions et de les remonter au contrôleur d'IT.
La solution que tu demandes consisterais à désactiver les interruptions matérielles pendant ton traitement. C'est possible mais je ne suis pas sûr que Linux te fournisse un lien entre ton interruption et la fonction de désactivation de la source de cette interruption (ça existe peut-être ceci dit)
Pourquoi Linux fonctionne de cette manière ? Car en général quand on désactive / réactive les interruptions c'est pour ne pas être interrompu pendant une section critique, ce genre de chose. Quand on réactive les interruptions on souhaite souvent être prévenu si un événement a eu lieu pendant ce temps.
En désactivant les interruptions matérielles tu dois être absolument certain qu'aucune race condition ne peut arriver. Si le volume d'interruptions est soutenable par le système je te conseille de ne pas chercher à désactiver les interruptions matérielles. Dans le pire des cas ton handler d'IT sera appelé quelques fois pour rien, ça ne devrait pas être grave.
Je te déconseille d'essayer d'utiliser le timestamp pour décider si une IT est à jeter ou non, c'est trop hasardeux car Linux n'est pas assez précis là dessus et que ça rajoute encore plus de race conditions.
ça te plaît qu'on te dise qu'il est urgent de ne rien faire ou la solution proposée ne convient vraiment pas à ton usage ? Si c'est le cas essaye de nous expliquer plus en détail ce que tu fais ça pourra nous aider à mieux répondre.