Received: by 10.192.165.148 with SMTP id m20csp3336970imm; Mon, 23 Apr 2018 05:00:59 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/FfIlfDDRmTQmQOYyql6hUEnQgYA9ajE7myj+DDxYYafQji4KHrGSPGZQeseRQYm6M9avH X-Received: by 2002:a17:902:7201:: with SMTP id ba1-v6mr20087837plb.283.1524484859566; Mon, 23 Apr 2018 05:00:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524484859; cv=none; d=google.com; s=arc-20160816; b=iC4+gjVtCSbtAYWaLXM4rYnYZyBtoqhCeGPoKy/IvpdfhG00rKEh1oOSCxyRGLMoxh Uzvz2Ymt21pafxc0UmAs/V8co7NjK2UzrS/cChfjRf6lsMh4XdYFAXNMKPvEgrFjPVyi S9D8QvwGnh4swjJXoamzdCcZjV+DJ3stEqLCERagi8hb0egw/FR/Ud9uTYIGLxd40N9V 8d4618U0O/rPT0hLCKr8rn/lDTCNBM8PMI1bX61N21QK1apQNhyR8ac4P0o0T3fDLbe1 coiVYGbff+627zLTR0m/znat0WKfcspg38e/jAwKaHCU7FIM6gOD8N9TbobwjbQSUCmx u3OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from:dkim-signature:arc-authentication-results; bh=d6gh5zb6/Z4ZtrZbXKA2UCeYxML0f68Y77Xiw4BwPRM=; b=inflxzGptCGpM/zRA3ocA8nFEh1Yv+zS0w/ImHd3nEG5p3bKPgokJt5Ncspchz2M7E 1u9dgcKbokaQJMDGjwSxBwREgtDjq5fmiJXq8/wxCbTiHLKMCQ0Pu2RAKnurwk3kBdjP aYShs6W6ykcOa7VSJc4GCI6fr2CLyuww6BU/O0R3gcUj1bPWH2PIm4Q/ejJUiYupE6+I rZIJOOPf40qNXZJmN5cQgsQI9UILz5klaJqHpZcN1bv3xuHLdZYgG/3JB0grgy2QTmNv dLFXHx1fE0hf7Y80UriQiVN7+Y3QgRhq9OvdLGWAYwkhWuv4BnQgsZXGkLA6CdXgGGiN LN8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=grSx4vo5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t25si10644079pfh.101.2018.04.23.05.00.44; Mon, 23 Apr 2018 05:00:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=grSx4vo5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754984AbeDWL7b (ORCPT + 99 others); Mon, 23 Apr 2018 07:59:31 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:52086 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754746AbeDWL73 (ORCPT ); Mon, 23 Apr 2018 07:59:29 -0400 Received: from avalon.localnet (dfj612ybrt5fhg77mgycy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:2e86:4862:ef6a:2804]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7EEB6608D; Mon, 23 Apr 2018 13:59:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1524484767; bh=YS51zJ0lGfwlE0McCRDyHLSLj3XrlvdSl9+CL3FPvSs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=grSx4vo5Ijc84FHNZqi4livKMOqD4qqEbTugnNfOVLgFvxKySkQA06u/RyPj/plbQ nwspFwdQ+x73MRV5Gy+YFYkfum18vA0CNnFxYm7NjJBBZfCNv4bAuokHmR0tLEWePH ijdaBXmrRx9tTDR2m0o9io0weVwsJELuSkcwQeu4= From: Laurent Pinchart To: jacopo mondi Cc: Peter Rosin , Jacopo Mondi , architt@codeaurora.org, a.hajda@samsung.com, airlied@linux.ie, daniel@ffwll.ch, linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property Date: Mon, 23 Apr 2018 14:59:40 +0300 Message-ID: <4581508.09qg8X0yyC@avalon> Organization: Ideas on Board Oy In-Reply-To: <20180423073504.GN4235@w540> References: <1524130269-32688-1-git-send-email-jacopo+renesas@jmondi.org> <17d6f6b0-e657-4a5f-63a6-572cdf062bd3@axentia.se> <20180423073504.GN4235@w540> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jacopo, On Monday, 23 April 2018 10:35:04 EEST jacopo mondi wrote: > On Sun, Apr 22, 2018 at 10:02:41PM +0200, Peter Rosin wrote: > > On 2018-04-19 11:31, Jacopo Mondi wrote: > >> The THC63LVD1024 LVDS to RGB bridge supports two different input mapping > >> modes, selectable by means of an external pin. > >> > >> Describe the LVDS mode map through a newly defined mandatory property in > >> device tree bindings. > >> > >> Signed-off-by: Jacopo Mondi > >> --- > >> > >> .../devicetree/bindings/display/bridge/thine,thc63lvd1024.txt | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >> index 37f0c04..0937595 100644 > >> --- > >> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >> +++ > >> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >> @@ -12,6 +12,8 @@ Required properties: > >> - compatible: Shall be "thine,thc63lvd1024" > >> - vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS > >> input, > >> PPL and digital circuitry > >> > >> +- thine,map: LVDS mapping mode selection signal, pin name "MAP". Shall > >> be <1> > >> + for mapping mode 1, <0> for mapping mode 2 > > > > Since the MAP pin is an input pin, I would expect there to be an optional > > gpio specifier like thine,map-gpios so that the driver can set it > > according to the value given in thine,map in case the HW has a line from > > some gpio output to the MAP pin (instead of hardwired hi/low which seem > > to be your thinking). > > I see... As the only use case I had has the pin tied to vcc, I > thought about making it a binary property, and I wonder in how many > cases the chip 'MAP' pin would actually be GPIO controlled input and > not an hardwired one instead. I don't see the LVDS mapping mode to be > changed at runtime, but you are right, who knows.... > > Do you think we can add an options 'thine,map-gpios' property along > to the proposed ones? If the MAP pin is connected to an SoC-controlled GPIO for a given platform then we will likely need a thine,map-gpios property to control the pin. I think we can leave it out for now and add it later if the need arises. The thine,map property serves a different purpose, it indicates the level of the MAP pin for platforms where the pin is hardwired. If we later introduce a thine,map-gpios property it should be mutually exclusive with the thine,map property. The level of the MAP pin should be then software-controlled, not set through DT. > >> Optional properties: > >> - powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low > >> > >> @@ -36,6 +38,7 @@ Example: > >> vcc-supply = <®_lvds_vcc>; > >> powerdown-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; > >> + thine,map = <1>; > >> > >> ports { > >> #address-cells = <1>; -- Regards, Laurent Pinchart