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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
