[Intel-gfx] Intel eDP and fixed_mode probing/initialization

[Josh Litherland]

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 at linux.intel.com> wrote:
> On Sat, 30 Apr 2016, Josh Litherland <josh at temp123.org> 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 at 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 at temp123.org)