Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1227394ybg; Wed, 29 Jul 2020 08:49:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOs3VOnkrHS8KMFMbW3u/Fj+FSJ3rHw0nP0Klo7Aj0ybuiV8w6MFg5kIGmULlhKua9o+Qf X-Received: by 2002:aa7:c450:: with SMTP id n16mr31059282edr.53.1596037756052; Wed, 29 Jul 2020 08:49:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596037756; cv=none; d=google.com; s=arc-20160816; b=RvEhD6XRCznzhf27FRzkQVcM9FAZhzUAjkL50End/f9WVtyDKqyJRxLGTFwg6ftwwx Bf4+6pryvyJd/qvTsD/7tMSWvk+E3JGF8+T88J9jYoicBdD0QpBJpRNl64l1U1gUjkrs nquw0/eeEqU/IPRIYE/UGhf5B9p0jGamcvabk6N3Ill9RyA9fqMbDomtD65mIpiTyL3D 19BavC//MN5FeGTU/QgItMEUD1qEY9FotPTJrg/rXQTFzhzMO/3cFBxI3OfC8d2ymfiM cMB2F9F4MHCwFK2VpnbEsKtaMDIG1xbY9IJqysjWfHzNe38M+pkYOlqGnAkCnLLkbtNi 6EOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:to :from:date; bh=ZK07GHzXCBnM/gZQd1xpyf9uu+jHzO3skmNAt9i9qFQ=; b=IBN74ST48Rxz9ClJbF3d/+0hZdlDIF0Naq9wzeaDxHxTsdcy0WNKFLXvK8L+IevjFZ poxSPfB0C6GZxwOrSXef6TMmS/dyBDOG0sgtZ0q6ur0WmKl0BPiIcYgC/jdIDbTKQNfn 69Z2kbG/TqAsszdLdVzUhFUuO1GTJCWio5HPe0/cd/kfs2NIdkVvPkGIuAp0ESBlBDL3 EGERgjjS9QogUlB3ddF7lo4qv41JPARThxYDy3TxS9AG23IXY5o11y16oCGSmEK2DsTA CTRn5fN+gsnp3QaZ6lmY0smouU+A/GprxifVrAFdUBFi4qDE0hVfky/wnr4KG4nIhRs9 eC9Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jp21si1424955ejb.136.2020.07.29.08.48.54; Wed, 29 Jul 2020 08:49:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726862AbgG2PsO (ORCPT + 99 others); Wed, 29 Jul 2020 11:48:14 -0400 Received: from honk.sigxcpu.org ([24.134.29.49]:46324 "EHLO honk.sigxcpu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726476AbgG2PsN (ORCPT ); Wed, 29 Jul 2020 11:48:13 -0400 Received: from localhost (localhost [127.0.0.1]) by honk.sigxcpu.org (Postfix) with ESMTP id 40641FB03; Wed, 29 Jul 2020 17:48:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at honk.sigxcpu.org Received: from honk.sigxcpu.org ([127.0.0.1]) by localhost (honk.sigxcpu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeLiyG1p29WJ; Wed, 29 Jul 2020 17:48:09 +0200 (CEST) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 1EBD845341; Wed, 29 Jul 2020 17:48:09 +0200 (CEST) Date: Wed, 29 Jul 2020 17:48:09 +0200 From: Guido =?iso-8859-1?Q?G=FCnther?= To: =?utf-8?Q?Ond=C5=99ej?= Jirman , David Airlie , Daniel Vetter , Thierry Reding , Sam Ravnborg , Fabio Estevam , Robert Chiras , Samuel Holland , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] Fix st7703 panel initialization failures Message-ID: <20200729154809.GA435075@bogon.m.sigxcpu.org> References: <20200716123753.3552425-1-megous@megous.com> <20200716140843.GA359122@bogon.m.sigxcpu.org> <20200716143209.ud6ote4q545bo2c7@core.my.home> <20200718173124.GA88021@bogon.m.sigxcpu.org> <20200718174215.mgjl3klytfa3nf3t@core.my.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200718174215.mgjl3klytfa3nf3t@core.my.home> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Sat, Jul 18, 2020 at 07:42:15PM +0200, Ondřej Jirman wrote: > Hello, > > On Sat, Jul 18, 2020 at 07:31:24PM +0200, Guido Günther wrote: > > Hi, > > On Thu, Jul 16, 2020 at 04:32:09PM +0200, Ondřej Jirman wrote: > > > Hi Guido, > > > > > > On Thu, Jul 16, 2020 at 04:08:43PM +0200, Guido Günther wrote: > > > > Hi Ondrej, > > > > On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote: > > > > > When extending the driver for xbd599 panel support I tried to do minimal > > > > > changes and keep the existing initialization timing. > > > > > > > > > > It turned out that it's not good enough and the existing init sequence > > > > > is too aggressive and doesn't follow the specification. On PinePhone > > > > > panel is being powered down/up during suspend/resume and with current > > > > > timings this frequently leads to corrupted display. > > > > > > > > Given the amount of ST7703 look alikes i don't think you can go by the > > > > datasheet and hope not to break other panels. The current sleeps cater > > > > for the rocktech panel (which suffered from similar issues you describe > > > > when we took other parameters) so you need to make those panel specific. > > > > > > It should work on rocktech too. The patch mostly increases/reorders the delays > > > slightly, to match the controller documentation. I don't see a reason to > > > complicate the driver with per panel special delays, unless these patches don't > > > work on your panel. > > > > That's why i brought it up. It breaks the rocktech panel on > > blank/unblank loops where it just stays blank and then starts hitting > > DSI command timeouts. > > Good to know. Does keeping the msleep(20); after init sequence and before sleep > exit make it work? We need both sleeps to make this work reliably so basically reverting your 'drm/panel: st7703: Make the sleep exit timing match the spec' makes things stable again. We don't need to sleep 120ms after sleep out though since our panel only requires 15ms as per data sheet there so it really makes sense to make these configurable. Cheers, -- Guido > > thank you and regards, > o. > > > Cheers, > > -- Guido > > > > > > > > The init sequence is still suboptimal, and doesn't follow the kernel docs > > > completely, even after these patches. Controller spec also talks about adding > > > some delay before enabling the backlight to avoid visual glitches. > > > > > > Which is what enable callback is documented to be for. Currently part of the > > > initialization that belongs to prepare callback is also done in enable callback. > > > > > > I see the glitch (small vertical shift of the image on powerup), but personally > > > don't care much to introduce even more delays to the driver, just for the > > > cosmetic issue. > > > > > > regards, > > > o. > > > > > > > Cheers, > > > > -- Guido > > > > > > > > > > > > > > This patch series fixes the problems. > > > > > > > > > > The issue was reported by Samuel Holland. > > > > > > > > > > Relevant screenshots from the datasheet: > > > > > > > > > > Power on timing: https://megous.com/dl/tmp/35b72e674ce0ca27.png > > > > > Power off timing: https://megous.com/dl/tmp/dea195517106ff17.png > > > > > More optimal reset on poweron: https://megous.com/dl/tmp/a9e5caf14e1b0dc6.png > > > > > Less optimal reset on poweron: https://megous.com/dl/tmp/246761039283c4cf.png > > > > > Datasheet: https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > > > > > > > > > > Please take a look. > > > > > > > > > > thank you and regards, > > > > > Ondrej Jirman > > > > > > > > > > Ondrej Jirman (2): > > > > > drm/panel: st7703: Make the sleep exit timing match the spec > > > > > drm/panel: st7703: Fix the power up sequence of the panel > > > > > > > > > > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 29 ++++++++++--------- > > > > > 1 file changed, 15 insertions(+), 14 deletions(-) > > > > > > > > > > -- > > > > > 2.27.0 > > > > > > > > >