On 21/05/15 13:32, Sakari Ailus wrote: >>>> @@ -147,6 +149,8 @@ Example: >>>> > >> clocks = <&camera 0>; >>>> > >> clock-names = "mclk"; >>>> > >> >>>> > >>+ samsung,flash-led = <&rear_cam_flash>; >>>> > >>+ >>>> > >> port { >>>> > >> s5c73m3_1: endpoint { >>>> > >> data-lanes = <1 2 3 4>; >>> > > >>> > >Oops. I missed this property would have ended to the sensor's DT node. I >>> > >don't think we should have properties here that are parsed by another >>> > >driver --- let's discuss this tomorrow. >> > >> > exynos4-is driver already parses sensor nodes (at least their 'port' >> > sub-nodes). > > If you read the code and the comment, it looks like something that should be > done better but hasn't been done yet. :-) That's something we should avoid. > Also, flash devices are by far more common than external ISPs I presume.
Yes, especially let's not require any samsung specific properties in other vendors' sensor bindings. One way of modelling [flash led]/[image sensor] association I imagine would be to put, e.g. 'flash-leds' property in the SoC camera host interface/ISP DT node. This property would then contain pairs of phandles, first to the led node and the second to the sensor node, e.g. i2c_controller { ... flash_xx@NN { ... led_a { ... } }; image_sensor_x@NN { ... }; }; flash-leds = <&flash_xx &image_sensor_x>, <...>; For the purpose of this patch set presumably just samsung specific property name could be used (i.e. samsung,flash-leds). -- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html