센서 제어와 영상 데이터는 경로가 다릅니다
- Sensor
노출·gain·영상 모드 등은 보통 I²C 같은 제어 경로로 설정합니다.
CSI-2 link로 영상 샘플을 전송합니다.
- CSI receiver / ISP
입력 link를 수신하고 구현에 따라 영상 처리를 수행합니다.
capture 장치가 RAM의 버퍼에 데이터를 씁니다.
- V4L2 video node
/dev/videoN의 ioctl로 format·buffer·stream을 제어합니다.
완료된 버퍼를 사용자 공간이 처리합니다.
- 사용자 프로그램
유효한 데이터 길이와 format에 맞춰 프레임을 해석합니다.
세로 화살표는 영상 데이터와 처리 단계의 흐름입니다. I²C가 영상 전체를 이 경로로 운반한다는 뜻은 아닙니다. USB UVC 등 다른 카메라는 연결 구조가 다릅니다.
Media Controller의 entity·pad·link는 이 연결을 표현합니다. sub-device의 pad format, link 설정, video node의 pixel format이 맞아야 합니다. /dev/video0을 열 수 있다는 사실만으로 sensor에서 RAM까지 전 경로가 정상이라는 뜻은 아닙니다. Media Controller의 연결 모델
CSI-2 가상 채널은 센서를 합쳐도 출처를 구분합니다
CSI-2 카메라 여러 개를 한 응용 프로세서 입력에 연결할 때, Lattice의 CrossLink-NX 레퍼런스 디자인은 각 입력 스트림에 서로 다른 가상 채널 ID를 지정한 뒤 하나의 CSI-2 출력으로 집약합니다. 이 기능은 물리적인 출력 링크 수를 줄이는 전송 경로의 설계이며, 여러 센서의 노출 시각을 자동으로 동기화하거나 영상 픽셀을 합성하는 기능은 아닙니다.
입력 패킷의 가상 채널 ID를 바꾸면 헤더의 ECC도 새 헤더 값에 맞춰 다시 계산해야 합니다. 이 디자인의 파서는 짧은 패킷과 긴 패킷을 구별해 ID와 ECC를 갱신할 수 있습니다. 새 ID는 0부터 15까지 설정할 수 있지만, 4 이상을 쓰는 경우에는 수신 장치가 CSI-2 2.x를 지원해야 합니다. 0부터 3까지의 ID만 필요한 구성과 8개 채널을 집약하는 구성을 같은 호환성 조건으로 취급하지 않습니다.
각 입력은 D-PHY에서 바이트 스트림으로 바뀌고, 채널별 버퍼를 거쳐 출력 스케줄러가 준비된 전송을 차례로 선택합니다. CrossLink-NX 가이드는 여러 채널이 준비됐을 때 라운드 로빈으로 선택한다고 설명합니다. 한 채널이 기다리는 사이 다음 영상 라인이 들어오면 FIFO가 더 필요합니다. 평균 전송률의 합이 출력의 이론상 최대값보다 작더라도, 긴 라인이나 겹치는 버스트 때문에 FIFO가 넘칠 수 있으므로 실제 라인 크기와 타이밍으로 시뮬레이션해야 합니다.
출력 대역폭 계산에는 각 입력의 데이터와 패킷·전송 오버헤드를 함께 넣습니다. 이 레퍼런스 디자인의 CrossLink-NX 하드 D-PHY 출력은 레인당 최대 2.5 Gbps, 네 레인에서 물리 계층 기준 최대 10 Gbps입니다. 이를 응용 프로그램에 전달되는 영상의 보장 처리량으로 해석하지 않습니다. 사용 가능한 대역폭은 채널 수, blanking, 출력 레인과 기어, 전송 간격 및 버퍼 용량에 따라 달라집니다.
CrossLink-NX 데이터시트는 하드 D-PHY와 프로그래머블 I/O를 이용한 소프트 D-PHY를 구분합니다. 레인 속도는 사용하는 부품·패키지·동작 조건의 전기적 특성 표와 IP 설정을 대조해야 합니다. 레퍼런스 디자인의 입력 최대값을 모든 패키지의 보장값으로 쓰지 않습니다. 비연속 입력 클록에서는 멈출 수 있는 바이트 클록과 같은 주파수의 연속 바이트 클록도 필요합니다.
이 집약 출력이 Linux의 카메라 프레임이 되려면 응용 프로세서의 CSI-2 수신기와 드라이버가 해당 가상 채널, 데이터 형식과 라우팅을 지원해야 합니다. FPGA가 가상 채널 ID를 붙였다는 사실만으로 각 센서가 자동으로 별도 V4L2 video node에 나타난다고 가정하지 않습니다. 수신기의 채널별 오류 카운터, media link·pad format, 스트림 라우팅, 실제 video node의 반환 형식을 함께 확인합니다.
원본 북마크 페이지는 2019년 CrossLink 계열과 2025년 CrossLink-NX 가이드를 함께 제공합니다. 전자는 최대 다섯 입력과 레인당 1.5 Gbps 출력 예이고, 후자는 최대 여덟 입력과 하드 D-PHY 레인당 2.5 Gbps 출력 예입니다. 수치가 다른 두 레퍼런스 디자인을 같은 제품의 보편적 사양으로 섞지 않습니다. 이 글은 하단 공식 문서의 개념과 설계 제약을 요약했으며, 소스 ZIP의 RTL·보드 실측 결과까지 검증했다는 뜻은 아닙니다.
레인당 2.5·1.5 Gbps는 위 Lattice 설계의 값이지 D-PHY 전체의 상한이 아닙니다. 2026-10-27 확인한 MIPI 공개 소개는 v3.6(2025년 9월)을 표시합니다. v3.0의 standard/short channel은 각각 9/11 Gbps이며 수신 CTLE를 도입했습니다. v3.5는 128-132b 인코딩·CDR을 쓰는 선택적 embedded clock을 추가했고 forwarded clock도 유지합니다. 이는 모든 부품이 지원한다는 뜻이 아닙니다. 회원 전용 사양을 읽은 것으로 간주하지 않고, 실제 부품의 버전·속도·동작 조건은 데이터시트로 확인합니다. MIPI D-PHY 사양 소개
원본 북마크 · 가상 채널 집약 CrossLink-NX 집약 가이드 · FPGA-RD-02148-1.2 CrossLink-NX 데이터시트 · FPGA-DS-02049-2.4 구형 CrossLink 집약 가이드 · FPGA-RD-02051-1.2
GMSL2의 제어 통신과 영상 전달을 따로 확인합니다
센서의 I²C ID를 읽을 수 있어도 프레임이 도착했다는 뜻은 아닙니다. GMSL2 영상은 센서의 CSI-2 출력, 직렬화기, GMSL2 링크, 역직렬화기의 CSI-2 출력을 거쳐 수신·캡처 경로로 이어집니다. Jetson에서는 NVCSI·VI와 V4L2 버퍼 완료까지 구분합니다. I²C는 설정을 전달하는 제어 경로이지 영상 프레임을 운반하는 경로가 아닙니다.
한 카메라·한 모드로 전원·클록·리셋, 로컬 역직렬화기, 원격 직렬화기·센서, stream-on, 영상·CSI-2 출력, 수신기·media graph, 실제 버퍼 완료를 차례로 확인합니다. 마지막으로 반복 확인된 단계 다음을 조사합니다. 링크 lock이나 /dev/videoN의 존재만으로 전체 경로를 통과했다고 판단하지 않습니다.
NVIDIA Jetson Linux r36.5의 AGX Orin GMSL 예제는 중복될 수 있는 물리 I²C 주소와 장치별 proxy 주소를 구분합니다. 공유 역직렬화기가 전원과 스트림 조정을 맡고, 센서 드라이버가 SerDes 드라이버를 제어합니다. 집약한 영상의 virtual channel 설정은 SerDes 출력·센서 모드·CSI·VI에서 맞아야 합니다. 이 소유권과 속성 규칙은 해당 BSP 예제의 계약이며 모든 SerDes 드라이버의 공통 ABI는 아닙니다. 여기서는 보드별 레지스터·설치 명령이나 실측 결과를 제시하지 않습니다.
DS90UB960의 VC 재매핑과 Linux 라우팅은 구분합니다
FPD-Link III의 DS90UB960-Q1은 네 수신 포트의 영상을 하나 또는 두 CSI-2 출력으로 모을 수 있습니다. 여기서 설명하는 VC는 이 칩의 CSI-2 데이터 식별자에 있는 2비트 필드, 즉 0~3입니다. 앞 절의 CrossLink-NX가 지원하는 확장 VC 범위와 섞지 않습니다. VC는 패킷의 흐름을 구분하는 값이며, 노출 시각을 맞추거나 픽셀을 합성하거나 Linux의 /dev/videoN 번호를 직접 정하는 값은 아닙니다.
TI SNLS589D, 2023년 9월 개정, §7.6.1.101의 CSI_VC_MAP(0x72)에는 입력 VC0~3에 대응하는 출력 VC 값이 각각 2비트씩 들어갑니다. 수신 포트별 레지스터 뱅크를 선택하는 문맥이 있으며, 이 레지스터는 CSI-2 입력 모드용입니다. RAW 모드의 데이터 형식·VC 설정을 같은 경로라고 취급하지 않습니다.
| 입력 VC | 비트 | 0xE4 | 0x55 |
|---|---|---|---|
| 0 | 1:0 | 출력 0 | 출력 1 |
| 1 | 3:2 | 출력 1 | 출력 1 |
| 2 | 5:4 | 출력 2 | 출력 1 |
| 3 | 7:6 | 출력 3 | 출력 1 |
0xE4는 각 입력 VC를 같은 번호로 보내는 배치이고, 0x55는 네 입력 VC를 모두 출력 VC1로 보냅니다. 이 두 값은 비트 필드 해석을 보여 주는 계산이며 장치에 쓰라는 명령이 아닙니다. 서로 다른 흐름을 같은 VC로 합친 경우 수신기가 별도 영상으로 자동 복원한다고 가정할 수 없습니다.
Linux v6.18 ds90ub960.c의 ub960_get_vc_maps()는 활성 라우트를 순회하면서 TX별 카운터로 VC를 배정하고, 이미 처리한 RX는 다시 배정하지 않습니다. 따라서 일반 규칙을 RX port number = output VC라고 쓸 수 없습니다. 같은 소스의 UB960 CSI-2 입력 분기는 선택한 RX의 네 매핑 필드에 같은 VC를 반복해 넣습니다. 칩이 입력 VC마다 개별 매핑을 지원한다는 것과 이 드라이버가 임의의 매핑 표를 사용자에게 제공한다는 것은 다릅니다. UB9702의 별도 분기도 이 UB960 설명으로 대신하지 않습니다.
프레임 설명에는 배정한 VC와 입력 데이터 형식이 연결됩니다. 최종 캡처까지는 CSI 수신기의 라우팅·형식 지원과 버퍼 완료를 확인해야 합니다. 대역폭, 프레임 동기화와 VC 배정은 각각 다른 설계 조건입니다. RidgeRun의 소개와 Jetson 사례는 주제 발견 자료로 읽었으며, 그 구성의 처리량·지연이나 오래된 실행 명령을 이 글의 실측 결과로 사용하지 않았습니다. 데이터시트 전체나 실제 카메라를 시험한 것은 아닙니다.
English summary
DS90UB960 CSI-2 input mode provides four two-bit VC mapping fields per RX port. 0xE4 preserves the four incoming IDs; 0x55 maps them all to VC1. The reviewed Linux v6.18 UB960 path repeats one assigned VC across those fields, with assignment based on active routes and per-TX counters. Hardware capability and driver policy differ. VC mapping does not guarantee video-node numbering, frame synchronization or successful capture. No registers were written.
libcamera는 파이프라인 운영과 영상 알고리즘을 나눕니다
V4L2와 Media Controller가 장치·연결·버퍼를 제공해도, 여러 센서·CSI 수신기·ISP를 일관된 카메라 동작으로 운영하는 코드는 필요합니다. libcamera의 Pipeline Handler는 장치별 구성과 실행·스케줄링 차이를 맡고, 응용 프로그램에는 공통 Camera API를 제공합니다. 커널 드라이버를 없애거나 모든 카메라를 자동 지원하는 대체 계층은 아닙니다.
| 구성요소 | 주요 책임 | 구분할 점 |
|---|---|---|
| CameraManager | 지원 카메라 발견과 Pipeline Handler 생성 | 어떤 video node든 곧바로 지원된다는 뜻은 아님 |
| Pipeline Handler | 장치별 파이프라인 구성·운영·필요한 스케줄링 | 커널 MC/V4L2 API를 사용하는 사용자 공간 구성요소 |
| IPA | 하드웨어 통계와 상위 제어값을 바탕으로 영상 처리 제어 계산 | 필요한 플랫폼에서 사용하는 알고리즘 모듈 |
예를 들어 ISP가 노출 판단용 통계를 만들고, CPU에서 실행되는 알고리즘이 다음 제어값을 계산하면 영상 처리 장치와 제어 루프를 이룰 수 있습니다. 공식 구조 문서의 3A는 자동 노출·자동 화이트 밸런스·자동 초점입니다. 이것은 IPA가 하드웨어 ISP의 모든 픽셀 처리를 소프트웨어로 대신한다는 뜻이 아닙니다. 호스트 CPU가 제어하는 ISP가 필요한 구성과 센서 내부 ISP를 사용하는 구성을 구분해야 하며, 모든 카메라에 같은 IPA나 같은 제어 항목이 필요한 것은 아닙니다.
프로세스 격리 여부도 단순히 “외부 업체 모듈인가?”로 결정하지 않습니다. 고정 버전 libcamera v0.7.2의 IPAManager::createIPA()는 일치하는 모듈을 찾은 뒤 isSignatureValid()가 참이면 T::Threaded, 거짓이면 T::Isolated 프록시를 생성하고, 이어 프록시 유효성을 확인합니다. 모듈을 찾지 못하거나 프록시가 유효하지 않으면 성공으로 반환하지 않습니다.
같은 버전 구현에서 공개키 지원이 없는 빌드, 강제 격리 설정, 모듈 파일 읽기·매핑 실패 또는 서명 검증 실패는 이 판정을 거짓으로 만듭니다. 따라서 구조 문서의 내장·외부 모듈 설명만으로 특정 설치의 실행 모드를 확정하면 안 됩니다. 격리 프록시를 택했다는 사실만으로 네트워크·파일 접근을 포함한 모든 보안 제한을 검증했다고 주장하지도 않습니다. 여기서는 서명·격리 설정을 바꾸거나 모듈을 로드하지 않았습니다.
v0.7.2 구조 문서, IPA 생성 분기, 서명 판정 구현을 대조했습니다. 2022년 소개 글의 장치 지원 목록·설치 절차는 재현하지 않았으며, 실제 카메라의 화질·지연·3A 동작을 측정한 결과가 아닙니다.
English summary
Pipeline Handlers orchestrate supported hardware through MC and V4L2; optional IPA modules close image-control loops with hardware statistics. IPA is not a replacement for kernel drivers or every ISP pixel operation. In v0.7.2, createIPA selects threaded or isolated proxies through the signature-validation result and then checks proxy validity. In-tree/vendor labels alone do not determine the observed branch. No modules, signing settings or hardware were changed.
QBUF는 사용할 버퍼를 드라이버에 넘깁니다
1. 버퍼 준비
REQBUFS로 버퍼 집합을 요청하고 QUERYBUF가 돌려준 offset·길이를 이용해 mmap합니다. offset을 물리 주소라고 가정하거나 임의로 바꾸지 않습니다. 요청한 개수와 실제 할당한 개수도 확인합니다.
2. QBUF 후
해당 index의 버퍼를 capture에 사용할 수 있도록 queue에 넣습니다. driver가 관리하는 동안 애플리케이션이 내용을 임의로 읽고 수정하면 안 됩니다. QBUF가 즉시 새 프레임 하나의 촬영 완료를 뜻하지는 않습니다.
3. 프레임 완료
장치·드라이버가 버퍼를 채워 완료 queue에 넣습니다. poll 등으로 준비 상태를 기다릴 수 있습니다. poll이 반환했다고 화면에 이미 표시됐다는 뜻은 아닙니다.
4. DQBUF와 사용자 처리
DQBUF가 돌려준 index·bytesused·timestamp·flags 등을 읽습니다. 데이터 처리를 마치면 같은 버퍼를 QBUF로 다시 넘길 수 있습니다. 계속 보관할 데이터라면 버퍼 재사용 전에 별도 보관·참조 수명을 설계해야 합니다.
단계는 버퍼의 사용 권한과 완료 상태가 바뀌는 순서입니다. QBUF·DQBUF 호출마다 프레임 전체를 새 메모리로 복사한다는 그림이 아닙니다.
해상도만 같다고 같은 프레임은 아닙니다
| 값 | 확인할 내용 |
|---|---|
| width / height | 영상의 가로·세로 샘플 수입니다. 메모리 stride와 같지는 않습니다. |
| pixel format | RGB·YUV·Bayer 등 샘플의 의미와 배치를 정합니다. |
| bytesperline | 한 줄을 저장할 때의 stride입니다. width × 임의의 바이트 수로 대신하지 않습니다. |
| sizeimage / bytesused | 할당에 필요한 공간과 이번 버퍼의 유효 데이터 길이를 구분합니다. |
| single-planar / multi-planar | 색 성분의 수와 API plane의 수를 단순히 동일시하지 않습니다. 실제 format·API를 확인합니다. |
format을 요청한 뒤에는 드라이버가 반환한 실제 값을 읽어야 합니다. 지원하지 않는 해상도나 정렬 조건 때문에 조정될 수 있습니다. 줄이 어긋나거나 색이 틀어졌다면 먼저 format과 stride를 확인합니다. V4L2 pixel format
전원은 probe 한 번으로 끝나지 않습니다
Linux 6.18 문서의 새 sensor driver는 runtime PM으로 clock·regulator·GPIO 등의 상태를 관리합니다. register 접근과 streaming에 필요한 동안 전원을 확보하고 사용이 끝나면 참조를 돌려줍니다. 옛 글의 .s_power() 예를 새 driver의 일반 규칙으로 가져오지 않습니다.
ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
/* 이제 센서 register 접근과 stream 시작을 수행합니다. */
/* 실패하면 이미 확보한 PM 참조를 반환해야 합니다. */이 코드는 PM 참조 확보 부분만 보인 예입니다. 센서 register 설정, error unwind, stream stop은 장치별로 구현해야 합니다. runtime_resume 안에서 무조건 v4l2_ctrl_handler_setup()을 호출하는 방식 역시 문서의 제약을 확인해야 합니다. sensor driver의 전원·clock 규칙
| 증상 | 나누어 확인할 단계 |
|---|---|
| DQBUF에서 계속 기다립니다. | QBUF, STREAMON, media link·format, sensor stream, receiver 오류, DMA 완료 순서로 확인합니다. |
| resume 뒤 첫 프레임만 깨집니다. | 전원·clock 복구, mode·control 재설정, stale buffer와 완료 상태를 확인합니다. |
| DMABUF fd는 전달했는데 화면이 깨집니다. | format·stride·수명·동기화와 importer가 지원하는 메모리 조건을 확인합니다. |
센서 모드는 세 계약이 맞아야 선택됩니다
Jetson의 mode0·mode1 같은 Device Tree 항목은 센서 동작값을 설명합니다. 이 선언만으로 사용자 프로그램이 임의의 번호를 선택할 수 있는 것은 아닙니다. 드라이버가 해당 모드를 구현하고 제어 항목을 노출해야 하며, 응용 프로그램은 그 제어 항목의 실제 지원 여부·범위·호출 형식을 확인해야 합니다. NVIDIA 문서에서 use_sensor_mode_id가 활성화된 경로는 TEGRA_CAMERA_CID_SENSOR_MODE_ID로 0부터 시작하는 모드를 명시적으로 선택합니다. 기본 모드 선택 경로는 해상도·색 형식·프레임 속도를 사용하므로 두 경로를 혼동하지 않습니다. Jetson 센서 모드 문서 (r36.3)
VIDIOC_S_EXT_CTRLS을 사용한다면 ioctl 인수는 struct v4l2_ext_controls이고, 그 안의 controls가 struct v4l2_ext_control 배열을 가리켜야 합니다. 단일 제어용 struct v4l2_control 포인터를 그대로 넘기는 것은 다른 ABI입니다. 먼저 VIDIOC_QUERY_EXT_CTRL 등으로 ID·범위·플래그를 확인하고, 설정 시점이 해당 드라이버의 스트림 상태에서 허용되는지도 검증합니다. Linux V4L2 확장 제어 API
2020년 Xavier NX 포럼 사례에서는 도구의 모드 설정과 직접 작성한 ioctl 코드의 결과가 달랐습니다. 후속 코드에는 확장 제어 구조체를 잘못 전달한 부분도 드러났지만, 원래의 EINVAL이 정확히 어느 조건에서 났는지는 대화만으로 확정되지 않습니다. 따라서 오류 번호 하나로 DT, 드라이버, 호출 시점 중 한 곳을 단정하지 말고 각각 분리해 확인합니다.
MMAP은 memcpy 시간을 보장하지 않습니다
V4L2의 MMAP 스트리밍은 장치 버퍼를 사용자 주소 공간에 매핑하고, QBUF·DQBUF에서 버퍼를 주고받는 방식입니다. 이 교환 자체는 프레임 전체를 복사하지 않습니다. 반면 응용 프로그램이 반환된 주소에서 별도 배열로 memcpy하면 별도의 전체 프레임 복사가 발생합니다. 매핑 가능하다는 사실은 그 주소를 CPU가 일반 malloc 메모리처럼 빠르게 읽는다는 보장이 아닙니다. Linux V4L2 MMAP 스트리밍
복사가 필요한 설계라면 같은 크기·stride·목적지·CPU 부하·반복 횟수로 시간을 재고, 버퍼의 메모리 속성과 CPU 접근 동기화, 실제 데이터 길이 및 프레임 주기 예산을 함께 확인합니다. 특정 보드에서 관찰한 복사 시간을 다른 Jetson 기기나 MMAP 전체의 고정 성능으로 일반화하지 않습니다.
복사를 줄이려면 후속 처리기가 같은 버퍼를 안전하게 사용할 수 있는지 먼저 봅니다. 드라이버와 소비자가 지원하면 DMA-BUF 같은 공유 경로를 검토하되, 버퍼 수명·소유권·동기화와 형식 조건을 확인해야 합니다. 공유 fd를 쓴다는 사실만으로 전체 파이프라인의 복사 횟수가 0이 되는 것은 아닙니다. Linux V4L2 DMA-BUF 가져오기 DMA 버퍼 사용 순서
D-PHY: 프레임 버퍼보다 먼저 확인할 연결 상태
/dev/videoN이 있어도 센서에서 수신기로 영상이 도착한다는 뜻은 아닙니다. 센서의 전원·리셋·외부 클록과 스트리밍 중 runtime PM 상태부터 확인하고, 실제 출력 모드의 link frequency를 수신기 설정과 맞춥니다. 이 절은 별도 clock lane을 쓰는 CSI-2 D-PHY 구성을 대상으로 합니다. 다른 PHY나 clock 방식까지 같은 절차로 일반화하지 않습니다. Linux 6.18 센서 드라이버 문서가 전원과 클록 관리의 기준입니다.
보드 배선과 양쪽 endpoint의 bus-type, 물리 data-lanes 순서, clock-lanes, 지원되는 lane-polarities 및 link-frequencies를 대조합니다. 물리 레인 번호와 논리 레인 순서를 혼동하지 않고, lane swap 지원 여부도 해당 하드웨어에서 확인합니다. DTS만 맞고 센서의 실제 레지스터 모드가 다르면 영상은 오지 않습니다. 비디오 endpoint binding은 공통 속성을 정의하지만 개별 장치의 지원 범위를 대신하지 않습니다.
Linux 6.18 송수신기 문서 §7.3.2에 따르면 HS 진입 전 LP 상태가 매우 짧아 소프트웨어가 놓칠 수 있습니다. 전원 직후 LP-00일 수도 있고, LP-11을 명시적으로 준비하는 기능은 송신기별로 다릅니다. 이를 사용하는 경로에서는 성공한 pre_streamon()마다 post_streamoff() 정리가 필요합니다. 자율적으로 전이를 처리하는 수신기까지 무조건 두 콜백을 요구하지 않습니다.
해당 수신기가 제공하는 동기·ECC/CRC·패킷 오류 상태를 본 다음 media link, pad format, 가상 채널을 확인합니다. 존재하지 않는 오류 카운터를 필수 계측값으로 만들지 않습니다. 이 경로와 QBUF·STREAMON·DQBUF의 버퍼 소유권을 분리하면 프레임 대기를 물리 링크 문제와 버퍼 문제로 나눌 수 있습니다. HS timing·종단·합격 파형은 실제 PHY와 센서 사양으로 정하며 여기서는 보드 시험을 수행하지 않았습니다.
조사 계기는 저장된 Leharika Prakash의 설명입니다. 원저자 그림을 복제하거나 사용자의 재공유가 확인됐다고 주장하지 않습니다.
English summary. A video node does not prove a working camera link. Check power, the actual sensor mode, endpoint lane mapping and receiver state before diagnosing buffer ownership. Explicit LP preparation is hardware-dependent, not a universal requirement.