Re: [Intel-gfx] (no subject)

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Josh Wu" <josh.wu@atmel.com>,
	"Bhuvanchandra DV" <bhuvanchandra.dv@toradex.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Eric Anholt" <eric@anholt.net>,
	nouveau@lists.freedesktop.org, "Guido Günther" <agx@sigxcpu.org>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	"Gustaf Lindström" <gl@axentia.se>,
	"Andrzej Hajda" <a.hajda@samsung.com>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Philipp Zabel" <philipp.zabel@gmail.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Marian-Cristian Rotariu"
	<marian-cristian.rotariu.rb@bp.renesas.com>,
	"Jagan Teki" <jagan@amarulasolutions.com>,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"Joonyoung Shim" <jy0922.shim@samsung.com>,
	"Jonathan Marek" <jonathan@marek.ca>,
	"Stefan Mavrodiev" <stefan@olimex.com>,
	"Adam Ford" <aford173@gmail.com>,
	"Jerry Han" <hanxu5@huaqin.corp-partner.google.com>,
	"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"H. Nikolaus Schaller" <hns@goldelico.com>,
	"Robert Chiras" <robert.chiras@nxp.com>,
	"Heiko Schocher" <hs@denx.de>, "Icenowy Zheng" <icenowy@aosc.io>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Fabio Estevam" <festevam@gmail.com>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"Vincent Abriou" <vincent.abriou@st.com>,
	"Andreas Pretzsch" <apr@cn-eng.de>,
	"Jernej Skrabec" <jernej.skrabec@siol.net>,
	"Alex Gonzalez" <alex.gonzalez@digi.com>,
	"Purism Kernel Team" <kernel@puri.sm>,
	"Boris Brezillon" <bbrezillon@kernel.org>,
	"Seung-Woo Kim" <sw0312.kim@samsung.com>,
	"Christoph Fritz" <chf.fritz@googlemail.com>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Heiko Stuebner" <heiko.stuebner@theobroma-systems.com>,
	"Eugen Hristev" <eugen.hristev@microchip.com>,
	"Giulio Benetti" <giulio.benetti@micronovasrl.com>
Subject: Re: [Intel-gfx] (no subject)
Date: Wed, 26 Feb 2020 16:34:09 +0200	[thread overview]
Message-ID: <20200226143409.GJ13686@intel.com> (raw)
In-Reply-To: <CACRpkdZ4H5fdWsxsXnsbyxb6fwKbgm0h5a6CdqEjU9w5+z0a7Q@mail.gmail.com>

On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> 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älä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx