- 14 3月, 2018 15 次提交
-
-
由 zain wang 提交于
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: Nzain wang <wzz@rock-chips.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Escande <thierry.escande@collabora.com> Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-5-enric.balletbo@collabora.com
-
由 zain wang 提交于
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: Nzain wang <wzz@rock-chips.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Escande <thierry.escande@collabora.com> Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> [dropped header reordering] Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-6-enric.balletbo@collabora.com
-
由 zain wang 提交于
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: Nzain wang <wzz@rock-chips.com> Signed-off-by: NCaesar Wang <wxt@rock-chips.com> [seanpaul fixed up the commit message a bit and renamed *_supported to *_enabled] Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Escande <thierry.escande@collabora.com> Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-4-enric.balletbo@collabora.com
-
由 Sean Paul 提交于
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: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Escande <thierry.escande@collabora.com> Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-3-enric.balletbo@collabora.com
-
由 Yakir Yang 提交于
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: NYakir Yang <ykk@rock-chips.com> [seanpaul changed timeout loop to a readx poll] Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Escande <thierry.escande@collabora.com> Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-2-enric.balletbo@collabora.com
-
由 Giulio Benetti 提交于
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: NGiulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520963677-124239-1-git-send-email-giulio.benetti@micronovasrl.com
-
由 Giulio Benetti 提交于
mode_valid function is missing for lvds. Add it making it pointed by encoder helper functions. Signed-off-by: NGiulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520940019-68977-1-git-send-email-giulio.benetti@micronovasrl.com
-
由 Giulio Benetti 提交于
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: NGiulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520941017-81177-1-git-send-email-giulio.benetti@micronovasrl.com
-
由 Lukas Wunner 提交于
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: NPeter 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: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/77e0ab74f3377ea9b6acf8fab624acfb4f7dbeca.1520068884.git.lukas@wunner.de
-
由 Lukas Wunner 提交于
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: NPeter Wu <peter@lekensteyn.nl> Signed-off-by: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/098ed883460eb4976a899eac6f5192fefc877c0f.1520068884.git.lukas@wunner.de
-
由 Lukas Wunner 提交于
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: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NPeter 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: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/51bd38360ff502a8c42b1ebf4405ee1d3f27118d.1520068884.git.lukas@wunner.de
-
由 Lukas Wunner 提交于
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: NPeter 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: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/0aa49d735b988aa04524a8dc339582ace33f0f94.1520068884.git.lukas@wunner.de
-
由 Lukas Wunner 提交于
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: NPeter 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: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/8416958482c8c42d6f311ea5c1e5a65ccf21f5db.1520068884.git.lukas@wunner.de
-
由 Lukas Wunner 提交于
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: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/2962443259e7faec577274b4ef8c54aad66f9a94.1520068884.git.lukas@wunner.de
-
由 Rafael J. Wysocki 提交于
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: NBjorn Helgaas <bhelgaas@google.com> Tested-by: Peter Wu <peter@lekensteyn.nl> # Nvidia Optimus Tested-by: Lukas Wunner <lukas@wunner.de> # MacBook Pro Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> [lukas: add commit message, bikeshed code comments for clarity] Signed-off-by: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.de
-
- 13 3月, 2018 5 次提交
-
-
由 Neil Armstrong 提交于
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: NJerome Brunet <jbrunet@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520935670-14187-1-git-send-email-narmstrong@baylibre.com
-
由 Christophe JAILLET 提交于
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: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/df47e03d36c2cf7bc37ec3105fc47c16555bd946.1520885192.git.christophe.jaillet@wanadoo.fr
-
由 Christophe JAILLET 提交于
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: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/d4ce46077d3ada7149c4555acfdda8ade4a6cf50.1520885192.git.christophe.jaillet@wanadoo.fr
-
由 Christophe JAILLET 提交于
'drm_vblank_init()' can fail. So handle this (unlikely) error. Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/6cbf3d70ac3904489c7194c895225c4103aebb96.1520885192.git.christophe.jaillet@wanadoo.fr
-
由 Ville Syrjälä 提交于
Put an empty line between the variable declarations and the code, and use tabs for alignment. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180305144919.2881-3-ville.syrjala@linux.intel.comAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 3月, 2018 14 次提交
-
-
由 Christoph Fritz 提交于
This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM simple panel driver. Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com> Signed-off-by: NStefan Riedmueller <s.riedmueller@phytec.de> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1513430016.1930.4.camel@googlemail.com
-
由 Wei Yongjun 提交于
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: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1514948938-19996-1-git-send-email-weiyongjun1@huawei.com
-
由 jan.tuerk@emtrion.com 提交于
emtrion is a system integrator and manufacturer of embedded systems. Website: https://www.emtrion.deSigned-off-by: NJan Tuerk <jan.tuerk@emtrion.com> Reviewed-by: NAndreas Färber <afaerber@suse.de> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123125600.41562-3-jan.tuerk@emtrion.com
-
由 Philippe CORNU 提交于
Add SPDX identifiers to OriseTech OTM8009a panel driver. Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119110516.4916-1-philippe.cornu@st.com
-
由 Baruch Siach 提交于
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NBaruch Siach <baruch@tkos.co.il> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/f80a5dd350b057d925d36f5857b5724c88da50df.1516636902.git.baruch@tkos.co.il
-
由 Jagan Teki 提交于
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: NJagan Teki <jagan@amarulasolutions.com> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1517766571-409-5-git-send-email-jagan@amarulasolutions.com
-
由 Philippe CORNU 提交于
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: NPhilippe Cornu <philippe.cornu@st.com> Reviewed-by: NYannick Fertré <yannick.fertre@st.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205094532.23547-3-philippe.cornu@st.com
-
由 Philippe CORNU 提交于
Some boards use a dedicated voltage regulator for this panel. Add & document this related optional power-supply property. Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com> Reviewed-by: NYannick Fertré <yannick.fertre@st.com> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205094532.23547-2-philippe.cornu@st.com
-
由 Sean Paul 提交于
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: NSean Paul <seanpaul@chromium.org> Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-6-seanpaul@chromium.org
-
由 Sean Paul 提交于
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: NSean Paul <seanpaul@chromium.org> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-3-seanpaul@chromium.org
-
由 Sean Paul 提交于
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: NSean Paul <seanpaul@chromium.org> Reviewed-by: NRob Herring <robh@kernel.org> Acked-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-2-seanpaul@chromium.org
-
由 Philippe CORNU 提交于
This patch adds Raydium Semiconductor Corporation RM68200 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode). Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302153222.4377-3-philippe.cornu@st.com
-
由 Philippe CORNU 提交于
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD panel connected using a MIPI-DSI video interface. Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302153222.4377-2-philippe.cornu@st.com
-
由 Eric Anholt 提交于
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: NEric 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: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180309233332.1769-1-eric@anholt.net
-
- 10 3月, 2018 4 次提交
-
-
由 Stefan Schake 提交于
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: NStefan Schake <stschake@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net> Reviewed-by: NEric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-5-git-send-email-stschake@gmail.com
-
由 Stefan Schake 提交于
We need to reference it from the CRTC to make a decision for enabling background color fill. Signed-off-by: NStefan Schake <stschake@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net> Reviewed-by: NEric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-4-git-send-email-stschake@gmail.com
-
由 Stefan Schake 提交于
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: NStefan Schake <stschake@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net> Reviewed-by: NEric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-3-git-send-email-stschake@gmail.com
-
由 Stefan Schake 提交于
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: NStefan Schake <stschake@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net> Reviewed-by: NEric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-2-git-send-email-stschake@gmail.com
-
- 09 3月, 2018 2 次提交
-
-
由 Sean Paul 提交于
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: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Escande <thierry.escande@collabora.com> Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180305222324.5872-3-enric.balletbo@collabora.com
-
由 zain wang 提交于
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: Nzain wang <wzz@rock-chips.com> Signed-off-by: NCaesar Wang <wxt@rock-chips.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Escande <thierry.escande@collabora.com> Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180305222324.5872-2-enric.balletbo@collabora.com
-