From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933254AbcLIJhN (ORCPT ); Fri, 9 Dec 2016 04:37:13 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:36240 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932362AbcLIJhJ (ORCPT ); Fri, 9 Dec 2016 04:37:09 -0500 Date: Fri, 9 Dec 2016 10:36:57 +0100 From: Maxime Ripard To: Chen-Yu Tsai Cc: David Airlie , dri-devel , linux-arm-kernel , linux-kernel , linux-sunxi , Laurent Pinchart , Sean Paul , Eric Anholt , Daniel Vetter Subject: Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check Message-ID: <20161209093657.jcalemg5xpumr2ma@lukather> References: <20161124112231.4297-1-wens@csie.org> <20161206172911.z6sbjzgqv3vfcrfh@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p7aqbbgt4mu56dsv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --p7aqbbgt4mu56dsv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 07, 2016 at 10:26:25AM +0800, Chen-Yu Tsai wrote: > > Some panels require an exact frequency, some have a minimal frequency > > but no maximum, some have a maximum frequency but no minimal, and I > > guess most of them deviates by how much exactly they can take (and > > possibly can take more easily a higher frequency, but are less > > tolerant if you take a frequency lower than the nominal. > > > > And we cannot remove that check entirely, since some bridges will > > report out of range frequencies for higher modes that we know we > > cannot reach. >=20 > I believe this should be handled by the bridge driver in the check > callback? This doesn't really have anything to do with the bridge itself, it's a limitation on the encoder. For all we know, the bridge might be able to operate at the higher resolutions without any issues if the encoder was able to. > The callback I'm changing is attached to the connector, which I > think doesn't get used if you have a bridge instead. And this only > checks the pre-registered display modes, such as those specified in > simple-panel or EDID. Geeee, I forgot to send that one (and thought I did)... I'll send that patch next week, but basically, I was creating a mode_valid hook at the encoder level, and moving the RGB mode_valid hook from the connector to the encoder (since it really is an encoder limitation). Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --p7aqbbgt4mu56dsv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYSns5AAoJEBx+YmzsjxAgnnUQALKms7bfq9JMM4jp3D2d1Wi1 T09A8eVdC0dDx9d3nmfMRlR9DozO7uuVQhJVmJrQ71a1JgSnyQOaJQTuNbNhGUCD k8AddFRdymm64e9B7giT70fLzOSjLe83QbKsE9SZCxd7G2Pq9YfmCaC43u4pMN9D lbOF5yPniq+EmdICnfwEsgsztQSYWP/CHPQfF1PX8mlojqPnrCAlWTpiWOzOjAjU WE/UGC0HIc4fsjmtIGJUpPy6VVl0qFEJwIZLscVsoyYtlVIcXhcNiZSCmzp2yMSB x2MUlhSkn0tWfZaEcxgdqOrJbpZdGKi04HUGvEULWtvYmQfYF4MZY8lpFEfNnOHe I3+1Mf1c1IOBgL+hZjmXfsHxW0svvu1F+9aUxtJwDhN5fwoWmsnJL3rYx01rpzCq RSqWcJBLoW250pn0wR6pyEXhpwXIuCBW/XZS9a1ux5OuOoB6vfEKW70fUXMKeyZz uYTSk6+RYVgmSzlNEsZGd1AQj+rO6jsEsp5MfDzV43uqIBtBNlmjewuov+4K0sBd bz2PIVx83XUTXPl97LqBCx35JYv2oGC/y97NzDeDG4Gh5sY3/ETswDNRgAXw+1H5 Po6qoJd8H8IDzoQMp94tZqeuAqU3ww/n17u0Pa4oL3g71WALEVYi6EHDbBDPkz+4 nCgG/v1QTwkuFV+gB8HI =jtkZ -----END PGP SIGNATURE----- --p7aqbbgt4mu56dsv--