Russell,
On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux linux@arm.linux.org.uk 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