From patchwork Tue Mar 7 08:56:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Ripard X-Patchwork-Id: 9608405 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BDAA660414 for ; Tue, 7 Mar 2017 09:29:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AAE5625D9E for ; Tue, 7 Mar 2017 09:29:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9F8AF284A5; Tue, 7 Mar 2017 09:29:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 55C5C25D9E for ; Tue, 7 Mar 2017 09:29:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754910AbdCGJ3k (ORCPT ); Tue, 7 Mar 2017 04:29:40 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:50849 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754964AbdCGJ32 (ORCPT ); Tue, 7 Mar 2017 04:29:28 -0500 Received: by mail.free-electrons.com (Postfix, from userid 110) id 7B50420BBB; Tue, 7 Mar 2017 09:56:56 +0100 (CET) Received: from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.free-electrons.com (Postfix) with ESMTPSA id 28AD3207D1; Tue, 7 Mar 2017 09:56:38 +0100 (CET) From: Maxime Ripard To: Mike Turquette , Stephen Boyd , Chen-Yu Tsai , Maxime Ripard Cc: dri-devel@lists.freedesktop.org, Daniel Vetter , David Airlie , Mark Rutland , Rob Herring , devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner, tcon-channel property Date: Tue, 7 Mar 2017 09:56:26 +0100 Message-Id: <46fdec2d680d539652f87d79c627973b3a568438.1488876832.git-series.maxime.ripard@free-electrons.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: References: In-Reply-To: References: Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The Allwinner Timings Controller has two, mutually exclusive, channels. When the binding has been introduced, it was assumed that there would be only a single user per channel in the system. While this is likely for the channel 0 which only connects to LCD displays, it turns out that the channel 1 can be connected to multiple controllers in the SoC (HDMI and TV encoders for example). And while the simultaneous use of HDMI and TV outputs cannot be achieved, switching from one to the other at runtime definitely sounds plausible. Add an extra property, allwinner,tcon-channel, to specify for a given endpoint which TCON channel it is connected to, while falling back to the previous mechanism if that property is missing. Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 11 ++++--- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 4b280672658e..18d445723c3e 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -68,10 +68,13 @@ Required properties: Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoint, the second one the output - The output should have two endpoints. The first is the block - connected to the TCON channel 0 (usually a panel or a bridge), the - second the block connected to the TCON channel 1 (usually the TV - encoder) + The output may have multiple endpoints. The TCON has two channels, + usually with the first channel being used for the panels interfaces + (RGB, LVDS, etc.), and the second being used for the outputs that + require another controller (TV Encoder, HDMI, etc.). The endpoints + will take an extra property, allwinner,tcon-channel, to specify the + channel the endpoint is associated to. If that property is not + present, the endpoint number will be used as the channel number. On SoCs other than the A33, there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1