All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
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>
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 22:52:25 +0100	[thread overview]
Message-ID: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com> (raw)
In-Reply-To: <20200225192720.GG13686@intel.com>

On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:

> OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.

That's impressive :D

> Unfortunately it found a lot of strange stuff:

I will answer for the weirdness I caused.

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.

In most cases I thing the clock is the way to go.

> panel-sony-acx424akp.c:51/sony_acx424akp_vid_mode: 60 vs. 727 (.clock=330000 .htotal=480 + 15 + 0 + 15 .vtotal=864 + 14 + 1 + 11)

I suspect clock should be adjusted after vfresh = 60 here instead of the
other way around. I couldn't quite test the video mode, but the vendor
driver (no documentation ....) does state 330 MHz which seems a
bit high.

Just drop vrefresh for now.

> panel-sony-acx424akp.c:71/sony_acx424akp_cmd_mode: 60 vs. 711 (.clock=420160 .htotal=480 + 154 + 16 + 32 .vtotal=864 + 1 + 1 + 1)

You can override this ignoring the vrefresh, this is a command-mode
only, and in command mode the refresh doesn't come into play, or is
very high and limited by a bunch of other overhead than just the
resolution. The command mode HS clock is @420+ MHz indeed.
Tests showed around 116 Hz for this particular display in practice
with continuous updates.

