[Intel-gfx] (no subject)
Ville Syrjälä
ville.syrjala at linux.intel.com
Wed Feb 26 11:57:08 UTC 2020
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Message-ID: <20200226115708.GH13686 at intel.com>
References: <20200219203544.31013-1-ville.syrjala at linux.intel.com>
<CGME20200219203620eucas1p24b4990a91e758dbcf3e9b943669b0c8f at eucas1p2.samsung.com>
<20200219203544.31013-5-ville.syrjala at linux.intel.com>
<0f278771-79ce-fe23-e72c-3935dbe82d24 at samsung.com>
<20200225112114.GA13686 at intel.com>
<3ca785f2-9032-aaf9-0965-8657d31116ba at samsung.com>
<20200225154506.GF13686 at intel.com>
<20200225192720.GG13686 at intel.com>
<CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g at mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g at mail.gmail.com>
X-Patchwork-Hint: comment
User-Agent: Mutt/1.10.1 (2018-07-13)
On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
> <ville.syrjala at 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.
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.
--
Ville Syrjälä
Intel
More information about the Intel-gfx
mailing list