Hi Jacek,
On Wed, May 20, 2015 at 04:10:15PM +0200, Jacek Anaszewski wrote:
> This patch adds examples for samsung,flash-led property to the
> samsung-fimc.txt.
>
> Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
> Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
> Cc: devicet...@vger.kernel.org
> ---
> .../devicetree/bindings/media/samsung-fimc.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> index 922d6f8..57edffa 100644
> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> @@ -126,6 +126,8 @@ Example:
> clocks = <&camera 1>;
> clock-names = "mclk";
>
> + samsung,flash-led = <&front_cam_flash>;
> +
> port {
> s5k6aa_ep: endpoint {
> remote-endpoint = <&fimc0_ep>;
> @@ -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.
There are two main options that I can think of --- either put the property
under the bridge (ISP) driver's device node as a temporary solution that
works on a few ISP drivers, or think how sensor modules should be modelled,
in which case we'd have some idea how lens device would be taken into
account.
Cc Sebastian.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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
