| commit | 450c24cbf61b758ffa39cde702015c99eb46a8f0 | [log] [tgz] |
|---|---|---|
| author | Angel Pons <th3fanbus@gmail.com> | Tue May 12 22:49:52 2020 |
| committer | Nico Huber <nico.h@gmx.de> | Sun Jul 19 18:04:00 2020 |
| tree | 7ea770b5c3f41d73f1e4c7bc25139b7083b427ac | |
| parent | 3f86b0b121ff5f07d5d1ab5c1b210ea92620bb30 [diff] |
haswell: Make VGA on FDI work Attempting to light up a 1920x1080 monitor through VGA with libgfxinit on Haswell would either hang the system or show garbage on the monitor. This was due to two different problems around FDI initialization code. The system would only hang if libgfxinit was the first program to light up a monitor on VGA. This is because no one had performed the required FDI mPHY initialization that is described on the Haswell graphics PRMs. Add it to libgfxinit alongside some code to disable bending CLKOUT_DP. Even with the FDI mPHY initialization in place, the garbage would still be present on the VGA monitor. Digital interfaces were not affected. By carefully dumping and comparing the display registers of a good and a bad case, it was determinted that the fault was due to a mismatched link width for FDI. The FDI link between the iGPU and the Lynxpoint PCH can operate in either x1 or x2 width, depending on the bandwidth needs of the monitor on the PCH's VGA port. To drive a 1920x1080 VGA monitor, it is necessary to use both FDI lanes. Moreover, both ends of the link need to be configured to use the same link width. However, the wrong link width was assumed when configuring the display pipe, because `DP.Lane_Count` was used unconditionally instead of `FDI.Lane_Count`. After fixing both issues, gfx_test is able to light up a 1920x1080 VGA monitor on the Asrock B85M Pro4 successfully, even after a S3 resume. Change-Id: Ieabe3b7f947be2ef488ddb57bfeae85fa055d360 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/libgfxinit/+/41343 Tested-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Nico Huber <nico.h@gmx.de>
libgfxinit is a graphics initialization (aka modesetting) library for embedded environments. It currently supports only Intel hardware, more specifically the Intel Core processor line.
It can query and set up most kinds of displays based on their EDID information. You can, however, also specify particular mode lines.
libgfxinit is written in SPARK, an Ada subset with formal verifica- tion aspects. Absence of runtime errors can be proved automatically with SPARK GPL 2016.
For compilation, the GNAT Ada compiler is required. Usual package names in Linux distributions are gcc-ada and gnat.
You'll need libhwbase and libgfxinit. Best is to clone the reposi- tories into a common parent directory (this way libgfxinit will know where to find libhwbase).
$ mkdir gfxfun && cd gfxfun $ git clone https://review.coreboot.org/p/libhwbase.git $ git clone https://review.coreboot.org/p/libgfxinit.git
Both libraries are currently configured by hand-written config files. You can either write your own .config, link one of the shipped files in configs/, e.g.:
$ ln -s configs/linux libhwbase/.config
or overwrite the config filename by specifying cnf=<configfile> on the make command line.
By default most debug messages won't be compiled into the binary. To include them into the build, set DEBUG=1 on the command line or in your .config.
Let‘s install libhwbase. We’ll need configs/linux to build regular Linux executables:
$ cd libhwbase $ make DEBUG=1 cnf=configs/linux install
By default this installs into a new subdirectory dest. You can however overwrite this decision by specifying DESTDIR=.
gfx_testlibgfxinit is configured and installed in the same manner as de- scribed above. You will have to select a configuration matching your hardware.
The makefile knows an additional target gfx_test to build a small Linux test application:
$ cd ../libgfxinit $ make DEBUG=1 cnf=configs/sandybridge gfx_test
The resulting binary is build/gfx_test.
gfx_test sets up its own framebuffer in the stolen memory. It backs any current framebuffer mapping and contents up first and re- stores it before exiting. This works somehow even while the i915 driver is running. A wrapper script gfxtest/gfx_test.sh is pro- vided to help with the setup. It switches to a text console first and tries to unload the i915 driver. But ignores failures to do so (it won't work if you still have any application running that uses the gfx driver, e.g. an X server).
# gfxtest/gfx_test.sh
If you chose the right config above, you should be presented with a nice test image. But please be prepared that your console might be stuck in that state afterwards. You can try to run it with i915 deactivated then (e.g. when booting with nomodeset in the kernel command line or with i915 blacklisted) and loading it afterwards.