Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756046AbbFRP0w (ORCPT ); Thu, 18 Jun 2015 11:26:52 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35505 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754983AbbFRP0m (ORCPT ); Thu, 18 Jun 2015 11:26:42 -0400 MIME-Version: 1.0 In-Reply-To: <20150618085335.GF7557@n2100.arm.linux.org.uk> References: <1434582847-713-1-git-send-email-dianders@chromium.org> <20150617233040.GE7557@n2100.arm.linux.org.uk> <20150618085335.GF7557@n2100.arm.linux.org.uk> Date: Thu, 18 Jun 2015 08:26:39 -0700 X-Google-Sender-Auth: Lc5zMkrdYI12a4t_HUarlhkyELc Message-ID: Subject: Re: [PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI From: Doug Anderson To: Russell King - ARM Linux Cc: Philipp Zabel , Thierry Reding , Heiko Stuebner , David Airlie , Andy Yan , Yakir Yang , Fabio Estevam , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3649 Lines: 84 Russell, On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux wrote: >> OK, so clearly my patch won't work against mainline. I guess it's a >> good thing that I pointed out that it was only tested locally (would >> have been better to test against mainline, but I don't think that's so >> easy since there are several unlanded patches in mainline for >> Rockchip). > > As far as I'm aware, Freescale's original BSP version was the same, as is > their later BSPs, and Jon's maintained 3.14-stable kernel. Was "the same"? You mean was untested, or was 3.14? It is probably not the same "3.14 with backports" that I'm testing on, which includes backports + things from the mailing list that haven't landed yet, as many of the unlanded patches are things that make Rockchip HDMI work more correctly. Perhaps I should have called my tree "3.14 with backports + unlanded patches" or "the chromeos 3.14 tree" to make it clearer. In general I haven't been posting patches that I've made to HDMI since it appears that our tree has significant differences from mainline. In this case the function I was touching looked identical to mainline so I figured posting a patch seemed reasonable. >> As pointed out by others at , locally >> our kernel has a slightly older version of >> , which would change mdvi to be >> as needed. > > Please don't post unreliable lkml.org URLs, please use some other archive > site. I can't access this URL at the moment. Perhaps you can try >> ...so I guess my change is blocked on someone reviewing/landing that >> series. If that series is rejected (or is changed sufficiently so >> that mdvi no longer is set via drm_detect_hdmi_monitor() then my patch >> will need to be re-spun. > > That's not what I said. I said mdvi is set according to whether the mode > being set is a CEA mode or not. Perhaps now that you can access the patch with the patchwork link you can re-read my email. If/when that patch lands then mdvi _will_ be set as per drm_detect_hdmi_monitor(). > A thought occurs to me this morning though: what happens if you connect > a DVI monitor to an AV receiver which is then connected to this device. > Does the resulting EDID contain the HDMI vendor ID? If it does, it > means that drm_detect_hdmi_monitor() will return true, indicating that > the connected device is HDMI, and we will still allow modes greater than > 165MHz. I am nowhere near an HDMI expert. If you have a better suggestion then I'm more than happy for you to post it and drop my patch. In my non-expert opinion, it would seem awfully strange for an AV receiver to modify the EDID though unless it was actively interpreting the signal and generating a whole new signal on the other end. In any case, perhaps you can find such a device and that will give insight to how we should deal with it. Until such a device is found, it seems fruitless to speculate. Personally, I was pointed at "drivers/gpu/drm/i915/intel_hdmi.c". If you look there you will find a similar bit of code. To summarize: I am not planning to spin my patch. I am hopeful that folks could review Yakir's series. Would it help if he re-sent it with different people in the "To" line? Maybe when Yakir spins his series next he can include my patch? -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/