From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751109AbdESIyp (ORCPT ); Fri, 19 May 2017 04:54:45 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:51276 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734AbdESIyn (ORCPT ); Fri, 19 May 2017 04:54:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 4656E601D9 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=architt@codeaurora.org Subject: Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes. To: Laurent Pinchart , Eric Anholt References: <20170511235625.22427-1-eric@anholt.net> <87shk4iqr7.fsf@eliezer.anholt.net> <3771766.1sVmoPRjsn@avalon> Cc: Rob Herring , dri-devel , Thierry Reding , Mark Rutland , Andrzej Hajda , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: Archit Taneja Message-ID: Date: Fri, 19 May 2017 14:24:36 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3771766.1sVmoPRjsn@avalon> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/18/2017 08:25 PM, Laurent Pinchart wrote: > Hi Archit, > > On Thursday 18 May 2017 13:56:19 Archit Taneja wrote: >> On 05/17/2017 12:16 AM, Eric Anholt wrote: > > [snip] > >>> In terms of physical connections: >>> [15-pin "DSI" connector on 2835] >>> >>> | I2C | DSI >>> >>> / \ SPI | >>> >>> [TS] [Atmel]------[TC358762] >>> >>> \ | >>> >>> \PWM | >>> >>> \ | DPI >>> >>> [some backlight]------[some unknown panel] >>> >>> The binding I'm trying to create is to expose what's necessary for a >>> driver that talks I2C to the Atmel, which then controls the PWM and does >>> the command sequence over SPI to the Toshiba that sets up its end of the >>> DSI link. >> >> The bridge (Atmel + TC358762 combination) here looks like it's primarily >> an i2c device (i.e, the control bus is i2c). Therefore, the drm-bridge >> driver here should be an i2c driver instead of a mipi_dsi_driver. > > Glad to see we agree, that's what I've proposed in a separate answer :-) I'd > go one step further though, there should be no DRM bridge, just a DRM panel. If the PCB containing the controller chips and the panel are part of a single casing, and the set up won't work with another panel, then yeah, I agree. If the bridge chips are on a separate adapter board, and there is a possibility to connect other panels, then maybe a separate DRM bridge and a DRM panel might be a safer bet. Thanks, Archit > >> We have the facility to create a mipi DSI device without the need to have >> a corresponding node in DT. The ADV7533 and TC358767 drivers are examples >> of that. >> >> The following is what the binding could look like, it's same as what Rob >> also mentioned previously in the thread. >> >> Thanks, >> Archit >> >> dsi1: dsi@7e700000 { >> #address-cells = <1>; >> #size-cells = <0>; >> <...> >> >> /* The SoC's DSI input/output port */ >> ports { >> #address-cells = <1>; >> #size-cells = <0>; >> >> /* port@0 if needed */ >> >> port@1 { >> dsi_out_port: endpoint { >> reg = <1>; >> remote-endpoint = <&bridge_dsi_port>; >> }; >> }; >> }; >> }; >> >> i2c_dsi: i2c { >> compatible = "i2c-gpio"; >> #address-cells = <1>; >> #size-cells = <0>; >> gpios = <&gpio 28 0 >> &gpio 29 0>; >> >> /* the Atmel + TC35872 bridge */ >> pitouchscreen_bridge: bridge@45 { > > This should thus be lcd@45. > >> compatible = "raspberrypi,touchscreen-bridge"; > > And this raspberrypi,7inch-touchscreen-panel. Shame we haven't standardized > the vendor name prefix to rpi :-/ > >> reg = <0x45>; >> >> ports { >> #address-cells = <1>; >> #size-cells = <0>; >> >> port@0 { >> reg = <0>; >> bridge_dsi_port: endpoint { > > This should be named panel_dsi_port. > >> remote-endpoint = <&dsi_out_port>; >> }; >> }; >> port@1 { >> reg = <1>; >> bridge_dpi_port: endpoint { >> remote-endpoint = > <&pitouchscreen_panel_port>; >> }; >> }; > > The second port is thus not needed. > >> }; > > So we can simplify this to > > port { > panel_dsi_port: endpoint { > remote-endpoint = <&dsi_out_port>; > }; > }; > > (no need for a ports node when there's a single port) > >> }; >> }; >> >> lcd { >> compatible = "raspberrypi,7inch-touchscreen-panel"; >> ports { >> #address-cells = <1>; >> #size-cells = <0>; >> port@0 { >> reg = <0>; >> pitouchscreen_panel_port: endpoint { >> remote-endpoint = <&bridge_dpi_port>; >> }; >> }; >> }; >> }; > > And this node can go away. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project