Tag Archives: Driver

Intel Sends Out First Batch Of Display/Graphics Driver Updates For Linux 5.1 Kernel


INTEL --

While the Linux 5.0 kernel won’t even debut as stable until around the end of February, as is standard practice, it’s open season for new feature improvements of the changes developers want to end up queuing into the “-next” branches ahead of the Linux 5.1 cycle. The Intel open-source driver developers on Monday sent in their initial batch of graphics driver changes for this next kernel cycle.

Rodrigo Vivi of the Intel Open-Source Technology Center sent in their initial Linux 5.1 Intel DRM driver material today to DRM-Next for its vetting until the Linux 5.1 merge window at the start of March.

The Icelake “Gen 11” graphics support for Linux appears to be squared away ahead of the new CPUs debuting later in the year. With this 5.1 pull request there are just a handful of Icelake “ICL” related patches mostly around the display handling and in particular for Type-C/Thunderbolt ports.

This initial 5.1 pull request is largely made up of low-level code clean-ups, random fixes, and some kernel documentation improvements. Some of the larger fixes/changes include better debugfs handling, removing hardware semaphores for Gen7 interl-engine sync, improvements around GPU resetting and hang reporting, some power management related tweaks, and other small items.

One sort of feature to mention is that frame-buffer compression (FBC) is now supported for 5K displays on Gen10 (Cannonlake) graphics and newer. But with Cannonlake graphics not materializing, that seems like it will really be a change for Icelake.

The complete list of these patches initially staged for Linux 5.1 by way of DRM-Next can be found via this pull request. Expect more changes in the weeks ahead while Linux 5.0 gets buttoned up.


Even In 2019, A Long Road Still For Getting The VIA OpenChrome Driver In Linux


VIA --

It’s been over a decade since VIA x86 hardware has been relevant and with that their Unichrome/Chrome integrated graphics chipsets, but the effort still isn’t over for trying to get the OpenChrome DRM/KMS driver into the mainline Linux kernel for these vintage systems.

For nearly three years now, the OpenChrome project that’s been focused on open-source driver support for VIA graphics hardware has been down to just one active developer who has been learning along the way and trying to take the existing OpenChrome DRM/KMS code and work it into a state that could be merged into the mainline Linux kernel. That developer, Kevin Brace, is also the one that’s been doing new patch releases on the RAGE 128 X.Org driver, other vintage hardware, and even wanting to see new xorg-server releases to help out old hardware.

Last year when evaluating the potential for getting the OpenChrome DRM/KMS driver code merged to mainline, there was some resistance in accepting any new DRM/KMS driver unless it first supported the modern atomic mode-setting APIs in the kernel. It did not then and does not know. When Kevin Brace fired off a new message this week about interest in getting the driver merged, there’s even more interest in seeing atomic support first before accepting new drivers based upon their experience last year in pulling the VirtualBox DRM driver to the staging area without atomic support.

Also with the interest in seeing OpenChrome submitted to the kernel tree proper and bypass the staging area, it doesn’t look like this code will be pulled in the near-term.

Even if this driver were to be merged now, there is no OpenChrome acceleration support at this time. In a blog post today, Kevin mentioned he is deleting the acceleration code that was unfinished and not working.


Intel Graphics Driver Working On FP16 Visual Support For Handling Wide Color Gamut


INTEL --

Besides the Intel engine-reset graphics driver work, some other interesting activity to report on this weekend in the Intel open-source Linux graphics driver space is the FP16 visual and frame-buffer configuration support that recently debuted.

This FP16 visuals work is intended to be used with the likes of EXT_surface_SMPTE2086_metadata and EXT_gl_colorspace_scrgb extensions, albeit not implemented yet. Once those extensions are implemented it can yield support for Android wide-color gamut support and related wide-color scenarios where 16-bit per channel color depth is desired.

This initial FP16 Mesa format support work is currently under review on the Mesa mailing list. Intel’s Kevin Strasser is currently leading this work.


Power Management Changes Prepped For Linux 4.21 With New Qualcomm CPUFreq Driver


LINUX KERNEL --

Another one of the pull requests sent in early for the Linux 4.21 kernel cycle due to the holidays are the ACPI and power management trees maintained by Intel’s Rafael Wysocki.

The power management changes for this next version of the Linux kernel aren’t too exciting on the x86_64 CPU front this time around but there are a few other changes worth pointing out:

– There is a new Qualcomm CPUFreq driver called “qcom-hw” for controlling CPU frequency scaling on Qualcomm SoCs having a hardware engine that controls frequency transitions. This hardware engine in turn interfaces with this ARM_QCOM_CPUFREQ_HW code via a firmware interface. This new driver has been in development for a while by Qualcomm / Code Aurora. It appears this hardware engine is present with Qualcomm;s Kryo 385 and newer.

– A new cpuidle.governor= command line parameter for the kernel to control the CPU idle governor selected at boot time.

– System-wide suspend and resume support in the Devfreq framework.

– The ACPI subsystem can now be built without PCI support.

– The device properties framework is picking up the concept of “software nodes” to complement firmware nodes.

– A variety of other updates.

More details in the Git pulls.


Linux Getting Driver Work To Support Tesla V100 NVLink GPUs On High-End POWER9 Servers


NVIDIA --

IBM is working on the necessary upstream Linux kernel work for supporting the NVIDIA Tesla V100 GPUs on the POWER9 servers like what comprises the Sierra and Summit supercomputers.

The V100 Volta GPUs on these POWER9 servers aren’t just conventional PCIe cards plugged in but connected via NVLink and allow for coherent memory and NPU/ATS support on the POWER9 CPU. IBM has been leading the Linux kernel work to allow for the unmodified NVIDIA POWER driver to work on this hardware.

It’s a set of 20 patches affecting the kernel’s PowerPC and VFIO code for allowing this Tesla V100 GPU support to happen on the likes of the IBM POWER9 Witherspoon servers. The patch series goes on to explain in more technical detail:

POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not pluggable PCIe devices but still have PCIe links which are used for config space and MMIO. In addition to that the GPUs have 6 NVLinks which are connected to other GPUs and the POWER9 CPU. POWER9 chips have a special unit on a die called an NPU which is an NVLink2 host bus adapter with p2p connections to 2 to 3 GPUs, 3 or 2 NVLinks to each. These systems also support ATS (address translation services) which is a part of the NVLink2 protocol. Such GPUs also share on-board RAM (16GB or 32GB) to the system via the same NVLink2 so a CPU has cache-coherent access to a GPU RAM.

This exports GPU RAM to the userspace as a new VFIO device region. This preregisters the new memory as device memory as it might be used for DMA. This inserts pfns from the fault handler as the GPU memory is not onlined until the vendor driver is loaded and trained the NVLinks so doing this earlier causes low level errors which we fence in the firmware so it does not hurt the host system but still better be avoided; for the same reason this does not map GPU RAM into the host kernel (usual thing for emulated access otherwise).

More details in the patches. While these high-end POWER9 + Volta HPC servers are out of reach for most, it’s fun to see this hardware used by some of the leading supercomputers getting closer to actually working off a mainline kernel. Though as these patches are still under review, don’t count on seeing the work merged for the imminent Linux 4.21 cycle.