- 19 Mar, 2018 9 commits
-
-
Chen-Yu Tsai authored
This patch adds compatible strings for the remaining documented components of the Allwinner A80 display pipeline. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180315114136.24747-5-wens@csie.org
-
Chen-Yu Tsai authored
The Allwinner A80 SoC has 2 documented TCONs. The display pipeline diagram from the user manual shows a third TCON, but it's missing an interrupt line, and its registers are not explained either. It's also not used in Allwinner's vendor BSP. The first TCON only has channel 0, for LCD panel output. The TCON hardware setup is peculiar in that the eDP reset must also be deasserted to allow access to the TCON. How the eDP module is wired in the SoC itself is never explained. The second TCON only has channel 1, and its output is connected to the HDMI encoder block. This patch adds a "needs_edp_reset" field to the tcon quirks structure, and adds quirks and compatible strings for the 2 documented TCONs. Signed-off-by:
-
Chen-Yu Tsai authored
The display pipeline on the A80 SoC has what is called the Detail Enhancement Unit, or DEU for short, block in between the display frontend and backend. This unit can sharpen images in both luma and chroma channels. It seems to also do colorspace conversion. This patch adds the device tree binding for this hardware block. Reviewed-by:
-
Chen-Yu Tsai authored
The A80 has 2 or 3 TCONs. The documentation and vendor kernel are very vague about the third TCON, to the point that it might not exist. In the documentation, the first TCON is missing channel 1, and the second is missing channel 0. However the vendor kernel seems to be able to use them regardless. Here we model them like the old TCONs. An oddity is that TCON0 requires the reset control for the eDP block to be deasserted, for any register access to stick. This patch adds compatible strings for TCON0 and TCON1, with TCON0 requiring an extra "edp" reset control. Reviewed-by:
-
Joe Perches authored
These macros are similar to the DRM_<LEVEL> with the addition of a struct device * to the arguments. Convert the single drm_dev_printk function into 2 separate functions. drm_dev_printk with a KERN_<LEVEL> * for generic use and drm_dev_dbg for conditional masked use. Remove the __func__ argument and use __builtin_return_address(0) to be similar to the DRM_<LEVEL> macros uses. Convert the DRM_DEV_<LEVEL> macros to remove now unnecessary arguments and use a consistent style. These macros are rarely used in the generic gpu/drm code so the code size does not change much for a defconfig, but when more drivers are enabled, there is ~4k savings. Many of these macros have no existing use at all. $ size -t drivers/gpu/drm/built-in.a | tail -1 1877530 44651 995 1923176 1d5868 (TOTALS) $ size -t drivers/gpu/drm/built-in.a | tail -1 1877527 44651 995 1923173 1d5865 (TOTALS) $ size -t drivers/gpu/drm/built-in.a | tail -1 17166750 2689238 108352 19964340 130a1b4 (TOTALS) $ size -t drivers/gpu/drm/built-in.a | tail -1 17168888 2691734 108352 19968974 130b3ce (TOTALS) Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/e5c164946e15375ac71b69b75f296efdf0b76e6d.1521233717.git.joe@perches.com
-
Daniel Vetter authored
We have quite a few driver docs now, which is great, but having them all in the top-level gpu documentation chapter makes it harder to spot the core/shared bits. Stuff them into a separate chapter and ecourage people to add even more! Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316075926.13584-1-daniel.vetter@ffwll.ch
-
Paul McQuade authored
Fix a couple of checkpatch issues Signed-off-by:
Paul McQuade <paulmcquad@gmail.com> [seanpaul squashed series of 4 into one patch, and changed commit msg] Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180319005225.1545-1-paulmcquad@gmail.com
-
Haneen Mohammed authored
This patch remove the compatibility aliases drm_mode_object_{reference/unreference} of drm_mode_object_{get/put} since all callers have been converted to the prefered _{get/put}. Remove the helpers from the semantic patch drm-get-put-cocci. Signed-off-by:Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by:
-
José Roberto de Souza authored
eDP 1.4a specification defines PSR version 3, it PSR2 with the addition of Y-coordinate support when doing selective update. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180317013828.24182-1-jose.souza@intel.com
-
- 16 Mar, 2018 11 commits
-
-
Gustavo A. R. Silva authored
In preparation to enabling -Wvla, remove VLA. In this particular case use macro ARRAY_SIZE so the length of array _bo_ can be computed at preprocessing time. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug. Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
-
Ville Syrjälä authored
Do the refresh rate calculation with a single division. This gives us slightly more accurate results, especially for interlaced since we don't just double the final truncated result. We do lose one bit compared to the old way, so with an interlaced mode the new code can only handle ~2GHz instead of the ~4GHz the old code handeled. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180313150759.27620-2-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
No need to store the return value in a variable since we don't have to do any unwinding. Signed-off-by:
-
Ville Syrjälä authored
Avoid all the sizeof(drm_color_lut) business by using drm_color_lut_size() to convert the blob length into number of LUT entries. Signed-off-by:
-
Ville Syrjälä authored
Now that blob->data is void* again we don't need to cast it. Signed-off-by:
-
Ville Syrjälä authored
Provide a small helper to convert the blob length in bytes to the number of LUT entries. v2: Add kerneldoc (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
While we want to potentially support multiple different gamma/degamma LUT sizes we can (and should) at least check that the blob length is a multiple of the LUT entry size. v2: s/expected_size_mod/expected_elem_size/ (Daniel) Add kernel doc (Daniel) v3: s/we/were/ typo in the docs Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: -
Ville Syrjälä authored
Now that blob->data is void* again we don't need the casts anymore. Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Using a flexible array for the blob data was a mistake by me. It forces all users of the blob data to cast blob->data to something else. void* is clearly superior so let's go back to the original scheme. Not a clean revert as the code has moved. This reverts commit d63f5e6b. Signed-off-by:
-
Chris Zhong authored
There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence only one PHY can connect to DP controller at one time, the other should be disconnected. The GRF_SOC_CON26 register has a switch bit to do it, set this bit means enable PHY 1, clear this bit means enable PHY 0. If the board has 2 Type-C ports, the DP driver get the phy id from devm_of_phy_get_by_index, and then control this switch according to this id. But some others board only has one Type-C port, it may be PHY 0 or PHY 1. The dts node id can not tell us the correct PHY id. Hence move this switch to PHY driver, the PHY driver can distinguish between PHY 0 and PHY 1, and then write the correct register bit. Signed-off-by:
Chris Zhong <zyw@rock-chips.com> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> [The phy-changes are in the phy-tree now and the cdn-dp wasn't enabled at all so far, so this change can go through drm-misc alone without causing issues when testing drm-misc] Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180216120956.19034-6-enric.balletbo@collabora.com
-
Joe Perches authored
drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary arguments that can be removed by creating separate functins. Create specific functions for these calls to reduce x86/64 defconfig size by ~20k. Modify the existing macros to use the specific calls. new: $ size -t drivers/gpu/drm/built-in.a | tail -1 1876562 44542 995 19220999 1d5433 (TOTALS) old: $ size -t drivers/gpu/drm/built-in.a | tail -1 1897565 44542 995 1943102 1da63e (TOTALS) Miscellanea: o intel_display requires a change to use the specific calls. Signed-off-by:
-
- 15 Mar, 2018 1 commit
-
-
Fabio Estevam authored
The cable_plugin member never receives an assignment, so it is always false, which causes hdmi_enable_overflow_interrupts() to never be called as per the logic below: if (hdmi->cable_plugin && hdmi->sink_is_hdmi) hdmi_enable_overflow_interrupts(hdmi); This has been the case since the driver was originally introduced in commit 9aaf880e ("imx-drm: Add mx6 hdmi transmitter support"). Remove the cable_plugin element and the hdmi_enable_overflow_interrupts() function that is never called. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> # On R-Car H3 Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1518812170-22687-1-git-send-email-festevam@gmail.com
-
- 14 Mar, 2018 14 commits
-
-
Haneen Mohammed authored
This patch replace instances of drm_framebuffer_unreference with _put() suffix, because it is shorter and consistent with the kernel use of *_get/put() suffixes. This was done with the following Coccinelle script: @r@ expression e; @@ ( -drm_framebuffer_reference(e); +drm_framebuffer_get(e); | -drm_framebuffer_unreference(e); +drm_framebuffer_put(e); ) Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Marc Zyngier authored
The rockchip DRM driver is quite careful to disable interrupts when taking a lock that is also taken in interrupt context, which is a good thing. What is a bit over the top is to use spin_lock_irqsave when already in interrupt context, as you cannot take another interrupt again, and disabling interrupt is just pure overhead. Switching to the non _irqsave version in interrupt context is more logical, and less heavy handed. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Marc Zyngier authored
memcpy is only meant to be used for memory, and only that. MMIO accessors should be used to access MMIO regions, preferably the ones that correspond to the size of the register accessed. Let's convert the bulk register copy to writel/readl_relaxed, which is the correct API. Signed-off-by:
-
Marc Zyngier authored
Calling request_irq() followed by disable_irq() is usually a bad idea, specially if the interrupt can be pending, and you're not yet in a position to handle it. This is exactly what happens on my kevin system when rebooting in a second kernel using kexec: Some interrupt is left pending from the previous kernel, and we take it too early, before disable_irq() could do anything. Let's clear the pending interrupts as we initialize the HW, and move the interrupt request after that point. This ensures that we're in a sane state when the interrupt is requested. Cc: stable@vger.kernel.org Signed-off-by:
-
zain wang authored
We currently wait for the panel to mirror our intended PSR state before continuing on both PSR enter and PSR exit. This is really only important to do when we're entering PSR, since we want to be sure the last frame we pushed is being served from the panel's internal fb before shutting down the soc blocks (vop/analogix). This patch changes the behavior such that we only wait for the panel to complete the PSR transition when we're entering PSR, and to skip verification when we're exiting. Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: Sonny Rao <sonnyrao@chromium.org> Signed-off-by:
zain wang <wzz@rock-chips.com> Signed-off-by:
Thierry Escande <thierry.escande@collabora.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
Like many other panel drivers, this one fails to build when backlight support is disabled: drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe': panel-raydium-rm68200.c:(.text+0x14a): undefined reference to `devm_of_find_backlight' This adds the appropriate dependency. Note that while include/linux/backlight.h provides a stub inline when backlight support is not enabled, this isn't enough to deal with the case where backlight support is built as a module but the panel driver is built-in, in which case linking will still fail as above. One way to avoid this is to add a dependency such as this: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n but that is rather complex and misses the point that the panel support is mostly useless without backlight support. Fixes: 2b7ed18b ("drm/panel: Add support for Raydium RM68200 panel driver") Signed-off-by:Arnd Bergmann <arnd@arndb.de> [treding@nvidia.com: clarify the need for the dependency] Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180313210015.3344380-1-arnd@arndb.de
-
zain wang authored
Add a lock to vop to avoid disabling the crtc while waiting for a line flag while enabling psr. If we disable in the middle of waiting for the line flag, we'll end up timing out or worse. Signed-off-by:
-
zain wang authored
We would meet a short black screen when exit PSR with the full link training, In this case, we should use fast link train instead of full link training. Signed-off-by:
-
zain wang authored
There is a race between AUX CH bring-up and enabling bridge which will cause link training to fail. To avoid hitting it, don't change psr state while enabling the bridge. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by:
Caesar Wang <wxt@rock-chips.com> [seanpaul fixed up the commit message a bit and renamed *_supported to *_enabled] Signed-off-by:
-
Sean Paul authored
Now that the spinlocks and timers are gone, we can remove the psr worker located in rockchip's analogix driver and do the enable/disable directly. This should simplify the code and remove races on disable. Cc: 征增 王 <wzz@rock-chips.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
-
Yakir Yang authored
Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() function, or print the sink PSR error state if we failed to apply the requested PSR setting. Cc: 征增 王 <wzz@rock-chips.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
Yakir Yang <ykk@rock-chips.com> [seanpaul changed timeout loop to a readx poll] Signed-off-by:
-
Giulio Benetti authored
Handle both positive and negative dclk polarity, according to bus_flags, taking care of this: On A20 and similar SoCs, the only way to achieve Positive Edge (Rising Edge), is setting dclk clock phase to 2/3(240°). By default TCON works in Negative Edge(Falling Edge), this is why phase is set to 0 in that case. Unfortunately there's no way to logically invert dclk through IO_POL register. The only acceptable way to work, triple checked with scope, is using clock phase set to 0° for Negative Edge and set to 240° for Positive Edge. On A33 and similar SoCs there would be a 90° phase option, but it divides also dclk by 2. This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers for using A33 90° phase divided by 2 and consequently increase code complexity. Signed-off-by:
Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by:
-
Giulio Benetti authored
mode_valid function is missing for lvds. Add it making it pointed by encoder helper functions. Signed-off-by:
-
Giulio Benetti authored
mode_valid function must be connected to encoder. Otherwise it could get not be called by drm in the case there's a bridge connected to encoder instead of a panel. Move mode_valid function pointer to encoder helper functions, changing its prototype according to encoder helper function pointer. Signed-off-by:
-
- 13 Mar, 2018 5 commits
-
-
Lukas Wunner authored
Commit 5addcf0a ("nouveau: add runtime PM support (v0.9)") prevents runtime suspend of the GPU if its integrated HDA controller is not bound to a driver. The rationale appears to be that probing the HDA fails if the GPU is in D3cold. However we now use a device link to ensure that the GPU is runtime resumed while the HDA controller is probed, rendering this safety measure obsolete. Remove it. Cc: Dave Airlie <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Peter Wu <peter@lekensteyn.nl> Tested-by: Denis Lisov <dennis.lissov@gmail.com> # Nvidia Optimus Tested-by: Peter Wu <peter@lekensteyn.nl> # Nvidia Optimus Tested-by: Lukas Wunner <lukas@wunner.de> # MacBook Pro Signed-off-by:
Lukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/77e0ab74f3377ea9b6acf8fab624acfb4f7dbeca.1520068884.git.lukas@wunner.de
-
Lukas Wunner authored
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 <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Lukas Wunner authored
Back in 2013, runtime PM for GPUs with integrated HDA controller was introduced with commits 0d69704a ("gpu/vga_switcheroo: add driver control power feature. (v3)") and 246efa4a ("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 <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Lukas Wunner authored
If DRM drivers use runtime PM, they currently notify vga_switcheroo whenever they ->runtime_suspend or ->runtime_resume to update vga_switcheroo's internal power state tracking. That's essentially a duplication of a functionality performed by the PM core as it already tracks the GPU's power state and vga_switcheroo can always query it. Introduce a new internal helper vga_switcheroo_pwr_state() which does just that if runtime PM is used, or falls back to vga_switcheroo's internal power state tracking if manual power control is used. Drop a redundant power state check in set_audio_state() while at it. This removes one of the two purposes of the notification mechanism implemented by vga_switcheroo_set_dynamic_switch(). The other one is power management of the audio device and we'll remove that next. Cc: Dave Airlie <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
Lukas Wunner authored
When cutting power to a GPU and its integrated HDA controller, their cached current_state should be updated to D3cold to reflect reality. We currently rely on the DRM and HDA drivers to do that, however: - The HDA driver updates the current_state in azx_vs_set_state(), which will no longer be called with driver power control once we migrate to device links. (It will still be called with manual power control.) - If the HDA device is not bound, its current_state remains at D0 even though the GPU driver may decide to go to D3cold. - The DRM drivers update the current_state using pci_set_power_state() which can't put the device into a deeper power state than D3hot if the GPU is not deemed power-manageable by the platform (even though it *is* power-manageable by some nonstandard means, such as a _DSM). Centralize updating the current_state of the GPU and HDA controller in vga_switcheroo's ->runtime_suspend hook to overcome these deficiencies. The GPU and HDA controller are two functions of the same PCI device (VGA class device on function 0 and audio device on function 1) and no other PCI devices reside on the same bus since this is a PCIe point-to-point link, so we can just walk the bus and update the current_state of all devices. On ->runtime_resume, the HDA controller is in D0uninitialized state. Resume to D0active and then let it autosuspend as it sees fit. Note that vga_switcheroo_init_domain_pm_ops() is not supposed to be called by hybrid graphics laptops which power down the GPU via its root port's _PR3 resources and consequently vga_switcheroo_runtime_suspend() is not used. On those laptops, the root port is power-manageable by the platform (instead of by a nonstandard means) and the current_state is therefore updated by the PCI core through the following call chain: pci_set_power_state() __pci_complete_power_transition() pci_bus_set_current_state() Resuming to D0active happens through: pci_set_power_state() __pci_start_power_transition() pci_wakeup_bus() Cc: Dave Airlie <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
