Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756146AbbFRP4Y (ORCPT ); Thu, 18 Jun 2015 11:56:24 -0400 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:40704 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755100AbbFRP4I (ORCPT ); Thu, 18 Jun 2015 11:56:08 -0400 Date: Thu, 18 Jun 2015 16:55:45 +0100 From: Russell King - ARM Linux To: Doug Anderson 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" Subject: Re: [PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI Message-ID: <20150618155545.GQ7557@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4238 Lines: 95 On Thu, Jun 18, 2015 at 08:26:39AM -0700, Doug Anderson wrote: > 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? I'm saying that the mdvi thing behaves the same in all the kernel sources I've seen of this driver, and I'm unaware of anything that changes it - and I've been looking at Jon's 3.14-stable kernels as well as Freescale's git repository. > >> 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 Something like that needs to be done, but let's get rid of the mdvi thing in struct hdmi_vmode - it doesn't belong there, it isn't part of the currently set video mode, but becomes a property of the connected sink. I'd also prefer it to be called "is_dvi_sink", especially as its function is changing from "is it a CEA mode" to "is the attached device a DVI sink". Even better would be to call it "is_hdmi_sink" to maintain positive logic with single-negation where required, rather than double- negation in places. > >> ...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(). Well, I object to that patch (see above.) > 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. Neither am I, but I have had the ability to do some testing with AV receivers in the path of a HDMI device, and I've seen how they behave. (I made copious notes on this, which I intend to publish when I have a round tuit.) Unfortunately, I have no DVI devices to test with, and DVI devices are a dying breed - most monitors today come with HDMI sockets instead. > Personally, I was pointed at "drivers/gpu/drm/i915/intel_hdmi.c". If > you look there you will find a similar bit of code. Yea, I've also been using that for inspiration too, but I put personal testing above what's in someone elses driver. :) > 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? That's a shame... I'm not inclined to Ack it as-is - and I'd also like to see Yakir's patch reworked as I mentioned above. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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/