Thank you for your response! This panel is a separate piece, yes, hooked up via VGA, which I guess is wired internally on this mini-PC to eDP; the kernel names it card0-eDP-1. I thought it might be having issues with probing the EDID, so I'm providing it the EDID blob directly with drm_kms_helper.edid_firmware=<file>; should that not work around the issue? I know exactly what resolution and timings I need to drive this panel; is there any way I can just short-circuit all this probing and feed it a timings string directly? On Mon, May 2, 2016 at 4:12 AM, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > On Sat, 30 Apr 2016, Josh Litherland <josh@xxxxxxxxxxx> wrote: >> Hoping someone can point me in the right direction to understanding >> how intel_connector->panel.fixed_mode gets probed, as it's referenced >> in function "intel_dp_mode_valid" at drivers/gpu/drm/i915/intel_dp.c. >> >> I am working with a panel hooked up via DSUB to a port that is >> internally wired as eDP-1. The kernel is correctly probing its >> EDID-advertised preferred mode, 1360x768@60. However, in the >> above-named function, that mode is then being discarded with status >> MODE_PANEL (exceeds panel dimensions). After poking around a bit and >> adding some debugging output, I've gotten as far as the above-named >> function and found that fixed_mode is coming in to that function as >> 1280x800. Trying to trace back farther than that I get a bit lost. >> >> Thanks in advance if anyone can help me figure out where that spurious >> mode limitation is coming from. >> >> Incidentally, commenting out the checks against fixed_mode->hdisplay >> and fixed_mode->vdisplay make the panel work correctly, but I'd like >> to come at this from the other direction and find out why the probe >> failed in the first place. >> >> Thanks! >> >> Kernel is 3.16.0-4-686-pae from Debian Jessie >> Device is Intel Atom Processor Z36xxx/Z37xxx (8086:0f31) >> Dmesg here, interesting bit starts around line 807: >> http://pastebin.com/kpeWW0iB > > The fixed mode is supposed to be the panel native mode, probed at the > driver load time. However in your case, the EDID read fails at that time > (tons of "native defer" and "too many retries, giving up") which leads > to using a mode in VBT (Video BIOS Tables). You should be looking at > intel_edp_init_connector(). > > You don't say whether the panel is detachable or not, but if it is, > hooking it up to the eDP port is clearly a bad idea. > > The kernel you're using is pretty old, and we've fixed tons and tons of > DP aux and i2c issues in the driver and the drm core since then. You'd > probably have better chances of making the initial probe work with > latest kernels. An alternative is to fix your VBT (if you have access to > tools to do that) to match the panel. > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Technology Center -- Josh Litherland (josh@xxxxxxxxxxx) _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
