Russell, On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> 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 <http://crosreview.com/278255>, locally >> our kernel has a slightly older version of >> <https://lkml.org/lkml/2015/2/28/291>, 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 <https://patchwork.kernel.org/patch/5906771/> >> ...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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
