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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 29E0CC4BA12 for ; Wed, 26 Feb 2020 15:08:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F279D2467D for ; Wed, 26 Feb 2020 15:08:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cGvEH4AG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F279D2467D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=znfEctKKRVhPwk/Cp4U85WW3V7haOmXKPJ8s578x//U=; b=cGvEH4AGFiaiDc NGuibfZXQmo0/YqQO/6RwnJ9fPgeGE/KYSpaxsFjppXFeHLTxM7+zHrRr7Dobk9S3jq7iDNC2WAL6 LkWPXhDjSmbZiuFZXY/3d6YJFwNS6UrsKt2kXK/tQSOSr5b6LBdG405alxadUYCVO0ggF6VYhZRx8 m/DVCd0SEnK/c7fN5FMl6/Gi1dpAiMwdWzSX1in3FRzRnsJstTHtLdqP760UECW7qOgsaIDWsL3Pw j1DtpRRHZbya86vTdy8wUG2vF+f0j3rkqA15H7GHUdIqhwfWBN0BPv4jbOA9VgqfSShuN+YPPy7PX fqvDGyxDOhADIrsrhM+w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j6yIe-0002p4-K9; Wed, 26 Feb 2020 15:08:36 +0000 Received: from mga09.intel.com ([134.134.136.24]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j6yIb-0002es-4G for linux-amlogic@lists.infradead.org; Wed, 26 Feb 2020 15:08:34 +0000 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 07:08:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,488,1574150400"; d="scan'208";a="350409339" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga001.fm.intel.com with SMTP; 26 Feb 2020 07:08:20 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 26 Feb 2020 17:08:19 +0200 Date: Wed, 26 Feb 2020 17:08:19 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Linus Walleij Subject: Re: Message-ID: <20200226150819.GK13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.intel.com> <20200226143409.GJ13686@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200226_070833_226138_6B3DF9F1 X-CRM114-Status: GOOD ( 28.50 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Josh Wu , Bhuvanchandra DV , Neil Armstrong , Eric Anholt , nouveau@lists.freedesktop.org, Guido =?iso-8859-1?Q?G=FCnther?= , Paul Kocialkowski , "open list:DRM PANEL DRIVERS" , Gustaf =?iso-8859-1?Q?Lindstr=F6m?= , Andrzej Hajda , Thierry Reding , Laurent Pinchart , Philipp Zabel , Sam Ravnborg , Marian-Cristian Rotariu , Jagan Teki , Thomas Hellstrom , Joonyoung Shim , Jonathan Marek , Stefan Mavrodiev , Adam Ford , Jerry Han , VMware Graphics , Ben Skeggs , "H. Nikolaus Schaller" , Robert Chiras , Heiko Schocher , Icenowy Zheng , Jonas Karlman , intel-gfx , Maxime Ripard , Alexandre Courbot , Fabio Estevam , "open list:ARM/Amlogic Meson..." , Vincent Abriou , Andreas Pretzsch , Jernej Skrabec , Alex Gonzalez , Purism Kernel Team , Boris Brezillon , Seung-Woo Kim , Christoph Fritz , Kyungmin Park , Heiko Stuebner , Eugen Hristev , Giulio Benetti Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 3:34 PM Ville Syrj=E4l=E4 > wrote: > > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj=E4l=E4 > > > wrote: > > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > > are not simple but contains a display controller and memory. > > > > > That means that the speed over the link to the display and > > > > > actual refresh rate on the actual display is asymmetric because > > > > > well we are just updating a RAM, the resolution just limits how > > > > > much data we are sending, the clock limits the speed on the > > > > > bus over to the RAM on the other side. > > > > > > > > IMO even in command mode mode->clock should probably be the actual > > > > dotclock used by the display. If there's another clock for the bus > > > > speed/etc. it should be stored somewhere else. > > > > > > Good point. For the DSI panels we have the field hs_rate > > > for the HS clock in struct mipi_dsi_device which is based > > > on exactly this reasoning. And that is what I actually use for > > > setting the HS clock. > > > > > > The problem is however that we in many cases have so > > > substandard documentation of these panels that we have > > > absolutely no idea about the dotclock. Maybe we should > > > just set it to 0 in these cases? > > > > Don't you always have a TE interrupt or something like that > > available? Could just measure it from that if no better > > information is available? > = > Yes and I did exactly that, so that is why this comment is in > the driver: > = > static const struct drm_display_mode sony_acx424akp_cmd_mode =3D { > (...) > /* > * Some desired refresh rate, experiments at the maximum "pixel" > * clock speed (HS clock 420 MHz) yields around 117Hz. > */ > .vrefresh =3D 60, > = > I got a review comment at the time saying 117 Hz was weird. > We didn't reach a proper conclusion on this: > https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uip= F7LM_DHZ5=3DLg@mail.gmail.com/ > = > Thierry wasn't sure if 60Hz was good or not, so I just had to > go with something. > = > We could calculate the resulting pixel clock for ~117 Hz with > this resolution and put that in the clock field but ... don't know > what is the best? I would vote for that approach. -- = Ville Syrj=E4l=E4 Intel _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: (no subject) Date: Wed, 26 Feb 2020 17:08:19 +0200 Message-ID: <20200226150819.GK13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.intel.com> <20200226143409.GJ13686@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Linus Walleij Cc: Josh Wu , Bhuvanchandra DV , Neil Armstrong , Eric Anholt , nouveau@lists.freedesktop.org, Guido =?iso-8859-1?Q?G=FCnther?= , "open list:DRM PANEL DRIVERS" , Gustaf =?iso-8859-1?Q?Lindstr=F6m?= , Andrzej Hajda , Laurent Pinchart , Philipp Zabel , Sam Ravnborg , Marian-Cristian Rotariu , Jagan Teki , Thomas Hellstrom , Joonyoung Shim , Jonathan Marek , Stefan Mavrodiev , Adam Ford , Jerry Han , VMware List-Id: nouveau.vger.kernel.org On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 3:34 PM Ville Syrj=E4l=E4 > wrote: > > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj=E4l=E4 > > > wrote: > > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > > are not simple but contains a display controller and memory. > > > > > That means that the speed over the link to the display and > > > > > actual refresh rate on the actual display is asymmetric because > > > > > well we are just updating a RAM, the resolution just limits how > > > > > much data we are sending, the clock limits the speed on the > > > > > bus over to the RAM on the other side. > > > > > > > > IMO even in command mode mode->clock should probably be the actual > > > > dotclock used by the display. If there's another clock for the bus > > > > speed/etc. it should be stored somewhere else. > > > > > > Good point. For the DSI panels we have the field hs_rate > > > for the HS clock in struct mipi_dsi_device which is based > > > on exactly this reasoning. And that is what I actually use for > > > setting the HS clock. > > > > > > The problem is however that we in many cases have so > > > substandard documentation of these panels that we have > > > absolutely no idea about the dotclock. Maybe we should > > > just set it to 0 in these cases? > > > > Don't you always have a TE interrupt or something like that > > available? Could just measure it from that if no better > > information is available? > = > Yes and I did exactly that, so that is why this comment is in > the driver: > = > static const struct drm_display_mode sony_acx424akp_cmd_mode =3D { > (...) > /* > * Some desired refresh rate, experiments at the maximum "pixel" > * clock speed (HS clock 420 MHz) yields around 117Hz. > */ > .vrefresh =3D 60, > = > I got a review comment at the time saying 117 Hz was weird. > We didn't reach a proper conclusion on this: > https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uip= F7LM_DHZ5=3DLg@mail.gmail.com/ > = > Thierry wasn't sure if 60Hz was good or not, so I just had to > go with something. > = > We could calculate the resulting pixel clock for ~117 Hz with > this resolution and put that in the clock field but ... don't know > what is the best? I would vote for that approach. -- = Ville Syrj=E4l=E4 Intel 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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 A319CC4BA12 for ; Wed, 26 Feb 2020 15:08:33 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 80E0E2467D for ; Wed, 26 Feb 2020 15:08:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 80E0E2467D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0B3476E2D6; Wed, 26 Feb 2020 15:08:33 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 26C166E2D6; Wed, 26 Feb 2020 15:08:32 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 07:08:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,488,1574150400"; d="scan'208";a="350409339" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga001.fm.intel.com with SMTP; 26 Feb 2020 07:08:20 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 26 Feb 2020 17:08:19 +0200 Date: Wed, 26 Feb 2020 17:08:19 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Linus Walleij Subject: Re: Message-ID: <20200226150819.GK13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.intel.com> <20200226143409.GJ13686@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Josh Wu , Bhuvanchandra DV , Neil Armstrong , nouveau@lists.freedesktop.org, Guido =?iso-8859-1?Q?G=FCnther?= , Paul Kocialkowski , "open list:DRM PANEL DRIVERS" , Gustaf =?iso-8859-1?Q?Lindstr=F6m?= , Andrzej Hajda , Thierry Reding , Laurent Pinchart , Sam Ravnborg , Marian-Cristian Rotariu , Jagan Teki , Thomas Hellstrom , Joonyoung Shim , Jonathan Marek , Stefan Mavrodiev , Adam Ford , Jerry Han , VMware Graphics , Ben Skeggs , "H. Nikolaus Schaller" , Robert Chiras , Heiko Schocher , Icenowy Zheng , Jonas Karlman , intel-gfx , Alexandre Courbot , "open list:ARM/Amlogic Meson..." , Vincent Abriou , Andreas Pretzsch , Jernej Skrabec , Alex Gonzalez , Purism Kernel Team , Boris Brezillon , Seung-Woo Kim , Christoph Fritz , Kyungmin Park , Heiko Stuebner , Eugen Hristev , Giulio Benetti Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 3:34 PM Ville Syrj=E4l=E4 > wrote: > > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj=E4l=E4 > > > wrote: > > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > > are not simple but contains a display controller and memory. > > > > > That means that the speed over the link to the display and > > > > > actual refresh rate on the actual display is asymmetric because > > > > > well we are just updating a RAM, the resolution just limits how > > > > > much data we are sending, the clock limits the speed on the > > > > > bus over to the RAM on the other side. > > > > > > > > IMO even in command mode mode->clock should probably be the actual > > > > dotclock used by the display. If there's another clock for the bus > > > > speed/etc. it should be stored somewhere else. > > > > > > Good point. For the DSI panels we have the field hs_rate > > > for the HS clock in struct mipi_dsi_device which is based > > > on exactly this reasoning. And that is what I actually use for > > > setting the HS clock. > > > > > > The problem is however that we in many cases have so > > > substandard documentation of these panels that we have > > > absolutely no idea about the dotclock. Maybe we should > > > just set it to 0 in these cases? > > > > Don't you always have a TE interrupt or something like that > > available? Could just measure it from that if no better > > information is available? > = > Yes and I did exactly that, so that is why this comment is in > the driver: > = > static const struct drm_display_mode sony_acx424akp_cmd_mode =3D { > (...) > /* > * Some desired refresh rate, experiments at the maximum "pixel" > * clock speed (HS clock 420 MHz) yields around 117Hz. > */ > .vrefresh =3D 60, > = > I got a review comment at the time saying 117 Hz was weird. > We didn't reach a proper conclusion on this: > https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uip= F7LM_DHZ5=3DLg@mail.gmail.com/ > = > Thierry wasn't sure if 60Hz was good or not, so I just had to > go with something. > = > We could calculate the resulting pixel clock for ~117 Hz with > this resolution and put that in the clock field but ... don't know > what is the best? I would vote for that approach. -- = Ville Syrj=E4l=E4 Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 66CB5C4BA12 for ; Wed, 26 Feb 2020 15:08:35 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 478102467D for ; Wed, 26 Feb 2020 15:08:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 478102467D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6B09C6E9A5; Wed, 26 Feb 2020 15:08:33 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 26C166E2D6; Wed, 26 Feb 2020 15:08:32 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 07:08:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,488,1574150400"; d="scan'208";a="350409339" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga001.fm.intel.com with SMTP; 26 Feb 2020 07:08:20 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 26 Feb 2020 17:08:19 +0200 Date: Wed, 26 Feb 2020 17:08:19 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Linus Walleij Message-ID: <20200226150819.GK13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.intel.com> <20200226143409.GJ13686@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [Intel-gfx] (no subject) X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Josh Wu , Bhuvanchandra DV , Neil Armstrong , Eric Anholt , nouveau@lists.freedesktop.org, Guido =?iso-8859-1?Q?G=FCnther?= , "open list:DRM PANEL DRIVERS" , Gustaf =?iso-8859-1?Q?Lindstr=F6m?= , Andrzej Hajda , Laurent Pinchart , Philipp Zabel , Sam Ravnborg , Marian-Cristian Rotariu , Jagan Teki , Thomas Hellstrom , Joonyoung Shim , Jonathan Marek , Stefan Mavrodiev , Adam Ford , Jerry Han , VMware Graphics , Ben Skeggs , "H. Nikolaus Schaller" , Robert Chiras , Heiko Schocher , Icenowy Zheng , Jonas Karlman , intel-gfx , Maxime Ripard , Alexandre Courbot , Fabio Estevam , "open list:ARM/Amlogic Meson..." , Vincent Abriou , Andreas Pretzsch , Jernej Skrabec , Alex Gonzalez , Purism Kernel Team , Boris Brezillon , Seung-Woo Kim , Christoph Fritz , Kyungmin Park , Heiko Stuebner , Eugen Hristev , Giulio Benetti Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 3:34 PM Ville Syrj=E4l=E4 > wrote: > > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj=E4l=E4 > > > wrote: > > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > > are not simple but contains a display controller and memory. > > > > > That means that the speed over the link to the display and > > > > > actual refresh rate on the actual display is asymmetric because > > > > > well we are just updating a RAM, the resolution just limits how > > > > > much data we are sending, the clock limits the speed on the > > > > > bus over to the RAM on the other side. > > > > > > > > IMO even in command mode mode->clock should probably be the actual > > > > dotclock used by the display. If there's another clock for the bus > > > > speed/etc. it should be stored somewhere else. > > > > > > Good point. For the DSI panels we have the field hs_rate > > > for the HS clock in struct mipi_dsi_device which is based > > > on exactly this reasoning. And that is what I actually use for > > > setting the HS clock. > > > > > > The problem is however that we in many cases have so > > > substandard documentation of these panels that we have > > > absolutely no idea about the dotclock. Maybe we should > > > just set it to 0 in these cases? > > > > Don't you always have a TE interrupt or something like that > > available? Could just measure it from that if no better > > information is available? > = > Yes and I did exactly that, so that is why this comment is in > the driver: > = > static const struct drm_display_mode sony_acx424akp_cmd_mode =3D { > (...) > /* > * Some desired refresh rate, experiments at the maximum "pixel" > * clock speed (HS clock 420 MHz) yields around 117Hz. > */ > .vrefresh =3D 60, > = > I got a review comment at the time saying 117 Hz was weird. > We didn't reach a proper conclusion on this: > https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uip= F7LM_DHZ5=3DLg@mail.gmail.com/ > = > Thierry wasn't sure if 60Hz was good or not, so I just had to > go with something. > = > We could calculate the resulting pixel clock for ~117 Hz with > this resolution and put that in the clock field but ... don't know > what is the best? I would vote for that approach. -- = Ville Syrj=E4l=E4 Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx