Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.gh13...@intel.com> References: <20200219203544.31013-1-ville.syrj...@linux.intel.com> <cgme20200219203620eucas1p24b4990a91e758dbcf3e9b943669b0...@eucas1p2.samsung.com> <20200219203544.31013-5-ville.syrj...@linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.com> <20200225112114.ga13...@intel.com> <3ca785f2-9032-aaf9-0965-8657d3111...@samsung.com> <20200225154506.gf13...@intel.com> <20200225192720.gg13...@intel.com> <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dma_-r23yqh3nc...@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_-r23yqh3nc...@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.syrj...@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
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
