Arm Linux Kernel Hacks

rousalome.egloos.com

포토로그 Kernel Crash


통계 위젯 (화이트)

46107
469
422678


[Arm프로세서] GIC: 에지 트리거(Edge-triggered) 타입 인터럽트 Arm: GIC

이번에는 다음 그림을 보면서 'Edge-triggered' 인터럽트의 상태 머신을 알아봅시다.

 

그림 16.5 에지 트리거 인터럽트의 State Machine 변경 흐름

그림의 가장 왼쪽 부분에 있는 Inactive는 키보드와 터치와 같은 페리페럴에서 인터럽트가 발생하지 않는 상태입니다. 먼저 Inactive에서 pending로 상태가 바뀌는 흐름을 알아봅시다.

‘Inactive’ to ‘pending’

페리페럴이 인터럽트를 유발하지 않으면 상태 머신에서 Inactive 상태로 유지됩니다. 인터럽트가 발생(Assert)되면 GIC가 PE에게 인터럽트가 발생했다는 시그널을 보냅니다. 해당 인터럽트가 활성화됐고 우선 순위가 충분히 설정됐다면(우선 순위 레지스터보다 인터럽트 우선 순위가 높으면) Inactive에서 pending 상태로 변경됩니다.

‘Pending’ to ‘active’

인터럽트를 PE가 받아 소프트웨어적으로 ICC_IAR0_EL1 or ICC_IAR1_EL1 레지스터의 값을 읽으면 Pending에서 'active' 상태로 바뀝니다. 위에서 소개한 ICC_IAR_EL1 레지스터의 값만 읽으면 PE가 GIC에게 ACK를 전달하는 효과가 있습니다. GIC가 ACK를 받으면 해당 인터럽트의 시그널을 de-asserts합니다.  

‘Active’ to ‘active and pending’

페리페럴이 인터럽트 시그널을 re-assert하면 Active 상태에서 active and pending 상태로 바뀝니다. 이 동작이 레벨 트리거 타입 인터럽트에 비해 다릅니다.

‘Active and pending’ to ‘pending’

Arm 코어에서 실행되는 소프트웨어에서 ICC_IAR_EL1 레지스터에서 읽은 인터럽트 아이디를 EOIRs(End of Interrupt Registers) 레지스터에 써주면 Active and pending에서 pending으로 상태가 변경됩니다. Arm 코어에서 ICC_IAR_EL1 레지스터에서 읽은 인터럽트 아이디를 EOIRs 레지스터에 써줍니다.

CPU interface에서 인터럽트를 Arm 코어로 포워딩하면 GIC 인터럽트 핸들러에서 IAR 레지스트를 읽거나 EOI 레지스터에 인터럽트 아이디를 쓰는 루틴을 볼 수 있습니다. 이 과정에서 에지 트리거 타입의 인터럽트의 상태 머신이 어떻게 바뀌는지 머릿 속으로 그리면서 코드를 분석합시다.

여기까지 살펴본 레벨 센시티브 타입과 에지 트리거 인터럽트의 상태 변화도는 GIC의 동작 원리를 이해하기 위해 잘 익혀야 합니다.


덧글

댓글 입력 영역