질문 —
/sys/class/sensors/accelerometer_sensor에 값을 쓰면 그 명령은 실제로 어디까지 가는가?sysfs부터 다시 시작했다
sysfs는 disk에 저장된 일반 파일 시스템이 아니라 kernel object를 사용자 공간에 노출하는 ram 기반 파일 시스템이다. 그래서
kobject, kset, attribute가 어떻게 연결되는지부터 다시 정리했다.Galaxy Watch5에서 확인한 시작점은 다음 경로였다.
/sys/class/sensors/accelerometer_sensor
여기에서 sampling delay를 읽고 쓰는 함수는
show_acc_delay, set_acc_delay였다. 쓰기 요청은 change_sensor_delay로 넘어간다.change_sensor_delay
원문에서 추적한 핵심 호출은 다음과 같다.
send_instruction(data, CHANGE_DELAY, iSensorType, uBuf, 9);
uBuf에는 delay와 batch 관련 값이 byte 단위로 들어간다. 여기서 중요한 것은 sysfs 쓰기가 센서 register를 곧바로 건드리는 것이 아니라, CHANGE_DELAY라는 명령 packet으로 만들어진다는 점이었다.SSP로 들어간다
send_instruction은 drivers/sensorhub/slsi/ssp_comm.ko 쪽으로 이어졌다. 즉, accelerometer의 sampling rate를 바꾸는 명령은 일반 IIO 드라이버가 아니라 Samsung Sensor Platform 경로를 통과한다.발표자료에서 정리한 sysfs–SSP 흐름
Sensor Hub 밖으로 넘어가는 지점
계속 따라가자
drivers/sensorhub의 코드만으로 끝나지 않았다. drivers/staging/nanohub/chub_ipc_if.c까지 이어졌고, 최종적으로 다음 호출을 만났다.cipc_write_data(CIPC_REG_DATA_AP2CHUB, tx, length);
이 함수 이름 자체가 방향을 말하고 있었다. AP(Application Processor)에서 CHUB(Context Hub)로 data를 쓰는 경로다.
여기서 바뀐 질문
처음 질문은 “ODR register를 쓰는 kernel driver는 어디인가”였다. 이 지점부터 질문이 달라졌다.
AP가 만든 CHANGE_DELAY packet이 CIPC에서 어떤 memory와 mailbox를 거쳐 Sensor Hub firmware에 도착하는가?
이제 분석 대상은 한 개의 driver function이 아니라 AP와 CHUB 사이의 IPC, shared memory, Device Tree가 되었다.