- 13 Mar, 2018 10 commits
-
-
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:
Peter Wu <peter@lekensteyn.nl> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/098ed883460eb4976a899eac6f5192fefc877c0f.1520068884.git.lukas@wunner.de
-
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: -
Lukas Wunner authored
There are PCI devices which are power-manageable by a nonstandard means, such as a custom ACPI method. One example are discrete GPUs in hybrid graphics laptops, another are Thunderbolt controllers in Macs. Such devices can't be put into D3cold with pci_set_power_state() because pci_platform_power_transition() fails with -ENODEV. Instead they're put into D3hot by pci_set_power_state() and subsequently into D3cold by invoking the nonstandard means. However as a consequence the cached current_state is incorrectly left at D3hot. What we need to do is walk the hierarchy below such a PCI device on powerdown and update the current_state to D3cold. On powerup the PCI device itself and the hierarchy below it is in D0uninitialized, so we need to walk the hierarchy again and wake all devices, causing them to be put into D0active and then letting them autosuspend as they see fit. To this end make pci_wakeup_bus() & pci_bus_set_current_state() public so PCI drivers don't have to reinvent the wheel. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
-
Rafael J. Wysocki authored
We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child goes to D3cold, its internal state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost. One example are recent hybrid graphics laptops which cut power to the discrete GPU when the root port above it goes to ACPI power state D3. Users may provoke this by unbinding the GPU driver and allowing runtime PM on the GPU via sysfs: The PM core will then treat the GPU as "suspended", which in turn allows the root port to runtime suspend, causing the power resources listed in its _PR3 object to be powered off. The GPU's BARs will be uninitialized when a driver later probes it. Another example are hybrid graphics laptops where the GPU itself (rather than the root port) is capable of runtime suspending to D3cold. If the GPU's integrated HDA controller is not bound and the GPU's driver decides to runtime suspend to D3cold, the HDA controller's BARs will be uninitialized when a driver later probes it. Fix by saving and restoring config space over a runtime suspend cycle even if the device is not bound. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> [lukas: add commit message, bikeshed code comments for clarity] Signed-off-by:
-
Neil Armstrong authored
This patch adds support for DMT display modes over HDMI. The modes timings configurations are from the Amlogic Vendor linux tree and tested over multiples monitors. Previously only a selected number of CEA modes were supported. Only these following modes are supported with these changes: - 640x480@60Hz - 800x600@60Hz - 1024x768@60Hz - 1152x864@75Hz - 1280x1024@60Hz - 1600x1200@60Hz - 1920x1080@60Hz The associated code to handle the clock rates is also added. Acked-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520935670-14187-1-git-send-email-narmstrong@baylibre.com
-
Christophe JAILLET authored
If one of these functions fail, we whould free 'drm', as alreadry done in the other error handling paths, below and above. Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
-
Christophe JAILLET authored
According to 'drivers/gpu/drm/drm_drv.c', 'drm_dev_unref()' is just a compatibility alias for 'drm_dev_put()'. So use the latter instead. Signed-off-by:
-
Christophe JAILLET authored
'drm_vblank_init()' can fail. So handle this (unlikely) error. Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by:
-
- 12 Mar, 2018 15 commits
-
-
Ville Syrjälä authored
Put an empty line between the variable declarations and the code, and use tabs for alignment. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180305144919.2881-3-ville.syrjala@linux.intel.comAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Christoph Fritz authored
This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM simple panel driver. Signed-off-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
Stefan Riedmueller <s.riedmueller@phytec.de> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1513430016.1930.4.camel@googlemail.com
-
Wei Yongjun authored
Fixes the following sparse warnings: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:182:12: warning: symbol 'ili9322_inputs' was not declared. Should it be static? drivers/gpu/drm/panel/panel-ilitek-ili9322.c:343:28: warning: symbol 'ili9322_regmap_config' was not declared. Should it be static? Also change ili9322_inputs to 'const char * const' to avoid chackpatch warning. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
jan.tuerk@emtrion.com authored
emtrion is a system integrator and manufacturer of embedded systems. Website: https://www.emtrion.deSigned-off-by:
Jan Tuerk <jan.tuerk@emtrion.com> Reviewed-by:
Andreas Färber <afaerber@suse.de> Acked-by:
-
Philippe CORNU authored
Add SPDX identifiers to OriseTech OTM8009a panel driver. Signed-off-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
-
Baruch Siach authored
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Jagan Teki authored
This adds support for the Kaohsiung Opto-Electronics., TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be supported by the simple panel driver. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
-
Philippe CORNU authored
Add support for the optional power-supply. Note: A "dummy regulator" is returned by devm_regulator_get() if the optional regulator is not present in the device tree, simplifying the source code when enabling/disabling the regulator. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Signed-off-by:
-
Philippe CORNU authored
Some boards use a dedicated voltage regulator for this panel. Add & document this related optional power-supply property. Signed-off-by:
-
Sean Paul authored
Convert the sharp lq123p1jx31 from using a fixed mode to specifying a display timing with min/typ/max values. This allows us to capture the timings set forth in the datasheet as well as the additional values that we've cleared with the display vendor to avoid interference with the digitizer on the Samsung Chromebook Plus (kevin). A follow-on patch will specify the override mode for kevin devices. Changes in v2: - None Changes in v3: - None Cc: Doug Anderson <dianders@chromium.org> Cc: Eric Anholt <eric@anholt.net> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: devicetree@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-rockchip@lists.infradead.org Signed-off-by:
Sean Paul <seanpaul@chromium.org> Tested-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Sean Paul authored
In preparation for a new subnode section in a follow-on patch, add explicit headings to the existings sections for simple-panel. Changes in v2: - Added Changes in v3: - None Cc: Doug Anderson <dianders@chromium.org> Cc: Eric Anholt <eric@anholt.net> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: devicetree@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-rockchip@lists.infradead.org Signed-off-by:
-
Sean Paul authored
Add a note in the documentation explaining when it's appropriate to use the display-timings subnode on its own, as well as the preferred name to use (panel-timing). Changes in v3: - Added Cc: Doug Anderson <dianders@chromium.org> Cc: Eric Anholt <eric@anholt.net> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: devicetree@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-rockchip@lists.infradead.org Signed-off-by:
-
Philippe CORNU authored
This patch adds Raydium Semiconductor Corporation RM68200 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode). Signed-off-by:
-
Philippe CORNU authored
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD panel connected using a MIPI-DSI video interface. Reviewed-by:
-
Eric Anholt authored
This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel. Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: e8b6f561 ("drm/panel: simple: Add the 7" DPI panel from Adafruit") Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
- 09 Mar, 2018 4 commits
-
-
Stefan Schake authored
Using the hint from the plane state, we turn on the background color to avoid display corruption from planes blending with the background. Changes from v1: - Use needs_bg_fill from plane state Signed-off-by:
Stefan Schake <stschake@gmail.com> Signed-off-by:
-
Stefan Schake authored
We need to reference it from the CRTC to make a decision for enabling background color fill. Signed-off-by:
-
Stefan Schake authored
Considering a single plane only, we have to enable background color when the plane has an alpha format and could be blending from the background or when it doesn't cover the entire screen. Changes from v1: - Drop unrelated change - Move needs_bg_fill to plane state Signed-off-by:
-
Stefan Schake authored
Alpha formats in DRM are assumed to be premultiplied, so we should be setting the PREMULT bit in the plane configuration for HVS. Changes from v1: - Use correct has_alpha Signed-off-by:
-
- 08 Mar, 2018 7 commits
-
-
Sean Paul authored
Instead of using timer and spinlocks, use delayed_work and mutexes for rockchip psr. This allows us to make blocking calls when enabling/disabling psr (which is sort of important given we're talking over dpcd to the display). Cc: Caesar Wang <wxt@rock-chips.com> Cc: 征增 王 <wzz@rock-chips.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
Thierry Escande <thierry.escande@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180305222324.5872-3-enric.balletbo@collabora.com
-
zain wang authored
There's a race between when bridge_disable and when vop_crtc_disable are called. If the flush timer triggers a new psr work between these, we will operate eDP without power shutdowned by bridge_disable. In this case, moving activate/deactivate to enable/disable bridge to avoid it. Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
zain wang <wzz@rock-chips.com> Signed-off-by:
Caesar Wang <wxt@rock-chips.com> Signed-off-by:
-
Jeffy Chen authored
The HDMI vpll clock should be enabled when bind() is called. So move the clk_prepare_enable of that clock to bind() function and add the missing clk_disable_unprepare() required in error handling path and unbind(). Fixes: 12b9f204 ("drm: bridge/dw_hdmi: add rockchip rk3288 support") Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by:
-
Jeffy Chen authored
In bind the clk_prepare_enable of the HDMI pclk is called before adding the i2c_adapter. So it should be the other way around in unbind, first remove the i2c_adapter and then call the clk_disable_unprepare. Fixes: 412d4ae6 ("drm/rockchip: hdmi: add Innosilicon HDMI support") Signed-off-by:
-
Jeffy Chen authored
Add missing error handling in bind(). Fixes: 412d4ae6 ("drm/rockchip: hdmi: add Innosilicon HDMI support") Signed-off-by:
-
Jeffy Chen authored
In bind()'s error handling path call destroy functions instead of cleanup functions for encoder and connector and reorder to match how is called in bind(). In unbind() call the connector and encoder destroy functions. Signed-off-by:
-
Ville Syrjälä authored
Replace the ad-hoc iturbt_709 property with the new standard COLOR_ENCODING property. Compiles, but not tested. v2: Fix typos (Ilia) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: nouveau@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Acked-by: Ben Skeggs <bskeggs@redhat.com> #irc
-
- 07 Mar, 2018 4 commits
-
-
Linus Walleij authored
We were previously selecting 1024x768 and 32BPP as the default set-up for the PL111 consumers. This does not work on elder systems: the device tree bindings support a property "max-memory-bandwidth" in bytes/second that states that if you exceed this the memory bus will saturate. The result is flickering and unstable images. Parse the "max-memory-bandwidth" and respect it when intializing the driver. On the RealView PB11MP, Versatile and Integrator/CP we get a nice console as default with this code. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180307215819.15814-1-linus.walleij@linaro.org
-
Linus Walleij authored
The following happens when connection a DVI output driven from the SiI9022 using a DVI-to-VGA adapter plug: i2c i2c-0: sendbytes: NAK bailout. i2c i2c-0: sendbytes: NAK bailout. Then no picture. Apparently the I2C engine inside the SiI9022 is not smart enough to try to fall back to DDC I2C. Or the vendor have not integrated the electronics properly. I don't know which one it is. After this, the I2C bus seems stalled and the first attempt to read the status register fails, and the code returns with negative return value, and the display fails to initialized. Instead, retry status readout five times and continue even if this fails. Tested on the ARM Versatile Express with a DVI-to-VGA connector, it now gives picture. Introduce a helper struct device *dev variable to make the code more readable. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Linus Walleij authored
We want to cut down the default bpp to 16 on the RealView so we can have a 1024x768 framebuffer console by default. The memory bandwidth limitations makes this not work with the PL111 default of 32bpp. This builds on top of the earlier patches making the framebuffer default bpp a per-variant variable. Reviewed-by:
-
Linus Walleij authored
The PL110, Integrator and Versatile boards strongly prefer to use 16 BPP even if other modes are supported, both to keep down memory consumption and also to easier find a good match to supported resolutions with consideration taken to the memory bandwidth of the platforms. Reviewed-by:
-
