Intel eDP and fixed_mode probing/initialization

Intel eDP and fixed_mode probing/initialization

[Josh Litherland]

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

-- 
Josh Litherland (josh@temp123.org)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Intel eDP and fixed_mode probing/initialization

[Jani Nikula]

On Sat, 30 Apr 2016, Josh Litherland <josh@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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: 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@linux.intel.com> wrote:
> On Sat, 30 Apr 2016, Josh Litherland <josh@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@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@temp123.org)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx