From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753600AbcFJWJR (ORCPT ); Fri, 10 Jun 2016 18:09:17 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:36065 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753023AbcFJWJL convert rfc822-to-8bit (ORCPT ); Fri, 10 Jun 2016 18:09:11 -0400 MIME-Version: 1.0 In-Reply-To: References: <1465578127-30330-1-git-send-email-dianders@chromium.org> From: =?UTF-8?Q?St=C3=A9phane_Marchesin?= Date: Fri, 10 Jun 2016 15:08:50 -0700 X-Google-Sender-Auth: BzffRl9wEbjV7s6CDDWtlqgljSs Message-ID: Subject: Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding To: Rob Clark Cc: Doug Anderson , Thierry Reding , Mark Rutland , "devicetree@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , Rob Herring Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 10, 2016 at 3:03 PM, Rob Clark wrote: > On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson wrote: >> Rob, >> >> On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark wrote: >>> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson wrote: >>>> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected >>>> using eDP interfaces. >>> >>> so drive-by comment... but shouldn't eDP be probe-able? Not sure why >>> we need panel drivers or DT bindings? >> >> I was wondering about that too. As far as I can tell: >> >> 1. We need a panel driver because that appears to be what owns a >> reference to the backlight / panel power regulator and that part is >> not auto-probable. > > oh, hmm.. sad.. I was hoping that eDP would save us from dsi per-panel > driver hell.. I guess being able to use panel-simple is at least an > improvement. But panel specific sequences is sounds like panel-simple > won't save us all the time :-( Yes, although you can probably make things mostly work with improper sequencing and enough retries, a lot of ARM hw either requires interesting sequencing, or has broken/unreliable DDC, which translates into the use of panel simple on the sw side. > >> 2. As far as I could tell, there is no way to declare a generic >> (unspecified) panel in the device tree. Everyone seems to include >> "simple-panel" in their compatible string but as far as I can tell >> nothing in the kernel looks at it. >> >> 3. In theory, all the info specified here should match the EDID >> exactly and thus (as you said) be probable. However, it sounds like >> (for power sequencing reasons) there might be reasons why you'd want >> to know exactly what panel was present beforehand. You might need to >> power the panel and backlight in very specific sequences, for >> instance. I'm not sure it's always 100% possible in all embedded >> designs to read the EDID before you know how the sequencing should >> work (but, of course, I'm a NOOB). >> >> 4. Reading the EDID can be slow. If you happen to know all the info >> on the panel beforehand you can significantly speed up boot speed, >> notably how fast you can get something on the screen. > > The theory is (although I think not true currently for most of the arm > drivers) that we should be reading back from hw the current config > from bootloader splash screen, to avoid a modeset (and conveniently > also the need to read edid) at boot. On some devices the firmware doesn't set any video mode, so there isn't anything we can read back. That is our case :) Stéphane > > BR, > -R > >> >> Anyway, maybe someone else who actually knows what they're talking >> about will chime in. ;) >> >> -Doug