이 문서의 라이센스는 GPL 라이센스를 따릅니다(This document is released under the GPL license).
리눅스와 디바이스 트리
———————-
디바이스 트리 데이터를 위한 리눅스 사용 모델
저자: Grant Likely <grant.likely@secretlab.ca>
번역: 양정석 <dasomoli@gmailREMOVETHIS.com>
이 글은 리눅스가 디바이스 트리를 어떻게 사용하는지를 설명합니다.
디바이스 트리 데이터 포멧의 개요는 devicetree.org[1]에 있는 디바이스
트리 용법 페이지에서 찾을 수 있습니다.
[1] http://devicetree.org/Device_Tree_Usage
“오픈 펌웨어 디바이스 트리” 또는 간단히 디바이스 트리(DT)는 하드웨어를
서술하기 위한 데이터 구조와 언어입니다. 더 정확하게는, 어떤 운영 체제에
의해 읽혀져서 운영 체제가 그 머신의 상세 사항을 하드 코딩할 필요 없게
하는 한 하드웨어의 서술입니다.
구조적으로, DT는 이름있는 노드들로 이루어진 하나의 트리, 또는 사이클이
없는 그래프이고, 노드들은 임의의 데이터를 캡슐화하는 이름있는 프로퍼티
를 임의의 개수만큼 갖습니다. 또한 한 노드에서 자연스러운 트리 구조의
밖 다른 곳으로 임의의 연결을 만들 수 있는 메카니즘도 존재합니다.
개녑적으로, 데이터 버스, 인터럽트 라인, GPIO 연결, 그리고 부속 장치들을
포함하는 일반적인 하드웨어 속성을 서술하기 위해서 트리 안에서 데이터가
어떻게 나타나야 하는지를 위한 ‘바인딩’이라고 부르는 사용 용법의 공통
부분이 정의됩니다.
가능한 한 많이, 이미 존재하는 지원 코드의 사용을 최대화하기 위해서
이미 존재하는 바인딩을 사용해서 하드웨어가 서술됩니다. 그러나 프로퍼티와
코드 이름은 간단한 문자열이기 때문에, 이미 존재하는 바인딩을 확장하거나,
새로운 노드와 속성을 정의하는 것으로 새로운 것을 하나 생성하는 것은
쉽습니다. 그러나, 이미 존재하는 것에 대한 어떤 과제를 먼저 하지 않고,
새로운 바인딩을 생성하는 것은 조심하세요. 이전에 어떻게 기존 시스템에서
i2c 디바이스들이 열거되는지를 먼저 파악하지 않고 생성된 새로운 바인딩
때문에 현재 두가지 다른, 호환되지 않는 i2c 버스를 위한 바인딩이 있습니다.
1. 역사
——-
DT는 원래 오픈 펌웨어로부터 어떤 (운영 체제 같은)클라이언트 프로그램에게
데이터를 전달하기 위한 통신 방법의 일종으로 오픈 펌웨어에 의해서
생성되었습니다. 운영 체제는 런타임에 하드웨어의 구성을 알아내기 위해서
디바이스 트리를 사용했고, 그럼으로써 하드 코딩된 정보 없이 (모든
디바이스를 위한 드라이버가 가용함을 가정하여) 이용 가능한 하드웨어의
한 주류를 지원하였습니다.
오픈 펌웨어는 PowerPC 와 SPARC 플랫폼에서 일반적으로 사용되었기 때문에,
이들 아키텍처의 리눅스의 지원은 오랫동안 디바이스 트리를 사용했습니다.
2005년에, PowerPC 리눅스가 많은 코드 정리와 32비트와 64비트 지원을
통합하기 시작했을 때, 오픈 펌웨어를 사용하느냐와 상관없이 모든 PowerPC
플랫폼 상에서 DT 지원이 필요하다는 결정이 내려집니다. 이것을 하기 위해서
진짜 오픈 펌웨어 구현을 필요로 하지 않는 바이너리 덩이로 커널로 전달할 수
있는 평면 디바이스 트리(FDT: Flattened Device Tree)라고 불리는
DT 표현방법이 만들어 졌습니다. U-Boot, kexec, 그리고 다른 부트로더들이
디바이스 트리 바이너리(dtb: Device Tree Binary)를 전달하기 위한, 그리고
부팅 타임에 dtb를 수정하기 위한 두가지를 지원하기 위해서 수정되었습니다.
DT는 또한 PowerPC 부트 래퍼 (arch/powerpc/boot/*)에 추가되어 dtb가 기존의
DT가 아닌 것을 아는 펌웨어의 부팅을 지원하기 위한 커널 이미지와 함께
싸여질 수 있게 되었습니다.
조금 지나서부터는, FDT 구조는 모든 아키텍처에 사용가능하도록 일반화
되었습니다. 이 것이 쓰여지는 시점에, 6개의 메인 라인 아키텍처(arm,
microblaze, mips, powerpc, sparc, 그리고 x86)와 1개의 메인 라인은
아닌 아키텍처(nios)가 여러 단계의 DT 지원을 하고 있습니다.
2. 데이터 모델
————–
만약 여러분이 이미 디바이스 트리 용법[1] 페이지를 읽지 않았다면,
지금 가서 읽으세요. 괜찮아요. 내가 기다리죠….
2.1 하이 레벨 뷰
—————-
이해를 위해 가장 중요한 것은, DT가 간단히 하드웨어를 서술하는 하나의
데이터 구조라는 것입니다. 그에 관한 마법 같은 것은 없어요. 그리고,
마법을 사용해서 모든 하드웨어 설정 문제를 날려버리도록 하지도 않습니다.
그게 하는 것은 리눅스 커널 안에서 (혹은 그 문제를 위한 다른 운영체제
안에서) 그 보드로부터의 하드웨어 설정과 디바이스 드라이버 지원의
결합을 끊는 언어를 제공하는 것입니다. DT를 사용하는 것은 보드와 디바이스
지원이 데이터 중심(Data driven)이 되도록 합니다; 머신마다 하드 코딩된
선택들 대신 커널로 전달된 데이터에 기조한 셋업 결정을 내리기.
이상적으로는, 데이터 중심 플랫폼 셋업은 더 적은 코드 중복을 가져오고,
하나의 커널 이미지로 광범위한 하드웨어 지원을 쉽게 만듭니다.
리눅스는 DT 데이터를 다음 세가지 주요 목적을 위해 사용합니다:
1) 플랫폼 식별,
2) 런타임 환경 설정,
3) 디바이스 실제 장착
2.2 플랫폼 식별
—————
무엇보다도 먼저, 커널은 그 특정 머신을 식별하기 위해서 DT 안의 데이터를
사용할 것입니다. 완벽한 세상에서, 모든 플랫폼의 상세 사항은 디바이스
트리에 의에서 완벽히 일관되고 신뢰성있게 서술될 것이므로, 그 특정
플랫폼은 커널에게 문제가 되지 않습니다. 하드웨어가 완벽하지 않음에도,
커널은 초기 부팅 동안 그 머신을 식별해야만 하고 그로 인해 그 머신
의존적인 수정 사항을 실행할 수 있는 기회를 가집니다.
대부분의 경우에, 그 머신 식별은 엉뚱하고, 그 커널은 대신 머신의 코어
CPU나 SoC에 기초한 셋업 코드를 선택할 것입니다. ARM 을 예로 들면,
arch/arm/kernel/setup.c 안의 setup_arch() 는 machine_desc 테이블을
검색하고, 디바이스 트리 데이터와 가장 알맞은 machine_desc를 고르는
arch/arm/kernel/devtree.c 안에 있는 setup_machine_fdt()를 호출할
것입니다. 루트 디바이스 트리 노드 안에 있는 ‘compatible’ 프로퍼티에서
찾고 (궁금하다면, arch/arm/include/asm/mach/arch.h 내에 정의된)
struct machine_desc 안의 dt_compat 리스트와 비교함으로써 가장 알맞은
것을 결정합니다.
‘compatible’ 프로퍼티는 그 머신의 정확한 이름으로 시작하는 문자열의
정렬된 리스트를 포함하고, 그 보드와 가장 크게 호환되는 것에서부터
가장 적은 순으로 정렬된 보드들의 부가 리스트가 뒤따릅니다. 예를 들면,
TI BeagleBoard를 위한 루트 compatible 프로퍼티와 BeagleBoard xM 보드
같은 그 후계자는 각각:
compatible = “ti,omap3-beagleboard”, “ti,omap3450”, “ti,omap3”;
compatible = “ti,omap3-beagleboard-xm”, “ti,omap3450”, “ti,omap3”;
여기서 “ti,omap3-beagleboard-xm” 은 정확한 모델을 지정합니다. 그것은
또한 OMAP 3450 SoC, 그리고 일반적인 omap3 계열과 호환된다고 주장합니다.
여러분은 그 리스트를 가장 크게 특징적인 것(정확한 보드)에서 가장 적게
특징적인 것(SoC 계열)로 정렬함을 알아챌 수 있을 것입니다.
영리한 독자는 Bealge xM 은 또한 원래의 Beagle 보드와 호환된다고 주장함에
주목할 수 있습니다. 그러나, 같은 제품 라인이고, 한 보드가 다른 것과
호환된다고 주장할 때, 무엇을 의미하는지 정확히 못박기 어려울 지라도,
보통 한 보드에서 다른 것으로의 하이 레벨의 변경이 있는 한, 하나는 그
보드 레벨에서 그렇게 하는 것에 대한 경고를 받아야 합니다. 최고 레벨에서
한 쪽의 경고가 잘못되고, 한 보드가 다른 것과 호환된다고 주장하지 않는
것이 더 낫습니다. 유의할만한 예외는 싣는 보드로 한 CPU 모듈이 붙여졌을
때 같이, 한 보드가 다른 보드를 싣고 있을 때 입니다.
compatible 값에 대해 하나 더. compatible 프로퍼티 안에 사용되는 어떤
문자열도 그게 나타내는 것에 대해서 문서화되어야만 합니다. compatible
문자열에 대한 문서를 Documentation/devicetree/bindings 안에 추가하세요.
ARM 으로 돌아가서, 각각의 machine_desc에 대해서, 커널은 compatible
프로퍼티 안에 어떤 dt_compat 리스트 항목이 나타나지는 않는지 살펴봅니다.
하나가 그렇다면, 그 machine_desc는 그 머신으로 들어가기 위한 후보가
됩니다. machine_desc 의 전체 테이블을 검색한 후에, setup_machine_fdt()는
각 machine_desc 와 비슷한 compatible 프로퍼티 내의 항목을 기초로
‘가장 호환되는’ machine_desc를 반환합니다. 비슷한 machine_desc을
아무것도 찾지 못했다면, NULL 을 반환합니다.
이 동작 방식 뒤에 숨어있는 이유는 대부분의 경우에 그들이 모두 같은
SoC나 Soc의 같은 계열을 사용한다면, 하나의 machine_desc가 많은 수의
보드를 지원할 수 있다는 관측 때문입니다. 그러나 변함없이 특정 보드는
일반적인 경우에는 쓸데없는 특정 셋업 코드를 필요로 한다는 예외가
있습니다. 특별한 경우들은 일반적인 셋업 코드 안의 문제를 일으킬 수 있는
보드(들)을 위한 명시적인 검사에 의해 처리될 수 있습니다만, 크게 서둘러
그렇게 하는 것은 몇가지 경우보다 더 많아질 경우, 추하고 (또는)
관리할 수 없게 됩니다.
대신에 compatible 리스트는 dt_compat 리스트 안에 “더 적은 compatible”
값을 지정함으로써 일반적인 machine_desc가 광범위한 공용 보드들을 지원할
수 있도록 합니다. 위의 예에서, 일반적인 보드 지원은 “ti,omap3” 또는
“ti,omap3450″과 호환된다고 주장할 수 있습니다.. 원래의 beagleboard 에서
부팅 초기에 특별한 특수 조치 코드가 필요한 버그가 발견된다면, 새로운
machine_desc 는 그 특수 조치를 구현해서 “ti,omap3-beagleboard” 에만
맞게 되도록 추가할 수 있습니다.
PowerPC는 각 machine_desc 로부터 .probe() 를 호출하고, TRUE를 반환하는
첫번째 것이 사용되는 약간 다른 동작 방식을 사용합니다. 그러나, 이 접근법은
compatible 리스트의 우선 순위를 반영하지 않고, 아마도 새로운 아키텍처
지원을 위해서는 피해야 합니다.
2.3 런타임 환경 설정
——————–
대부분의 경우에, 하나의 DT는 펌웨어에서 커널로 데이터를 주고 받을 수
있는 하나밖에 없는 방법이 될 것이고, 그래서 또한 런타임에 initrd 이미지의
위치와 커널 파라미터 문자열 같은 환경 설정 데이터를 넘기는데 사용되기
시작합니다.
이 데이터의 대부분은 /chosen 노드 안에 포함되고, 리눅스가 부팅될 때,
이와 같은 것들이 보일 것입니다:
chosen {
bootargs = “console=ttyS0,115200 loglevel=8”;
initrd-start = <0xc8000000>;
initrd-end = <0xc8200000>;
};
bootargs 프로퍼티는 커널 인자들을 포함하고, initrd-* 프로퍼티들은 initrd
덩이의 주소와 크기를 정의합니다. initrd-end 는 initrd 이미지 이후의
첫번째 주소임에 유의하세요. 그래서 이것은 struct resource의 일반적인
용법과 일치하지 않습니다. chosen 노드는 또한 옵션으로 플랫폼 의존적인
환경 설정 데이터를 위한 임의의 개수의 추가 프로퍼티들을 포함할 수 있습니다.
초기 부팅 동안, 아키텍처 셋업 코드는 페이징이 셋업되기 전에 디바이스
트리를 파싱하는 다른 헬퍼 콜백들과 of_scan_flat_dt()를 여러번 호출합니다.
of_scan_flat_dt() 코드는 디바이스 트리를 스캔하고 초기 부팅 동안 필요한
정보를 추출하는 헬퍼를 사용합니다. 일반적으로 early_init_dt_scan_chosen()
헬퍼는 커널 파라미터를 포함하는 chosen 노드를 파싱하는데,
early_init_dt_scan_root()는 DT 주소 공간 모델을 초기화하는데, 그리고,
early_init_dt_scan_memory()는 사용 가능한 RAM의 위치와 크기를 결정하는데
사용됩니다.
ARM 상에서 setup_machin_fdt() 함수는 맞는 그 보드를 지원하는
machine_desc를 선택한 후에 디바이스 트리의 초기 스캐닝을 책임집니다.
2.4 디바이스 실제 장착
———————-
보드가 식별되고 난 후에, 그리고 초기 환경 설정 데이터가 파싱된 후에는,
커널 초기화가 보통의 방법으로 수행될 수 있습니다. 이 프로세스의 어떤
시점에, unflatten_device_tree()가 더 효율적인 런타임 표현 방식으로 데이터를
변환하기 위해서 호출됩니다. 이것은 또한 ARM 에서의 machine_desc
.init_early(), .init_irq(), 그리고 init_machine() 훅 같은 머신 의존적인
셋업 훅 때 실행되기 시작할 것입니다. 이 절의 나머지는 ARM 구현으로부터의
예제를 사용합니다. 그러나 모든 아키텍처에서 DT를 사용할 때 이와 같은
것들을 잘 수행할 것입니다.
이름에서 추측할 수 있듯이, .init_early() 는 부트 프로세스 내에서 일찍
실행될 필요가 있는 어떤 머신 의존적인 셋업을 위해 사용되고, .init_irq() 는
인터럽트 처리를 셋업하는데 사용됩니다. DT를 사용하는 것은 이들 함수들의
행위를 실제로 바꾸지 않습니다. DT가 제공되면 .init_early() 와 .init_irq()
모두 플랫폼에 대한 추가 데이터를 얻기 위해서 아무 DT 쿼리 함수
(include/linux/of*.h 안의 of_*)나 호출할 수 있습니다.
DT 안에서 가장 흥미로운 훅은 플랫폼에 대한 데이터로 리눅스 디바이스
모델을 실제 장착시키는 주된 책임을 가지는 .init_machine() 입니다.
역사적으로, 이것은 정적인 클럭 구조체, platform_devices, 그리고 보드 지원
.c 파일 안의 다른 데이터의 합을 정의함, 그리고 .init_machine() 안에서
일제히 등록되는 것으로써 임베디드 플랫폼 상에서 구현되었습니다. DT가
사용될 때, 각 플랫폼을 위한 하드 코딩된 정적 디바이스들 대신, 디바이스의
리스트가 DT를 파싱함으로써 얻어질 수 있고, 디바이스 구조체들을 동적으로
할당할 수 있습니다.
가장 간단한 경우는 .init_machine() 이 그냥 platform_devices 뭉치를 등록할
책임만을 가지고 있을 때 입니다. 한 platform_device 는 리눅스에서 하드웨어에
의해 찾을 수 없는 메모리 또는 I/O 매핑된 디바이스, 그리고 ‘복합적인’ 또는
‘가상의’ (이들 이후에는 또 다른) 디바이스로 사용되는 하나의 개념입니다.
DT 에서는 ‘플랫폼 디바이스’ 용어가 없는 반면, 플랫폼 디바이스는 대충 그
트리의 루트에 있는 디바이스 노드와 간단한 메모리 매핑된 버스 노드들의 자식에
해당합니다.
지금이 예제를 펼쳐 볼 좋은 시간인 것 같네요. 여기 NVIDIA Tegra 보드에 대한
디바이스 트리의 일부가 있습니다.
/{
compatible = “nvidia,harmony”, “nvidia,tegra20”;
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
chosen { };
aliases { };
memory {
device_type = “memory”;
reg = <0x00000000 0x40000000>;
};
soc {
compatible = “nvidia,tegra20-soc”, “simple-bus”;
#address-cells = <1>;
#size-cells = <1>;
ranges;
intc: interrupt-controller@50041000 {
compatible = “nvidia,tegra20-gic”;
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >;
};
serial@70006300 {
compatible = “nvidia,tegra20-uart”;
reg = <0x70006300 0x100>;
interrupts = <122>;
};
i2s1: i2s@70002800 {
compatible = “nvidia,tegra20-i2s”;
reg = <0x70002800 0x100>;
interrupts = <77>;
codec = <&wm8903>;
};
i2c@7000c000 {
compatible = “nvidia,tegra20-i2c”;
#address-cells = <1>;
#size-cells = <0>;
reg = <0x7000c000 0x100>;
interrupts = <70>;
wm8903: codec@1a {
compatible = “wlf,wm8903”;
reg = <0x1a>;
interrupts = <347>;
};
};
};
sound {
compatible = “nvidia,harmony-sound”;
i2s-controller = <&i2s1>;
i2s-codec = <&wm8903>;
};
};
.init_machine() 때, Tegra 보드 지원 코드는 이 DT를 살펴보고, 어떤 노드를
platform_devices 로 생성해야 할 지를 결정할 필요가 있을 것입니다.
그러나, 이 트리를 살펴보고, 즉시 어떤 종류의 디바이스가 각 노드로
표현된 것인지는 한 노드가 한 디바이스를 표현한 것이 전부일 지라도
명확하지 않을 것입니다. /chosen, /aliases, 그리고 /memory 노드는
디바이스를 나타내지 않는(아마 분명히, 메모리는 디바이스로 고려될 수
있겠지만) 정보를 전달하기 위한 노드들 입니다. /soc 노드의 자식들은
메모리 매핑된 디바이스지만, codec@1a 는 i2c 디바이스이고, sound 노드는
디바이스가 아니지만, 그보다는 다른 디바이스들이 오디오 서브 시스템을
만들기 위해서 함께 연결되어 있다고 표현합니다. 저는 이 보드 설계에
매우 익숙하기 때문에 각 디바이스가 무엇인지 압니다만, 커널은 어떻게
이 노드들로 무엇을 해야 할 지 알 수 있을까요?
그 트릭은 커널이 트리의 루트에서 시작하고, ‘compatible’ 프로퍼티를 가진
노드들을 살피는 겁니다. 첫째, 일반적으로 ‘compatilbe’ 프로퍼티를 가진
어떤 노드는 어떤 종류의 디바이스를 표현한다고 가정하고, 둘째, 그 트리의
루트에 있는 어떤 노드는 직접 프로세서 버스에 붙거나, 또는 다른 방식으로
설명할 수 없는 기타 시스템 디바이스라고 가정할 수 있습니다. 각 트리
노드에 대해, 리눅스는 차례차례 platform_driver 로 향하게 될
platform_device 를 할당하고 등록합니다.
왜 이들 노드를 위해 platform_device 를 사용하는 것이 안전한 가정일까요?
글쎄요, 리눅스가 디바이스를 모델링하는 방법에서, 거의 모든 bus_types 는
그 디바이스들이 버스 컨트롤러의 자식이라고 가정합니다. 예를 들면,
각 i2c_client 는 i2c_master 의 한 자식입니다. 각 spi_device 는 SPI 버스의
한 자식이고요. 유사하게 USB, PCI, MDIO, 기타도 그렇습니다. 같은 계층 구조는
DT에서도 역시 I2C 디바이스 노드들은 오직 I2C 버스 노드의 한 자식으로만
나타나는 데서 찾을 수 있습니다. SPI, MDIO, USB. 기타도 동일합니다. 부모
디바이스의 특정 타입을 필요로 하지 않는 디바이스는 오직 리눅스
/sys/devices 트리의 바닥에서 행복하게 살 platform_devices(그리고,
amba_devices, 이후에 나올 다른 것들)입니다. 그래서 한 DT 노드가 그 트리의
루트 노드라면, 정말로 아마도 그것은 하나의 platform_device로 등록되는 것이
최선입니다.
리눅스 보드 지원 코드는 그 트리의 루트에 있는 디바이스를 찾기 시작하기
위해서 platform_populate(NULL, NULL, NULL, NULL) 를 호출합니다. 그 트리의
루트로부터 시작할 때, 시작 노드(첫번째 NULL), 부모 struct device(마지막
NULL)을 줄 필요가 없고, 우리는 매치 테이블을 (아직) 사용하고 있지 않기
때문에, 그 파라미터들은 모두 NULL 입니다. 오직 디바이스를 등록할 필요가
있는 한 보드를 위해서, .init_machine() 은 of_platform_populate() 함수를
위해서를 제외하면 완전히 텅 빌 수 있습니다.
Tegra 예제에서, 이것이 /soc 와 /sound 노드의 이유입니다. 그러나 SoC
노드의 자식에 대해서는 뭘까요? 그들도 플랫폼 디바이스로 등록되어야만
하지 않을까요? 리눅스 DT 지원에서, 자식 디바이스를 위한 일반적인 동작은
그 부모의 디바이스 드라이버에 의해서 드라이버 .probe() 때 등록되는
것입니다. 그래서 i2c 버스 디바이스 드라이버는 각 자식 노드를 위한
i2c_client 를 등록할 것이고, SPI 버스 드라이버는 그 spi_device 자식을
등록할 것이고, 유사하게 다른 bus_types도 그럴 겁니다. 이 모델에 따라
드라이버는 SoC 노드로 바인드하고, 그 자식들 각 노드를 간단히
platform_devices로 등록하도록 작성될 수 있습니다. 보드 지원 코드는
SoC 디바이스를 할당하고 등록할 것이고, (이론적인) SoC 디바이스
드라이버는 SoC 디바이스로 바인드할 수 있고, 그 .probe() 훅 안에서
soc/interrupt-controller, /soc/serial, /soc/i2s, 그리고 /soc/i2c 를 위한
platform_devices 를 등록합니다. 쉽죠, 어때요?
실제로, 더 많은 platform_devices 처럼 어떤 platform_devices의 자식을
등록하는 것은 일반적인 패턴으로 나타납니다. 그리고 그 디바이스 트리 지원
코드는 그를 반영하고 위의 예제를 더 간단하게 만듭니다.
of_platform_populate() 의 두번째 인자는 of_device_id 테이블이고, 그 테이블
안의 한 항목과 매치되는 어떤 노드는 또한 그 등록된 자식 노드를 얻을
것입니다. Tegra 의 경우에 그 코드는 이것처럼 볼 수 있습니다:
static void __init harmony_init_machine(void)
{
/* … */
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
“simple-bus” 는 ePAPR 1.0 스펙 안에 간단한 메모리 매핑된 버스를 나타내는
한 프로퍼티로 정의됩니다. 그래서 of_platform_populate() 코드는
simple-bus 호환 노드는 언제나 가로지를 것임을 그저 가정하도록 작성될 수
있습니다. 그러나, 우리는 한 인자를 그 안으로 넣을 수 있어서 보드 지원
코드는 언제나 그 기본 동작을 오버라이드할 수 있습니다.
[i2c/spi/기타 자식 디바이스 추가에 대한 논의가 추가될 필요가 있음]
부록 A: AMBA 디바이스
———————
ARM Primecells 들은 하드웨어 찾기와 전력 관리를 위한 지원을 포함하는
ARM AMBA 버스에 붙는 특정 종류의 디바이스입니다. 리눅스에서,
struct amba_device 와 amba_bus_type 은 Primecell 디바이스를 표현하는데
사용됩니다. 그러나, 약간 성가신 것은 ABMA 버스 상의 모든 디바이스가
Primecells은 아니고, 리눅스를 위해 amba_device 와 platform_device
인스턴스 둘 다 같은 버스 세그먼트의 형제가 되는 것이 일반적입니다.
DT를 사용할 때, 이것은 platform_device 또는 amba_device 중에 어느 하나로
각 노드를 등록해야 하는지 결정해야만 하기 때문에 of_platform_populate()
에 문제를 만듭니다. 이것은 불행히 그 디바이스 생성 모델이 약간
복잡합니다. 그러나 그 해결책은 너무 깊이 퍼져 있어서 나타나지 않습니다.
만약 “arm,amba-primecell”과 호환되는 한 노드가 있으면,
of_platform_populate() 는 그것을 platform 디바이스 대신 amba_device 로
등록할 것입니다.