[Intel-gfx] [PATCH] drm/i915: Enable fastboot by default on Skylake and newer

[Hans de Goede]

Hi,

On 29-01-19 15:02, Joonas Lahtinen wrote:
> Quoting Hans de Goede (2019-01-25 10:36:48)
>> Hi Rodrigo and Maarten,
>>
>> On 24-01-19 23:20, Rodrigo Vivi wrote:
>>> On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
>>>> From: Hans de Goede <hdegoede at redhat.com>
>>>>
>>>> We really want to have fastboot enabled by default to avoid an ugly
>>>> modeset during boot.
>>>>
>>>> Rather then enabling it everywhere, lets start with enabling it on
>>>> Skylake and newer.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>>
>>>
>>> I believe at this point you both addressed all of my concerns.
>>> And CI is happy. Let's give a try ;)
>>
>> Great, thank you.
>>
>> On IRC Maarten asked me about if we should also enable this for
>> VLV/CHV. As you may know, as a spare time/weekend project, I've been
>> working on making Linux support Bay and Cherry Trail based hardware,
>> better. As such I've about 40 different devices with these SoCs and
>> I've tested fastboot=1 on all of them. fastboot=1 not only works on
>> all of them, on 2 devices the display goes black when we have
>> fastboot=0 for some reason which I've been unable to figure out.
>> These 2 devices do survive a full-modeset just fine after the initial
>> one ?
> 
> You're not talking about PIPO X8(s) by any chance? I also happen to own
> those devices for side projects.

No I'm talking about the TEclast X80 pro and the VIOS LTH17 (no-name
X83x0 laptop).

> The verdict is that some revisions of them are missing the VBT sequences
> to actually bring up the display. So if you try to change the display
> mode after boot from Linux, the display won't ever come back up, as the
> GPIO sequences to bring them up do not exist.
> 
> Those information blocks are simply empty or missing, and the sequences
> have been hacked into the GOP driver and the Android/Windows display
> drivers. It also involved programming a mux configuration in addition to
> bringing up the display.
> 
> I even found some Android source dumps for the platform, but as I'm not
> that much of a display side guy and it was not a straightforward matter
> I gave up and got my devices exchanged for ones that include the VBT :P
> 
> Porting the code (they had basically re-used big portions of the GMA
> drivers) seemed like a doable although big task.

The situation on these 2 is different, the VBT appears complete and
subsequent full mode-sets, such as after a suspend/resume do work.

It is just that the LCD goes black if the initial modeset when the
first drm-using app (or fbcon) loads is a full-modeset.

Quite weird. Since the initial modeset involves turning the display
off and then on again in quick succession I've tried adding a
sleep in between, but that does not help. I've also checked the
MIPI sequences to see if there was an unimplemented part (such as
the PMIC sequences I've recently been working on) but that is not
the case either.

> PS. I'm huge fan of this non-flicker boot effort! I contributed the
> original splashscreen patches for gummiboot (now systemd-boot) for a
> project. Hopefully we soon have a completely smooth graphical
> boot process :)

I'm glad you like it.

Regards,

Hans