질문 — 커널에 공개된 LSM6DSX IIO 드라이버가 Galaxy Watch5 가속도계의 실제 제어 경로인가?
왜 이 경로를 먼저 봤는가
Galaxy Watch5가 사용하는 IMU와 같은 계열의 드라이버가 커널 소스에 있었고, 그 안에는 ODR(Output Data Rate)을 설정하는 코드가 분명히 보였다. 처음에는 이 부분을 수정하면 센서 샘플링 레이트를 바꿀 수 있을 것이라고 생각했다.
내가 먼저 정리한 것은 함수 하나가 아니라, 드라이버가 장치를 등록하고 IIO 인터페이스에 연결되는 전체 흐름이었다.
구조체부터 연결했다
구조체 | 당시 분석한 역할 |
struct device | 커널의 일반 장치 객체 |
struct st_lsm6dsx_hw | LSM6DSX 하드웨어 전체 상태 |
struct iio_dev | IIO 장치 |
struct st_lsm6dsx_sensor | 가속도계·자이로 등 개별 센서 상태 |
st_lsm6dsx_probe()에서 하드웨어를 초기화하고, 각 센서를 IIO 장치로 등록하는 흐름을 따라갔다. 이후 사용자의 요청이 어떤 callback을 거쳐 실제 register write로 이어지는지도 추적했다.ODR table
원문에서 정리한 ODR 후보는 다음과 같았다.
13 Hz 26 Hz 52 Hz 104 Hz 208 Hz 416 Hz
중심 함수는
st_lsm6dsx_set_odr()였다. 이 함수가 요청한 주파수에 맞는 값을 찾고, 마지막에는 regmap_update_bits()로 register를 갱신한다.원문에서 그린 함수 호출 trace
callback까지 추적했다
iio_info와 buffer operation을 따라가면서 사용자가 sysfs 또는 IIO buffer를 통해 값을 바꿀 때 어떤 함수가 호출되는지 정리했다. 이때까지는 공개된 IIO 드라이버가 실제 제어 경로라는 가정 아래 분석했다.그런데 커널을 바꿔도 예상한 위치가 변하지 않았다
드라이버를 수정하고 커널을 빌드했지만, firmware의 kernel 영역에서 예상한 변화가 보이지 않았다. 여기서 여러 가능성을 세웠다.
- 이 드라이버가 built-in이 아니라
.ko로 들어갔을 가능성
- ramdisk나 별도 module 영역에 있을 가능성
- Device Tree 설정이 다른 드라이버를 선택할 가능성
- Galaxy Watch5의 실제 센서 경로가 이 공개 IIO 드라이버가 아닐 가능성
마지막 가능성이 이후 분석의 방향을 바꿨다. 실제 Watch5의 센서 명령은 일반 IIO 경로에서 끝나는 것이 아니라 Samsung Sensor Hub(SSP)를 통과하고 있었다.
이 분석은 틀린 경로를 오래 본 기록이기도 하다. 하지만 이 경로를 끝까지 확인했기 때문에, 커널의 공개 드라이버를 조금 고치는 것으로 끝나는 문제가 아니라는 것을 알 수 있었다. 지운 실패가 아니라 다음 대상을 좁힌 실패였다.