linux/drivers/gpu/vga, branch v5.0

vga-switcheroo: make PCI dependency explicit

2019-01-15T22:16:47Z

This driver depends on the PCI infrastructure, but the dependency has not been explicitly called out. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya Reviewed-by: Lukas Wunner Acked-by: Daniel Vetter Signed-off-by: Rafael J. Wysocki

Merge tag 'drm-misc-next-2018-11-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2018-11-19T00:40:33Z

drm-misc-next for v4.21, part 1: UAPI Changes: - Add syncobj timeline support to drm. Cross-subsystem Changes: - Remove shared fence staging in dma-buf's fence object, and allow reserving more than 1 fence and add more paranoia when debugging. - Constify infoframe functions in video/hdmi. Core Changes: - Add vkms todo, and a lot of assorted doc fixes. - Drop transitional helpers and convert drivers to use drm_atomic_helper_shutdown(). - Move atomic state helper functions to drm_atomic_state_helper.[ch] - Refactor drm selftests, and add new tests. - DP MST atomic state cleanups. - Drop EXPORT_SYMBOL from drm leases. - Lease cleanups and fixes. - Create render node for vgem. Driver Changes: - Fix build failure in imx without fbdev emulation. - Add rotation quirk for GPD win2 panel. - Add support for various CDTech panels, Banana Pi Panel, DLC1010GIG, Olimex LCD-O-LinuXino, Samsung S6D16D0, Truly NT35597 WQXGA, Himax HX8357D, simulated RTSM AEMv8. - Add dw_hdmi support to rockchip driver. - Fix YUV support in vc4. - Fix resource id handling in virtio. - Make rockchip use dw-mipi-dsi bridge driver, and add dual dsi support. - Advertise that tinydrm only supports DRM_FORMAT_MOD_LINEAR. - Convert many drivers to use atomic helpers, and drm_fbdev_generic_setup(). - Add Mali linear tiled formats, and enable them in the Mali-DP driver. - Add support for H6 DE3 mixer 0, DW HDMI, HDMI PHY and TCON TOP. - Assorted driver cleanups and fixes. Signed-off-by: Dave Airlie From: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/be7ebd91-edd9-8fa4-4286-1c57e3165113@linux.intel.com

vga_switcheroo: Fix missing gpu_bound call at audio client registration

2018-11-05T13:56:21Z

The commit 37a3a98ef601 ("ALSA: hda - Enable runtime PM only for discrete GPU") added a new ops gpu_bound to be called when GPU gets bound. The patch overlooked, however, that vga_switcheroo_enable() is called only once at GPU is bound. When an audio client is registered after that point, it would miss the gpu_bound call. This leads to the unexpected lack of runtime PM in HD-audio side. For addressing that regression, just call gpu_bound callback manually at vga_switcheroo_register_audio_client() when the GPU was already bound. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201615 Fixes: 37a3a98ef601 ("ALSA: hda - Enable runtime PM only for discrete GPU") Cc: Reviewed-by: Lukas Wunner Signed-off-by: Takashi Iwai

vgaarb: Keep adding VGA device in queue

2018-10-23T05:23:00Z

If failed to find the deivice owning the boot framebuffer, try to use the first VGA device instead of the last one. Usually the 1st device is integrated GPU who owns the boot framebuffer. Signed-off-by: Aaron Ma Acked-by: Alex Deucher Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1535739600-8842-2-git-send-email-aaron.ma@canonical.com

vgaarb: Add support for 64-bit frame buffer address

2018-10-23T05:23:00Z

EFI GOP uses 64-bit frame buffer address when some BIOS disabled CSM support. vgaarb only stores lfb_base, this will lead boot framebuffer to wrong device. Add ext_lfb_base support to use 64-bit fb address. Signed-off-by: Aaron Ma Acked-by: Alex Deucher Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1535739600-8842-1-git-send-email-aaron.ma@canonical.com

ALSA: hda - Enable runtime PM only for discrete GPU

