From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63087C04AB4 for ; Fri, 17 May 2019 08:15:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3ADC320848 for ; Fri, 17 May 2019 08:15:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728742AbfEQIPN (ORCPT ); Fri, 17 May 2019 04:15:13 -0400 Received: from verein.lst.de ([213.95.11.211]:36068 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727386AbfEQIPN (ORCPT ); Fri, 17 May 2019 04:15:13 -0400 Received: by newverein.lst.de (Postfix, from userid 107) id 6C01068C4E; Fri, 17 May 2019 10:14:52 +0200 (CEST) Received: from blackhole.lan (p5B33F92B.dip0.t-ipconnect.de [91.51.249.43]) by newverein.lst.de (Postfix) with ESMTPSA id DBFF067329; Fri, 17 May 2019 10:14:19 +0200 (CEST) Date: Fri, 17 May 2019 10:14:18 +0200 From: Torsten Duwe To: Maxime Ripard Cc: Vasily Khoruzhick , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , Thierry Reding , Chen-Yu Tsai , Andrzej Hajda , Laurent Pinchart , Icenowy Zheng , Sean Paul , Harald Geyer , dri-devel , devicetree , arm-linux , linux-kernel Subject: Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I Message-ID: <20190517101353.3e86d696@blackhole.lan> In-Reply-To: <20190517072738.deohh5fly4jxms7k@flea> References: <20190514155911.6C0AC68B05@newverein.lst.de> <20190514160241.9EAC768C7B@newverein.lst.de> <20190515093141.41016b11@blackhole.lan> <20190516154820.GA10431@lst.de> <20190516164859.GB10431@lst.de> <20190517072738.deohh5fly4jxms7k@flea> Organization: LST e.V. X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 17 May 2019 09:27:38 +0200 Maxime Ripard wrote: > On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote: > > On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote: > > > > > > Driver can talk to the panel over AUX channel only after t1+t3, > > > t1 is up to 10ms, t3 is up to 200ms. > > > > This is after power-on. The boot loader needs to deal with this. > > The bootloader can deal with it, but the kernel will also need to. The > bootloader might not be doing this because it's not been updated, the > regulator might have been disabled between the time the kernel was > started and the time the bridge driver probes, etc. No, you cannot practically switch off this voltage. It supports _all_ the devices I mentioned. In fact, the PMIC needs to enable it initially, and then it takes some time before the SoC can access the MMC and read the SPL from it, just because of exactly these 3.3V. Then the boot loader starts, and later the eDP bridge gets initialised. In *theory*, albeit a very daring one, I could imagine a very deep sleep mode that can only be ended by pressing the power button, which should still work without DCDC1. Only then, a description of the panel would be required. But I probably missed something and even this does not work. So for all current practical purposes, we can assume the Teres-I panel to be powered properly and providing valid EDID; nothing to worry about in software. HTH, Torsten