> panel-ilitek-ili9322.c:543/srgb_320x240_mode: 60 vs. 10168 (.clock=2453500 .htotal=320 + 359 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:587/yuv_640x320_mode: 60 vs. 7768 (.clock=2454000 .htotal=640 + 252 + 1 + 28 .vtotal=320 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:616/itu_r_bt_656_640_mode: 60 vs. 5358 (.clock=2454000 .htotal=640 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:557/srgb_360x240_mode: 60 vs. 16178 (.clock=2700000 .htotal=360 + 35 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:601/yuv_720x360_mode: 60 vs. 7071 (.clock=2700000 .htotal=720 + 252 + 1 + 24 .vtotal=360 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:631/itu_r_bt_656_720_mode: 60 vs. 5422 (.clock=2700000 .htotal=720 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:572/prgb_320x240_mode: 60 vs. 59725 (.clock=6400000 .htotal=320 + 38 + 1 + 50 .vtotal=262)

This is the datasheet if you want to take a look:
https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf

The one platform using this is using the
8 bit ITU-R BT.656 640Y 320CbCr mode which
(I think) is similar to DSI command mode again: there is a stream
of data in a burst and you decide how often you want to send it
because the panel always has backing memory and the
speed out to the physical display is something completely
different.

You can safely delete vrefresh from all of these sites.

> panel-arm-versatile.c:161/versatile_panels[]: 60 vs. 61 (.clock=25000 .htotal=640 + 24 + 96 + 24 .vtotal=480 + 11 + 2 + 32)
> panel-arm-versatile.c:208/versatile_panels[]: 116 vs. 59 (.clock=5400 .htotal=240 + 10 + 10 + 20 .vtotal=320 + 2 + 2 + 2)
> panel-arm-versatile.c:184/versatile_panels[]: 390 vs. 1523 (.clock=62500 .htotal=176 + 2 + 3 + 3 .vtotal=220 + 0 + 2 + 1)

The only driver  drivers/gpu/drm/pl111/pl111_display.c
Uses mode->clock so just drop vrefresh.

Yours,
Linus Walleij
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: "Josh Wu" <josh.wu@atmel.com>,
	"Bhuvanchandra DV" <bhuvanchandra.dv@toradex.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	nouveau@lists.freedesktop.org, "Guido Günther" <agx@sigxcpu.org>,
	"Paul Kocialkowski" <contact@paulk.fr>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	"Gustaf Lindström" <gl@axentia.se>,
	"Andrzej Hajda" <a.hajda@samsung.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.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>,
	"Randy Li" <ayaka@soulik.info>,
	"Alexandre Courbot" <acourbot@nvidia.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: [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 22:52:25 +0100	[thread overview]
Message-ID: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com> (raw)
In-Reply-To: <20200225192720.GG13686@intel.com>

On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:

> OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.

That's impressive :D

> Unfortunately it found a lot of strange stuff:

I will answer for the weirdness I caused.

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.

In most cases I thing the clock is the way to go.

> panel-sony-acx424akp.c:51/sony_acx424akp_vid_mode: 60 vs. 727 (.clock=330000 .htotal=480 + 15 + 0 + 15 .vtotal=864 + 14 + 1 + 11)

I suspect clock should be adjusted after vfresh = 60 here instead of the
other way around. I couldn't quite test the video mode, but the vendor
driver (no documentation ....) does state 330 MHz which seems a
bit high.

Just drop vrefresh for now.

> panel-sony-acx424akp.c:71/sony_acx424akp_cmd_mode: 60 vs. 711 (.clock=420160 .htotal=480 + 154 + 16 + 32 .vtotal=864 + 1 + 1 + 1)

You can override this ignoring the vrefresh, this is a command-mode
only, and in command mode the refresh doesn't come into play, or is
very high and limited by a bunch of other overhead than just the
resolution. The command mode HS clock is @420+ MHz indeed.
Tests showed around 116 Hz for this particular display in practice
with continuous updates.

> panel-ilitek-ili9322.c:543/srgb_320x240_mode: 60 vs. 10168 (.clock=2453500 .htotal=320 + 359 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:587/yuv_640x320_mode: 60 vs. 7768 (.clock=2454000 .htotal=640 + 252 + 1 + 28 .vtotal=320 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:616/itu_r_bt_656_640_mode: 60 vs. 5358 (.clock=2454000 .htotal=640 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:557/srgb_360x240_mode: 60 vs. 16178 (.clock=2700000 .htotal=360 + 35 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:601/yuv_720x360_mode: 60 vs. 7071 (.clock=2700000 .htotal=720 + 252 + 1 + 24 .vtotal=360 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:631/itu_r_bt_656_720_mode: 60 vs. 5422 (.clock=2700000 .htotal=720 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:572/prgb_320x240_mode: 60 vs. 59725 (.clock=6400000 .htotal=320 + 38 + 1 + 50 .vtotal=262)

This is the datasheet if you want to take a look:
https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf

The one platform using this is using the
8 bit ITU-R BT.656 640Y 320CbCr mode which
(I think) is similar to DSI command mode again: there is a stream
of data in a burst and you decide how often you want to send it
because the panel always has backing memory and the
speed out to the physical display is something completely
different.

You can safely delete vrefresh from all of these sites.

> panel-arm-versatile.c:161/versatile_panels[]: 60 vs. 61 (.clock=25000 .htotal=640 + 24 + 96 + 24 .vtotal=480 + 11 + 2 + 32)
> panel-arm-versatile.c:208/versatile_panels[]: 116 vs. 59 (.clock=5400 .htotal=240 + 10 + 10 + 20 .vtotal=320 + 2 + 2 + 2)
> panel-arm-versatile.c:184/versatile_panels[]: 390 vs. 1523 (.clock=62500 .htotal=176 + 2 + 3 + 3 .vtotal=220 + 0 + 2 + 1)

The only driver  drivers/gpu/drm/pl111/pl111_display.c
Uses mode->clock so just drop vrefresh.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
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>,
	"Randy Li" <ayaka@soulik.info>,
	"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] [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 22:52:25 +0100	[thread overview]
Message-ID: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com> (raw)
In-Reply-To: <20200225192720.GG13686@intel.com>

On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:

> OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.

That's impressive :D

> Unfortunately it found a lot of strange stuff:

I will answer for the weirdness I caused.

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.

In most cases I thing the clock is the way to go.

> panel-sony-acx424akp.c:51/sony_acx424akp_vid_mode: 60 vs. 727 (.clock=330000 .htotal=480 + 15 + 0 + 15 .vtotal=864 + 14 + 1 + 11)

I suspect clock should be adjusted after vfresh = 60 here instead of the
other way around. I couldn't quite test the video mode, but the vendor
driver (no documentation ....) does state 330 MHz which seems a
bit high.

Just drop vrefresh for now.

> panel-sony-acx424akp.c:71/sony_acx424akp_cmd_mode: 60 vs. 711 (.clock=420160 .htotal=480 + 154 + 16 + 32 .vtotal=864 + 1 + 1 + 1)

You can override this ignoring the vrefresh, this is a command-mode
only, and in command mode the refresh doesn't come into play, or is
very high and limited by a bunch of other overhead than just the
resolution. The command mode HS clock is @420+ MHz indeed.
Tests showed around 116 Hz for this particular display in practice
with continuous updates.

> panel-ilitek-ili9322.c:543/srgb_320x240_mode: 60 vs. 10168 (.clock=2453500 .htotal=320 + 359 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:587/yuv_640x320_mode: 60 vs. 7768 (.clock=2454000 .htotal=640 + 252 + 1 + 28 .vtotal=320 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:616/itu_r_bt_656_640_mode: 60 vs. 5358 (.clock=2454000 .htotal=640 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:557/srgb_360x240_mode: 60 vs. 16178 (.clock=2700000 .htotal=360 + 35 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:601/yuv_720x360_mode: 60 vs. 7071 (.clock=2700000 .htotal=720 + 252 + 1 + 24 .vtotal=360 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:631/itu_r_bt_656_720_mode: 60 vs. 5422 (.clock=2700000 .htotal=720 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:572/prgb_320x240_mode: 60 vs. 59725 (.clock=6400000 .htotal=320 + 38 + 1 + 50 .vtotal=262)

This is the datasheet if you want to take a look:
https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf

The one platform using this is using the
8 bit ITU-R BT.656 640Y 320CbCr mode which
(I think) is similar to DSI command mode again: there is a stream
of data in a burst and you decide how often you want to send it
because the panel always has backing memory and the
speed out to the physical display is something completely
different.

You can safely delete vrefresh from all of these sites.

> panel-arm-versatile.c:161/versatile_panels[]: 60 vs. 61 (.clock=25000 .htotal=640 + 24 + 96 + 24 .vtotal=480 + 11 + 2 + 32)
> panel-arm-versatile.c:208/versatile_panels[]: 116 vs. 59 (.clock=5400 .htotal=240 + 10 + 10 + 20 .vtotal=320 + 2 + 2 + 2)
> panel-arm-versatile.c:184/versatile_panels[]: 390 vs. 1523 (.clock=62500 .htotal=176 + 2 + 3 + 3 .vtotal=220 + 0 + 2 + 1)

The only driver  drivers/gpu/drm/pl111/pl111_display.c
Uses mode->clock so just drop vrefresh.

Yours,
Linus Walleij
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
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>,
	"Paul Kocialkowski" <contact@paulk.fr>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	"Gustaf Lindström" <gl@axentia.se>,
	"Andrzej Hajda" <a.hajda@samsung.com>,
	"Thierry Reding" <thierry.reding@gmail.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>,
	"Randy Li" <ayaka@soulik.info>,
	"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: [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 22:52:25 +0100	[thread overview]
Message-ID: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com> (raw)
In-Reply-To: <20200225192720.GG13686@intel.com>

On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:

> OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.

That's impressive :D

> Unfortunately it found a lot of strange stuff:

I will answer for the weirdness I caused.

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.

In most cases I thing the clock is the way to go.

> panel-sony-acx424akp.c:51/sony_acx424akp_vid_mode: 60 vs. 727 (.clock=330000 .htotal=480 + 15 + 0 + 15 .vtotal=864 + 14 + 1 + 11)

I suspect clock should be adjusted after vfresh = 60 here instead of the
other way around. I couldn't quite test the video mode, but the vendor
driver (no documentation ....) does state 330 MHz which seems a
bit high.

Just drop vrefresh for now.

> panel-sony-acx424akp.c:71/sony_acx424akp_cmd_mode: 60 vs. 711 (.clock=420160 .htotal=480 + 154 + 16 + 32 .vtotal=864 + 1 + 1 + 1)

You can override this ignoring the vrefresh, this is a command-mode
only, and in command mode the refresh doesn't come into play, or is
very high and limited by a bunch of other overhead than just the
resolution. The command mode HS clock is @420+ MHz indeed.
Tests showed around 116 Hz for this particular display in practice
with continuous updates.

> panel-ilitek-ili9322.c:543/srgb_320x240_mode: 60 vs. 10168 (.clock=2453500 .htotal=320 + 359 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:587/yuv_640x320_mode: 60 vs. 7768 (.clock=2454000 .htotal=640 + 252 + 1 + 28 .vtotal=320 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:616/itu_r_bt_656_640_mode: 60 vs. 5358 (.clock=2454000 .htotal=640 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:557/srgb_360x240_mode: 60 vs. 16178 (.clock=2700000 .htotal=360 + 35 + 1 + 241 .vtotal=262)
> panel-ilitek-ili9322.c:601/yuv_720x360_mode: 60 vs. 7071 (.clock=2700000 .htotal=720 + 252 + 1 + 24 .vtotal=360 + 4 + 1 + 18)
> panel-ilitek-ili9322.c:631/itu_r_bt_656_720_mode: 60 vs. 5422 (.clock=2700000 .htotal=720 + 3 + 1 + 272 .vtotal=500)
> panel-ilitek-ili9322.c:572/prgb_320x240_mode: 60 vs. 59725 (.clock=6400000 .htotal=320 + 38 + 1 + 50 .vtotal=262)

This is the datasheet if you want to take a look:
https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf

The one platform using this is using the
8 bit ITU-R BT.656 640Y 320CbCr mode which
(I think) is similar to DSI command mode again: there is a stream
of data in a burst and you decide how often you want to send it
because the panel always has backing memory and the
speed out to the physical display is something completely
different.

You can safely delete vrefresh from all of these sites.

> panel-arm-versatile.c:161/versatile_panels[]: 60 vs. 61 (.clock=25000 .htotal=640 + 24 + 96 + 24 .vtotal=480 + 11 + 2 + 32)
> panel-arm-versatile.c:208/versatile_panels[]: 116 vs. 59 (.clock=5400 .htotal=240 + 10 + 10 + 20 .vtotal=320 + 2 + 2 + 2)
> panel-arm-versatile.c:184/versatile_panels[]: 390 vs. 1523 (.clock=62500 .htotal=176 + 2 + 3 + 3 .vtotal=220 + 0 + 2 + 1)

The only driver  drivers/gpu/drm/pl111/pl111_display.c
Uses mode->clock so just drop vrefresh.

Yours,
Linus Walleij

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2020-02-25 21:52 UTC|newest]

Thread overview: 133+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 20:35 [PATCH 00/12] drm: Put drm_display_mode on diet Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 01/12] drm: Nuke mode->hsync Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 10:55   ` Emil Velikov
2020-02-20 10:55     ` Emil Velikov
2020-02-21 16:04     ` Ville Syrjälä
2020-02-21 16:04       ` Ville Syrjälä
2020-02-21 16:55       ` Emil Velikov
2020-02-21 16:55         ` Emil Velikov
2020-02-19 20:35 ` [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 10:56   ` Emil Velikov
2020-02-20 10:56     ` [Intel-gfx] " Emil Velikov
2020-02-25  0:49     ` Inki Dae
2020-02-19 20:35 ` [PATCH 03/12] drm/i915: Introduce some local intel_dp variables Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 11:13   ` Emil Velikov
2020-02-20 11:13     ` Emil Velikov
2020-02-19 20:35 ` [PATCH 04/12] drm: Nuke mode->vrefresh Ville Syrjala
2020-02-19 20:35   ` Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35   ` Ville Syrjala
2020-02-20 12:00   ` Emil Velikov
2020-02-20 12:00     ` Emil Velikov
2020-02-20 12:00     ` [Intel-gfx] " Emil Velikov
2020-02-20 12:00     ` Emil Velikov
2020-02-22 12:32   ` Sam Ravnborg
2020-02-22 12:32     ` Sam Ravnborg
2020-02-22 12:32     ` [Intel-gfx] " Sam Ravnborg
2020-02-22 12:32     ` Sam Ravnborg
2020-02-24 13:14     ` Ville Syrjälä
2020-02-24 13:14       ` Ville Syrjälä
2020-02-24 13:14       ` [Intel-gfx] " Ville Syrjälä
2020-02-24 13:14       ` Ville Syrjälä
2020-02-24 14:14   ` Andrzej Hajda
2020-02-24 14:14     ` Andrzej Hajda
2020-02-24 14:14     ` [Intel-gfx] " Andrzej Hajda
2020-02-24 14:14     ` Andrzej Hajda
2020-02-25 11:21     ` Ville Syrjälä
2020-02-25 11:21       ` Ville Syrjälä
2020-02-25 11:21       ` [Intel-gfx] " Ville Syrjälä
2020-02-25 11:21       ` Ville Syrjälä
2020-02-25 15:19       ` Andrzej Hajda
2020-02-25 15:19         ` Andrzej Hajda
2020-02-25 15:19         ` [Intel-gfx] " Andrzej Hajda
2020-02-25 15:19         ` Andrzej Hajda
2020-02-25 15:45         ` Ville Syrjälä
2020-02-25 15:45           ` Ville Syrjälä
2020-02-25 15:45           ` [Intel-gfx] " Ville Syrjälä
2020-02-25 15:45           ` Ville Syrjälä
2020-02-25 19:27           ` Ville Syrjälä
2020-02-25 19:27             ` [Intel-gfx] " Ville Syrjälä
2020-02-25 19:27             ` Ville Syrjälä
2020-02-25 21:52             ` Linus Walleij [this message]
2020-02-25 21:52               ` Linus Walleij
2020-02-25 21:52               ` [Intel-gfx] " Linus Walleij
2020-02-25 21:52               ` Linus Walleij
2020-02-19 20:35 ` [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35   ` Ville Syrjala
2020-02-20 11:24   ` Emil Velikov
2020-02-20 11:24     ` [Intel-gfx] " Emil Velikov
2020-02-20 11:24     ` Emil Velikov
2020-02-20 15:33     ` Ville Syrjälä
2020-02-20 15:33       ` [Intel-gfx] " Ville Syrjälä
2020-02-20 15:33       ` Ville Syrjälä
2020-02-20 18:14       ` Daniel Vetter
2020-02-20 18:14         ` [Intel-gfx] " Daniel Vetter
2020-02-20 18:14         ` Daniel Vetter
2020-02-19 20:35 ` [PATCH 06/12] drm: Shrink {width,height}_mm to u16 Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 12:48   ` Emil Velikov
2020-02-20 12:48     ` Emil Velikov
2020-02-19 20:35 ` [PATCH 07/12] drm: Shrink mode->type to u8 Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 18:17   ` Daniel Vetter
2020-02-20 18:17     ` Daniel Vetter
2020-02-19 20:35 ` [PATCH 08/12] drm: Make mode->flags u32 Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 09/12] drm: Shrink drm_display_mode timings Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 18:19   ` Daniel Vetter
2020-02-20 18:19     ` Daniel Vetter
2020-02-20 18:47     ` Ville Syrjälä
2020-02-20 18:47       ` Ville Syrjälä
2020-02-21 16:13   ` Sam Ravnborg
2020-02-21 16:13     ` [Intel-gfx] " Sam Ravnborg
2020-02-21 17:27   ` Sam Ravnborg
2020-02-21 17:27     ` [Intel-gfx] " Sam Ravnborg
2020-02-24 13:06     ` Ville Syrjälä
2020-02-24 13:06       ` [Intel-gfx] " Ville Syrjälä
2020-02-19 20:35 ` [PATCH 10/12] drm: Flatten drm_mode_vrefresh() Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 11/12] drm: Shrink mode->private_flags Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-21 16:15   ` Sam Ravnborg
2020-02-21 16:15     ` [Intel-gfx] " Sam Ravnborg
2020-02-24 13:23     ` Ville Syrjälä
2020-02-24 13:23       ` [Intel-gfx] " Ville Syrjälä
2020-02-19 20:35 ` [PATCH 12/12] drm: pahole struct drm_display_mode Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 12:53   ` Emil Velikov
2020-02-20 12:53     ` [Intel-gfx] " Emil Velikov
2020-02-19 20:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Put drm_display_mode on diet Patchwork
2020-02-19 21:18 ` [PATCH 00/12] " Ville Syrjälä
2020-02-19 21:18   ` [Intel-gfx] " Ville Syrjälä
2020-02-19 21:21 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-02-20 13:21 ` [PATCH 00/12] " Emil Velikov
2020-02-20 13:21   ` [Intel-gfx] " Emil Velikov
2020-02-20 14:27   ` Ville Syrjälä
2020-02-20 14:27     ` [Intel-gfx] " Ville Syrjälä
2020-02-20 15:34     ` Ville Syrjälä
2020-02-20 15:34       ` Ville Syrjälä
2020-02-21 11:32       ` Jani Nikula
2020-02-21 11:32         ` Jani Nikula
2020-02-21 11:43         ` Ville Syrjälä
2020-02-21 11:43           ` Ville Syrjälä
2020-02-21 14:42           ` Daniel Vetter
2020-02-21 14:42             ` Daniel Vetter
2020-02-21 15:40             ` Ville Syrjälä
2020-02-21 15:40               ` Ville Syrjälä
2020-02-21 16:09               ` Ville Syrjälä
2020-02-21 16:09                 ` Ville Syrjälä
2020-02-21 17:16                 ` Daniel Vetter
2020-02-21 17:16                   ` Daniel Vetter
2020-02-21 17:49                   ` Ville Syrjälä
2020-02-21 17:49                     ` Ville Syrjälä
2020-02-20 17:01     ` Emil Velikov
2020-02-20 17:01       ` [Intel-gfx] " Emil Velikov
2020-02-21 15:09 ` Linus Walleij
2020-02-21 15:09   ` [Intel-gfx] " Linus Walleij
2020-02-21 18:26 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=aford173@gmail.com \
    --cc=agx@sigxcpu.org \
    --cc=bhuvanchandra.dv@toradex.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=gl@axentia.se \
    --cc=hanxu5@huaqin.corp-partner.google.com \
    --cc=jagan@amarulasolutions.com \
    --cc=jonathan@marek.ca \
    --cc=josh.wu@atmel.com \
    --cc=jy0922.shim@samsung.com \
    --cc=marian-cristian.rotariu.rb@bp.renesas.com \
    --cc=narmstrong@baylibre.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=philipp.zabel@gmail.com \
    --cc=sam@ravnborg.org \
    --cc=stefan@olimex.com \
    --cc=thellstrom@vmware.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.