From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Anderson Subject: Re: rk3399: Graphical artifacts when running for-next Date: Mon, 25 Feb 2019 10:00:51 -0800 Message-ID: References: <69ddf17a-232d-fc1f-f6a7-59dbde220395@collabora.com> <1654246.IP1FNPqO5J@phil> <5313650.gBT5ZN9C5b@phil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5313650.gBT5ZN9C5b@phil> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Heiko Stuebner Cc: Robert Foss , "open list:ARM/Rockchip SoC..." , Ezequiel Garcia , Tom Cubie , Tomeu Vizoso List-Id: linux-rockchip.vger.kernel.org Hi, On Thu, Feb 21, 2019 at 1:49 PM Heiko Stuebner wrote: > non-standard resolutions are still a bit of a problem I think. > The vendor kernel (and also the CrOS kernel) does contain quite a number > of hacks to make that work. (hacking up plls and the clock-tree, making > it quite non-generic). BTW: I did spend quite a bit of time getting a whole lot of HDMI clock rates working on rk3288 in the Chrome OS kernel. The main reason these can't go upstream is that it depends on knowing that we'll be able to fully control a PLL for HDMI and that's not guaranteed on upstream. I've tried to get folks interested in trying to solve that problem in the past but never made any real progress. :( In any case, if I can ever answer any questions about the HDMI configs I figured out to work on rk3288, please let me know. -Doug