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 5D72CC4BA12 for ; Wed, 26 Feb 2020 14:34:35 +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 302372467D for ; Wed, 26 Feb 2020 14:34:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sWYsFimZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 302372467D 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=9sRvxjjJ1lQKDYQvBOEzsBikFGt6cTxcg0XFpMRmSow=; b=sWYsFimZTlpqJD 2HHLi13PqCye6ZKlmjfwirlaLvOysn50aebs6Epj37ao3XHDJ5unX0AOiBXOosoBWYcJv41ERmnAm nUlqgjySHjS+Rl/cUOmDAGGCyBe4xtzlUchSZWRe4IjUreE4x5qrufen1l/aDm6OrQO8vslqMHJ7J bb+NJv0VFNMMzj4fLp4XsKq1yqqHgaOGWXi+WQs/bbI8KBfgxqhi3vNvwQfiutADZ2tiFZ4BfSF9R +6ZuMngoWvG8fzUACkq/0Dzwq1YpSDuTIRIU0KDdzs7lBwOTVxy4Kj7MQVDDgYLvwONp9rWjEQ1T8 +lYuXC0SZpGrcnyLednw==; 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 1j6xla-00065f-7r; Wed, 26 Feb 2020 14:34:26 +0000 Received: from mga04.intel.com ([192.55.52.120]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j6xlX-00065L-JT for linux-amlogic@lists.infradead.org; Wed, 26 Feb 2020 14:34:24 +0000 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 06:34:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,488,1574150400"; d="scan'208";a="231416670" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga008.jf.intel.com with SMTP; 26 Feb 2020 06:34:08 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 26 Feb 2020 16:34:09 +0200 Date: Wed, 26 Feb 2020 16:34:09 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Linus Walleij Subject: Re: Message-ID: <20200226143409.GJ13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.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_063423_653325_CECD395D X-CRM114-Status: GOOD ( 18.82 ) 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 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? -- = 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 16:34:09 +0200 Message-ID: <20200226143409.GJ13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.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 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? -- = 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 293A1C4BA13 for ; Wed, 26 Feb 2020 14:34:26 +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 0BD932467D for ; Wed, 26 Feb 2020 14:34:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BD932467D 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 258056E9A3; Wed, 26 Feb 2020 14:34:25 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 640396E99B; Wed, 26 Feb 2020 14:34:23 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 06:34:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,488,1574150400"; d="scan'208";a="231416670" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga008.jf.intel.com with SMTP; 26 Feb 2020 06:34:08 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 26 Feb 2020 16:34:09 +0200 Date: Wed, 26 Feb 2020 16:34:09 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Linus Walleij Subject: Re: Message-ID: <20200226143409.GJ13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.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 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? -- = 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 0EFA4C4BA10 for ; Wed, 26 Feb 2020 14:34:25 +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 E239F2467D for ; Wed, 26 Feb 2020 14:34:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E239F2467D 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 96CF96E99D; Wed, 26 Feb 2020 14:34:24 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 640396E99B; Wed, 26 Feb 2020 14:34:23 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 06:34:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,488,1574150400"; d="scan'208";a="231416670" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga008.jf.intel.com with SMTP; 26 Feb 2020 06:34:08 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 26 Feb 2020 16:34:09 +0200 Date: Wed, 26 Feb 2020 16:34:09 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Linus Walleij Message-ID: <20200226143409.GJ13686@intel.com> References: <86d0ec$ae4ffc@fmsmga001.fm.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 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? -- = Ville Syrj=E4l=E4 Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx