From patchwork Thu Jun 16 09:36:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 9180261 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 43FB960760 for ; Thu, 16 Jun 2016 09:36:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 356122705B for ; Thu, 16 Jun 2016 09:36:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2A47528308; Thu, 16 Jun 2016 09:36:43 +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.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham 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 BAFC62705B for ; Thu, 16 Jun 2016 09:36:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752713AbcFPJgm (ORCPT ); Thu, 16 Jun 2016 05:36:42 -0400 Received: from mail-lf0-f53.google.com ([209.85.215.53]:35380 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752217AbcFPJgl (ORCPT ); Thu, 16 Jun 2016 05:36:41 -0400 Received: by mail-lf0-f53.google.com with SMTP id l188so34324795lfe.2 for ; Thu, 16 Jun 2016 02:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=PDCVFa+D1xTDIwtSiM7L1x51xv6+5M33JHKvehaBNfc=; b=UFT0EPhMYYs/3ordkq+kmnz1vvqerENQeT7J00wtqLclxsVZ1GnHU18z8qZYEGFD/m KqfBA5Ztrkg9rcvmZwoGze54+Nym5y8WOD4/THh0oHuz4qQuFv8o0VfmGgEJeXG/2y2b TEOOSiVV0Rp6VK4vNUeCRoAxhCtFMkS9AiUGE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=PDCVFa+D1xTDIwtSiM7L1x51xv6+5M33JHKvehaBNfc=; b=dKVfbSJ5sPK9g5WrVVwNl+/A2Q4i8i0Svc4IIa2oDVEOMDShTM8trraBpdHUi1H/pN hMkwqHZd+OKBtOmd7UezoJhHfezUv0/G6kVq7kMKNlic7cJutEAkAWpy/6WnZRFu1wSo JQAtcOpeU/wF7OZdUT5nu+9yn8s7eScZrtGeVHrLWs8KcDQCx3mp0BbftJIYYxSYq7cx Xq7p4ZOZ9dkTOx3uM1UQolKhsYUGhqJvT9lS176MXfwKFjYS7rrMFAqXWw2zuFW8f1e6 Q5iG8EYuKoYloZmyByQxGzOd4yTSIPO+5vYtZpjbTnQWWcWbInQ/GoUztTgwCI4eI+/F hsAg== X-Gm-Message-State: ALyK8tJfzQ297axYInc+P/JtO3FTpZYYTiMklr2HNzQkKNaBRI+q6ATlyoGb5hKLXlt6xXwh X-Received: by 10.25.44.148 with SMTP id s142mr1016449lfs.146.1466069799618; Thu, 16 Jun 2016 02:36:39 -0700 (PDT) Received: from localhost.localdomain.localdomain (c-cc7c71d5.014-348-6c756e10.cust.bredbandsbolaget.se. [213.113.124.204]) by smtp.gmail.com with ESMTPSA id d8sm1884006lbc.29.2016.06.16.02.36.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jun 2016 02:36:38 -0700 (PDT) From: Linus Walleij To: linux-fbdev@vger.kernel.org, Tomi Valkeinen , Jean-Christophe Plagniol-Villard , Pawel Moll , Rob Herring , Russell King Cc: linux-arm-kernel@lists.infradead.org, Arnd Bergmann , Ray Jui , Linus Walleij Subject: [PATCH 3/6] video: ARM CLCD: support pads connected in reverse order Date: Thu, 16 Jun 2016 11:36:15 +0200 Message-Id: <1466069778-16087-4-git-send-email-linus.walleij@linaro.org> X-Mailer: git-send-email 2.4.11 In-Reply-To: <1466069778-16087-1-git-send-email-linus.walleij@linaro.org> References: <1466069778-16087-1-git-send-email-linus.walleij@linaro.org> Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There are CLCDs connected with the pads in BGR rather than RGB order. It really doesn't matter since the CLCD has a flag and a bit to switch the position of the RGB and BGR components. This is needed to put something logical into the arm,pl11x,tft-r0g0b0-pads property of the device tree on the Nomadik which will then be <16 8 0>. Cc: Pawel Moll Cc: Rob Herring Cc: Russell King Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Russell noted that we could collapse two &=/|= operations into a single ^= and save some arithmetics. ChangeLog v1->v2: - No changes --- drivers/video/fbdev/amba-clcd.c | 8 ++++++++ include/linux/amba/clcd.h | 18 +++++++++++++++--- 2 files changed, 23 insertions(+), 3 deletions(-) diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c index 5bd20e8800bc..080e8a246faf 100644 --- a/drivers/video/fbdev/amba-clcd.c +++ b/drivers/video/fbdev/amba-clcd.c @@ -675,6 +675,7 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0) } panels[] = { { 0x110, 1, 7, 13, CLCD_CAP_5551 }, { 0x110, 0, 8, 16, CLCD_CAP_888 }, + { 0x110, 16, 8, 0, CLCD_CAP_888 }, { 0x111, 4, 14, 20, CLCD_CAP_444 }, { 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 }, { 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 | @@ -702,6 +703,13 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0) fb->panel->caps = panels[i].caps; } + /* + * If we actually physically connected the R lines to B and + * vice versa + */ + if (r0 != 0 && b0 == 0) + fb->panel->bgr_connection = true; + return fb->panel->caps ? 0 : -EINVAL; } diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h index e64c1ccebb76..8b64ec0d574b 100644 --- a/include/linux/amba/clcd.h +++ b/include/linux/amba/clcd.h @@ -108,6 +108,12 @@ struct clcd_panel { grayscale:1; unsigned int connector; struct backlight_device *backlight; + /* + * If the B/R lines are switched between the CLCD + * and the panel we need to know this and not try to + * compensate with the BGR bit in the control register. + */ + bool bgr_connection; }; struct clcd_regs { @@ -234,16 +240,22 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs) if (var->grayscale) val |= CNTL_LCDBW; - if (fb->panel->caps && fb->board->caps && - var->bits_per_pixel >= 16) { + if (fb->panel->caps && fb->board->caps && var->bits_per_pixel >= 16) { /* * if board and panel supply capabilities, we can support - * changing BGR/RGB depending on supplied parameters + * changing BGR/RGB depending on supplied parameters. Here + * we switch to what the framebuffer is providing if need + * be, so if the framebuffer is BGR but the display connection + * is RGB (first case) we switch it around. Vice versa mutatis + * mutandis if the framebuffer is RGB but the display connection + * is BGR, we flip it around. */ if (var->red.offset == 0) val &= ~CNTL_BGR; else val |= CNTL_BGR; + if (fb->panel->bgr_connection) + val ^= CNTL_BGR; } switch (var->bits_per_pixel) {