From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932151AbdCFK5R (ORCPT ); Mon, 6 Mar 2017 05:57:17 -0500 Received: from smtprelay4.synopsys.com ([198.182.47.9]:45437 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752787AbdCFK5F (ORCPT ); Mon, 6 Mar 2017 05:57:05 -0500 Subject: Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check To: Alexey Brodkin References: <1488475674-6694-1-git-send-email-abrodkin@synopsys.com> <20170302195437.mlhzia2q2oav27mr@phenom.ffwll.local> <1488547649.2940.5.camel@synopsys.com> <873786fc-406e-850d-f9fb-a6c9ba8cf95c@synopsys.com> <1488569045.2973.14.camel@synopsys.com> CC: "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "daniel@ffwll.ch" , "daniel.vetter@ffwll.ch" , "linux-snps-arc@lists.infradead.org" , "airlied@linux.ie" From: Jose Abreu Message-ID: <50bfc375-5f72-3c5e-3442-5ad796c29413@synopsys.com> Date: Mon, 6 Mar 2017 10:48:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1488569045.2973.14.camel@synopsys.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.107.19.61] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexey, On 03-03-2017 19:24, Alexey Brodkin wrote: > > Correct. Otherwise we'll get some modes and devices that > don't work. > > Remember our saga with 74.25 vs 74.40 MHz? > > With our PLLs on AXS and HSDK boards we may generate 74.25 MHz clock > which satisfy some monitors especially those who pass correct EDID to the host. > But what if EDID is either corrupted or doesn't exist (that's my case with > some industrial monitor as well as with old DVI monitor)? > > In that case Linux kernel attempts to calculate all the values including pixel clock > but then instead of 74.25 we'll get 74.40 and equipment that used to work is no longer useful. > > So strictly speaking existing check makes perfect sense. But it reduces > compatibility with not very good monitors. > > Probably better solution to the problem is just to throw away [my] faulty HW and > buy equipment that conforms to standards (not really sure if EDID is a hard > requirement for DVI/HDMI displays or this is just an option). Hmm, per DVI and HDMI spec all compliant equipment must support the EDID. So, either you don't have a compliant equipment or the EDID is faulty (maybe wrong checksum), if you activate full debug in drm core you can see the list of probed modes from EDID. Anyway, per spec they must support EDID, otherwise you won't know what modes the display support. I think its not very portable to force a mode because it may not work in some displays. Or, if you want to make sure it is always works choose 640x480@60 because (I think) both DVI and HDMI displays must support this mode (though this would need to change at boot [or at runtime, once AXS PLL driver is in] the clock frequency from 74 to 25Mhz). > > BTW I'm wondering if there're any guidelines on what could be pixel clock > deviation from the requested one? The "flavours" of pixel clock are already handled by drm core (in cea_mode_alternate_clock()) and I think the mode that is passed to the drivers has always the corrected value (i.e. the value may vary when you have 60Hz or 59.94Hz, for example, but only the 60Hz value will be passed to the driver). Best regards, Jose Miguel Abreu > > -Alexey