Momento crítico en un controlador de kernel ARM Linux

Estoy ejecutando Linux en un MX28 (ARMv5), y estoy usando una línea GPIO para hablar con un dispositivo. Desafortunadamente, el dispositivo tiene algunos requisitos de tiempo especiales. Un mínimo en la línea GPIO no puede durar más de 7 us, los altos no tienen requisitos de tiempo especiales. El código se implementa como un controlador de dispositivo del kernel, y alterna el GPIO con escrituras de registro directo en lugar de ir a través de la api GPIO del kernel. Para las pruebas, solo estoy generando 3 pulsos. El proceso es el siguiente, todo en una función, por lo que debe encajar en el caché de instrucciones:

establecer gpio altoGuardar banderas y desactivar interrupcionesgpio bajopausagpio altorepite 2x masBanderas de restauración / Interrupciones de Reenable

Aquí está la salida de un analizador lógico vinculado al GPIO.

La mayoría de las veces funciona simplemente bien, y los pulsos duran poco menos de 1us. Sin embargo, aproximadamente el 10% de los mínimos duran muchos, muchos microsegundos. Aunque las interrupciones están deshabilitadas, algo está causando que el flujo del código se interrumpa.

Estoy en una pérdida. Es probable que RT Linux no ayude aquí, porque el problema no es la latencia, parece que algo sucede durante el nivel bajo, aunque nada debería interrumpirlo con las IRQ deshabilitadas. Cualquier sugerencia sería grandemente apreciada grandemente

Respuestas a la pregunta(2)

Su respuesta a la pregunta