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@xxxxxxxxxx>
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@xxxxxxxxxx>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
