Hi, This series adds support for: * get_frame_sync(), so that we can pass the VCs and DTs from the incoming sensor streams over to the downstream drivers (CSI, ISI); * frame synchronization in multi-sensor setups. This one comes with some dt-bindings changes in order to allow the user to specify the incoming GPIO RX ID and the output pin; * operation mode override. This would allow toggling from the pin configured mode (for example: pixel mode) to the other one (tunneling mode). Also, vice versa is possible as well but the driver only supports tunneling mode currently; On the frame synchronization bindings, I would need some advice on the property naming. Recently, I sent a RFC adding support for MAX96724 deserializer chip, see [1], and I also added support for FSYNC for that chip. The max96724 property is also named "maxim,fsync-config" but, since the chip is a deserializer and it's the one actually sending the FSYNC signal, that property has an extra item: the fsync mode. My question is: would it be OK to have the same "maxim,fsync-config" property name for both or should we have different names? [1] https://patchwork.linuxtv.org/project/linux-media/list/?series=14427 Thanks, Laurentiu Laurentiu Palcu (5): media/i2c: max96717: change internal regulator voltage media/i2c: max96717: implement the .get_frame_desc() operation dt-bindings: i2c: maxim,max96717: add new properties media/i2c: max96717: add FSYNC support media/i2c: max96717: allow user to override operation mode from DT .../bindings/media/i2c/maxim,max96717.yaml | 28 ++++ drivers/media/i2c/max96717.c | 137 +++++++++++++++++- 2 files changed, 157 insertions(+), 8 deletions(-) -- 2.34.1
