From patchwork Sun Mar 31 10:07:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H. Nikolaus Schaller" X-Patchwork-Id: 10878699 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0435A139A for ; Sun, 31 Mar 2019 10:07:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DD46B286D6 for ; Sun, 31 Mar 2019 10:07:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D095528924; Sun, 31 Mar 2019 10:07:42 +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=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI 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 8D13D286D6 for ; Sun, 31 Mar 2019 10:07:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726772AbfCaKHk (ORCPT ); Sun, 31 Mar 2019 06:07:40 -0400 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.50]:23531 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726750AbfCaKHk (ORCPT ); Sun, 31 Mar 2019 06:07:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1554026858; s=strato-dkim-0002; d=goldelico.com; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=WWZalGAHQUHeT7WX3zQ1/dfR05CU96A7kCwVlJkXlOg=; b=sPNKZFI+fcu2wxb7oWmZn6XMkFF8fWxcyIdxNLosRYVxAOmbJcxtNk8TSXzUfNOwdw Lx6AjMrRFe+oRIT1YixkcHxvMEOtrpyIF+CrJ7EvjjkbkSaHgg7HrzZoUAcYgYP9p1zL qZV94G+O/cUl21dOKCj9F1XcJ7TPEls2gpAlSbAm5GKMunF1o1qWLGNsy322FjIxJMQE 1K+XiYgTlZsVnm7CkIkN9IHzeBtkgXwL5zMR/LLcxHKqIx5N1Kl3VrCHGys0rZTjo6fp 0FJC/pq3WLMkWG/s9gO8mjNGqTrWaqhTbTTBq0ja+kdkf9QrC3MNJJXpU6HsmqrDVnyd RRtg== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMhflhwDubTJ9o1OAA2UNf2AyPQjXtNgX" X-RZG-CLASS-ID: mo00 Received: from iMac.fritz.box by smtp.strato.de (RZmta 44.18 DYNA|AUTH) with ESMTPSA id K07648v2VA7OX1n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 31 Mar 2019 12:07:24 +0200 (CEST) From: "H. Nikolaus Schaller" To: =?utf-8?q?Beno=C3=AEt_Cousson?= , Tony Lindgren , Rob Herring , Mark Rutland , Linus Walleij , Bartosz Golaszewski Cc: linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, letux-kernel@openphoenux.org, "H. Nikolaus Schaller" Subject: [BUG/PATCH 1/4] DTS: GTA04: SPI / gpiolib: work around a regression that unhides a broken legacy handler, which makes the gta04 display inoperable Date: Sun, 31 Mar 2019 12:07:20 +0200 Message-Id: X-Mailer: git-send-email 2.19.1 In-Reply-To: References: MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This is an ugly workaround for a regression introduced into v5.1-rc1 by The GTA04 board uses a bitbanged SPI interface to control the LCD and it did work right from the introduction of the cs-gpios 5 years ago by but unexpectedly stopped with v5.1-rc1. Since we already use the gpio-flags for high level CS, we did not add spi-cs-high, which is listed in the bindings documentation as optional and indicative and not described as required to make it work. And it worked without this flag until now. Now the newly introduced patch to gpiolib-of.c removes a bug which prevented an ugly legacy handler for of SPI active high chip select to run. This now suddenly requires spi-cs-high to be defined in addition to the gpio flags. Trying to find a workaround in DTS shows that there seems to be another bug in the legacy handler code in gpiolib-of.c because it checks for the spi-cs-high flag not in the individual slave node (as one could expect from bindings documentation) but the spi controller node. Unfortunately it requires us to add legacy flags to a DTS to make the workaround code functioning. I would prefer that the workaround code and the spi-cs-high property is completely removed from gpiolib-of.c and all DTS which still use legacy gpio flags are fixed. fgrep spi-cs-high arch/*/boot/dts/*.dts* shows only a handful of board candidates. Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap3-gta04.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi index 04f2b53d4d3d..1e134dfab428 100644 --- a/arch/arm/boot/dts/omap3-gta04.dtsi +++ b/arch/arm/boot/dts/omap3-gta04.dtsi @@ -114,6 +114,7 @@ gpio-miso = <&gpio1 18 GPIO_ACTIVE_HIGH>; gpio-mosi = <&gpio1 20 GPIO_ACTIVE_HIGH>; cs-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; + spi-cs-high; /* make the legacy handler in gpiolib not intervene */ num-chipselects = <1>; /* lcd panel */ @@ -123,6 +124,7 @@ spi-max-frequency = <100000>; spi-cpol; spi-cpha; + spi-cs-high; /* here is where it should be but this is ignored by a bug in the gpiolib handler */ backlight= <&backlight>; label = "lcd";