2018-09-13T15:58:30Z

The recent change of vga_switcheroo allowed the runtime PM for HD-audio on AMD GPUs, but this also resulted in a regression. When the HD-audio controller driver gets runtime-suspended, HD-audio link is turned off, and the hotplug notification is ignored. This leads to the inconsistent audio state (the connection isn't notified and ELD is ignored). The best fix would be to implement the proper ELD notification via the audio component, but it's still not ready. As a quick workaround, this patch adds the check of runtime_idle and allows the runtime suspend only when the vga_switcheroo is bound with discrete GPU. That is, a system with a single GPU and APU would be again without runtime PM to keep the HD-audio link for the hotplug notification and ELD read out. Also, the codec->auto_runtime_pm flag is set only for the discrete GPU at the time GPU gets bound via vga_switcheroo (i.e. only dGPU is forcibly runtime-PM enabled), so that APU can still get the ELD notification. For identifying which GPU is bound, a new vga_switcheroo client callback, gpu_bound, is implemented. The vga_switcheroo simply calls this when GPU is bound, and tells whether it's dGPU or APU. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200945 Fixes: 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller") Reported-by: Jian-Hong Pan Tested-by: Jian-Hong Pan Acked-by: Lukas Wunner Signed-off-by: Takashi Iwai

vga_switcheroo: set audio client id according to bound GPU id

2018-07-17T09:12:00Z

On modern laptop, there are more and more platforms have two GPUs, and each of them maybe have audio codec for HDMP/DP output. For some dGPU which is no output, audio codec usually is disabled. In currect HDA audio driver, it will set all codec as VGA_SWITCHEROO_DIS, the audio which is binded to UMA will be suspended if user use debugfs to contorl power In HDA driver side, it is difficult to know which GPU the audio has binded to. So set the bound gpu pci dev to vga_switcheroo. if the audio client is not the third registration, audio id will set in vga_switcheroo enable function. if the audio client is the last registration when vga_switcheroo _ready() get true, we should get audio client id from bound GPU directly. Signed-off-by: Jim Qu Reviewed-by: Lukas Wunner Signed-off-by: Takashi Iwai

docs: Fix some broken references

2018-06-15T21:10:01Z

As we move stuff around, some doc references are broken. Fix some of them via this script: ./scripts/documentation-file-ref-check --fix Manually checked if the produced result is valid, removing a few false-positives. Acked-by: Takashi Iwai Acked-by: Masami Hiramatsu Acked-by: Stephen Boyd Acked-by: Charles Keepax Acked-by: Mathieu Poirier Reviewed-by: Coly Li Signed-off-by: Mauro Carvalho Chehab Acked-by: Jonathan Corbet

vga_switcheroo: Let HDA autosuspend on mux change

2018-03-13T21:58:49Z

When switching the display on muxed machines, we currently force the HDA controller into runtime suspend on the previously used GPU and into runtime active state on the newly used GPU. That's unnecessary if the GPU uses driver power control, we can just let the audio device autosuspend or autoresume as it sees fit. Cc: Dave Airlie Cc: Ben Skeggs Cc: Takashi Iwai Cc: Alex Deucher Reviewed-by: Peter Wu Signed-off-by: Lukas Wunner Link: https://patchwork.freedesktop.org/patch/msgid/098ed883460eb4976a899eac6f5192fefc877c0f.1520068884.git.lukas@wunner.de

vga_switcheroo: Use device link for HDA controller

2018-03-13T21:58:09Z

Back in 2013, runtime PM for GPUs with integrated HDA controller was introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime suspend/resume on optimus support (v4)"). Briefly, the idea was that the HDA controller is forced on and off in unison with the GPU. The original code is mostly still in place even though it was never a 100% perfect solution: E.g. on access to the HDA controller, the GPU is powered up via vga_switcheroo_runtime_resume_hdmi_audio() but there are no provisions to keep it resumed until access to the HDA controller has ceased: The GPU autosuspends after 5 seconds, rendering the HDA controller inaccessible. Additionally, a kludge is required when hda_intel.c probes: It has to check whether the GPU is powered down (check_hdmi_disabled()) and defer probing if so. However in the meantime (in v4.10) the driver core has gained a feature called device links which promises to solve such issues in a clean way: It allows us to declare a dependency from the HDA controller (consumer) to the GPU (supplier). The PM core then automagically ensures that the GPU is runtime resumed as long as the HDA controller's ->probe hook is executed and whenever the HDA controller is accessed. By default, the HDA controller has a dependency on its parent, a PCIe Root Port. Adding a device link creates another dependency on its sibling: PCIe Root Port ^ ^ | | | | HDA ===> GPU The device link is not only used for runtime PM, it also guarantees that on system sleep, the HDA controller suspends before the GPU and resumes after the GPU, and on system shutdown the HDA controller's ->shutdown hook is executed before the one of the GPU. It is a complete solution. Using this functionality is as simple as calling device_link_add(), which results in a dmesg entry like this: pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0 The code for the GPU-governed audio power management can thus be removed (except where it's still needed for legacy manual power control). The device link is added in a PCI quirk rather than in hda_intel.c. It is therefore legal for the GPU to runtime suspend to D3cold even if the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL is not enabled, for accesses to the HDA controller will cause the GPU to wake up regardless if they're occurring outside of hda_intel.c (think config space readout via sysfs). Contrary to the previous implementation, the HDA controller's power state is now self-governed, rather than GPU-governed, whereas the GPU's power state is no longer fully self-governed. (The HDA controller needs to runtime suspend before the GPU can.) It is thus crucial that runtime PM is always activated on the HDA controller even if CONFIG_SND_HDA_POWER_SAVE_DEFAULT is set to 0 (which is the default), lest the GPU stays awake. This is achieved by setting the auto_runtime_pm flag on every codec and the AZX_DCAPS_PM_RUNTIME flag on the HDA controller. A side effect is that power consumption might be reduced if the GPU is in use but the HDA controller is not, because the HDA controller is now allowed to go to D3hot. Before, it was forced to stay in D0 as long as the GPU was in use. (There is no reduction in power consumption on my Nvidia GK107, but there might be on other chips.) The code paths for legacy manual power control are adjusted such that runtime PM is disabled during power off, thereby preventing the PM core from resuming the HDA controller. Note that the device link is not only added on vga_switcheroo capable systems, but for *any* GPU with integrated HDA controller. The idea is that the HDA controller streams audio via connectors located on the GPU, so the GPU needs to be on for the HDA controller to do anything useful. This commit implicitly fixes an unbalanced runtime PM ref upon unbind of hda_intel.c: On ->probe, a runtime PM ref was previously released under the condition "azx_has_pm_runtime(chip) || hda->use_vga_switcheroo", but on ->remove a runtime PM ref was only acquired under the first of those conditions. Thus, binding and unbinding the driver twice on a vga_switcheroo capable system caused the runtime PM refcount to drop below zero. The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag is now always set if use_vga_switcheroo is true. For more information on device links please refer to: https://www.kernel.org/doc/html/latest/driver-api/device_link.html Documentation/driver-api/device_link.rst Cc: Dave Airlie Cc: Ben Skeggs Cc: Alex Deucher Cc: Rafael J. Wysocki Acked-by: Bjorn Helgaas Reviewed-by: Takashi Iwai Reviewed-by: Peter Wu Tested-by: Kai Heng Feng # AMD PowerXpress Tested-by: Mike Lothian # AMD PowerXpress Tested-by: Denis Lisov # Nvidia Optimus Tested-by: Peter Wu # Nvidia Optimus Tested-by: Lukas Wunner # MacBook Pro Signed-off-by: Lukas Wunner Link: https://patchwork.freedesktop.org/patch/msgid/51bd38360ff502a8c42b1ebf4405ee1d3f27118d.1520068884.git.lukas@wunner.de