- 13 Mar, 2018 8 commits
-
-
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:
Peter Wu <peter@lekensteyn.nl> Tested-by: Kai Heng Feng <kai.heng.feng@canonical.com> # AMD PowerXpress Tested-by: Mike Lothian <mike@fireburn.co.uk> # AMD PowerXpress 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/0aa49d735b988aa04524a8dc339582ace33f0f94.1520068884.git.lukas@wunner.de
-
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:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-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 6 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:
-
Linus Walleij authored
This fixes up the .mode_valid() vtable entry documentation by copyediting the documentation from the .mode_valid() documentation in the drm_modeset_helper_vtables.h file. Fixes: 40275dc4 ("drm: simple_kms_helper: Add mode_valid() callback support") Suggested-by:
-
Linus Walleij authored
It's better if we explain a bit that this pertains to non-programmable VGA DAC bridges. Reviewed-by:
-
