Joe Perches [Fri, 16 Mar 2018 20:56:27 +0000 (13:56 -0700)]
drm: Reduce object size of DRM_DEV_<LEVEL> uses
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.
Daniel Vetter [Fri, 16 Mar 2018 07:59:26 +0000 (08:59 +0100)]
drm/doc: Put all driver docs into a separate chapter
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!
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.
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/621
Ville Syrjälä [Tue, 13 Mar 2018 15:07:58 +0000 (17:07 +0200)]
drm: Make drm_mode_vrefresh() a bit more accurate
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.
Ville Syrjälä [Thu, 15 Mar 2018 15:22:41 +0000 (17:22 +0200)]
drm: Verify gamma/degamma LUT size
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
Ville Syrjälä [Fri, 23 Feb 2018 19:25:01 +0000 (21:25 +0200)]
Revert "drm: Use a flexible array member for blob property data"
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.
Chris Zhong [Fri, 16 Feb 2018 12:09:56 +0000 (13:09 +0100)]
drm/rockchip: cdn-dp: remove the DP phy switch
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
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 9aaf880ed4ee ("imx-drm: Add mx6 hdmi transmitter support").
Remove the cable_plugin element and the hdmi_enable_overflow_interrupts()
function that is never called.
Haneen Mohammed [Sun, 11 Mar 2018 23:33:13 +0000 (17:33 -0600)]
drm/vmwgfx: replace drm_*_unreference with drm_*_put
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:
Marc Zyngier [Tue, 20 Feb 2018 13:01:20 +0000 (13:01 +0000)]
drm/rockchip: Don't use spin_lock_irqsave in interrupt context
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.
Marc Zyngier [Tue, 20 Feb 2018 13:01:19 +0000 (13:01 +0000)]
drm/rockchip: Do not use memcpy for MMIO addresses
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.
Marc Zyngier [Tue, 20 Feb 2018 13:01:18 +0000 (13:01 +0000)]
drm/rockchip: Clear all interrupts before requesting the IRQ
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.
zain wang [Fri, 9 Mar 2018 22:22:57 +0000 (23:22 +0100)]
drm/bridge: analogix_dp: Only wait for panel ACK on PSR entry
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: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-7-enric.balletbo@collabora.com
Arnd Bergmann [Tue, 13 Mar 2018 20:59:54 +0000 (21:59 +0100)]
drm/panel: rm68200: Add backlight dependency
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.
zain wang [Fri, 9 Mar 2018 22:22:55 +0000 (23:22 +0100)]
drm/rockchip: add mutex vop lock
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.
zain wang [Fri, 9 Mar 2018 22:22:56 +0000 (23:22 +0100)]
drm/bridge: analogix_dp: add fast link train for eDP
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 <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org>
[dropped header reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-6-enric.balletbo@collabora.com
zain wang [Fri, 9 Mar 2018 22:22:54 +0000 (23:22 +0100)]
drm/bridge: analogix_dp: Don't change psr while bridge is disabled
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: zain wang <wzz@rock-chips.com> 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 <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-4-enric.balletbo@collabora.com
Sean Paul [Fri, 9 Mar 2018 22:22:53 +0000 (23:22 +0100)]
drm/rockchip: Remove analogix psr worker
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: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-3-enric.balletbo@collabora.com
Yakir Yang [Fri, 9 Mar 2018 22:22:52 +0000 (23:22 +0100)]
drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR
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: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-2-enric.balletbo@collabora.com
Giulio Benetti [Tue, 13 Mar 2018 17:54:37 +0000 (18:54 +0100)]
drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
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.
Giulio Benetti [Tue, 13 Mar 2018 11:36:57 +0000 (12:36 +0100)]
drm/sun4i: move rgb mode_valid from connector to encoder
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.
Lukas Wunner [Sat, 3 Mar 2018 09:53:24 +0000 (10:53 +0100)]
drm/nouveau: Runtime suspend despite HDA being unbound
Commit 5addcf0a5f0f ("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 [Sat, 3 Mar 2018 09:53:24 +0000 (10:53 +0100)]
vga_switcheroo: Let HDA autosuspend on mux change
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.
Lukas Wunner [Sat, 3 Mar 2018 09:53:24 +0000 (10:53 +0100)]
vga_switcheroo: Use device link for HDA controller
Back in 2013, runtime PM for GPUs with integrated HDA controller was
introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver
control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime
suspend/resume on optimus support (v4)").
Briefly, the idea was that the HDA controller is forced on and off in
unison with the GPU.
The original code is mostly still in place even though it was never a
100% perfect solution: E.g. on access to the HDA controller, the GPU
is powered up via vga_switcheroo_runtime_resume_hdmi_audio() but there
are no provisions to keep it resumed until access to the HDA controller
has ceased: The GPU autosuspends after 5 seconds, rendering the HDA
controller inaccessible.
Additionally, a kludge is required when hda_intel.c probes: It has to
check whether the GPU is powered down (check_hdmi_disabled()) and defer
probing if so.
However in the meantime (in v4.10) the driver core has gained a feature
called device links which promises to solve such issues in a clean way:
It allows us to declare a dependency from the HDA controller (consumer)
to the GPU (supplier). The PM core then automagically ensures that the
GPU is runtime resumed as long as the HDA controller's ->probe hook is
executed and whenever the HDA controller is accessed.
By default, the HDA controller has a dependency on its parent, a PCIe
Root Port. Adding a device link creates another dependency on its
sibling:
PCIe Root Port
^ ^
| |
| |
HDA ===> GPU
The device link is not only used for runtime PM, it also guarantees that
on system sleep, the HDA controller suspends before the GPU and resumes
after the GPU, and on system shutdown the HDA controller's ->shutdown
hook is executed before the one of the GPU. It is a complete solution.
Using this functionality is as simple as calling device_link_add(),
which results in a dmesg entry like this:
pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0
The code for the GPU-governed audio power management can thus be removed
(except where it's still needed for legacy manual power control).
The device link is added in a PCI quirk rather than in hda_intel.c.
It is therefore legal for the GPU to runtime suspend to D3cold even if
the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
is not enabled, for accesses to the HDA controller will cause the GPU to
wake up regardless if they're occurring outside of hda_intel.c (think
config space readout via sysfs).
Contrary to the previous implementation, the HDA controller's power
state is now self-governed, rather than GPU-governed, whereas the GPU's
power state is no longer fully self-governed. (The HDA controller needs
to runtime suspend before the GPU can.)
It is thus crucial that runtime PM is always activated on the HDA
controller even if CONFIG_SND_HDA_POWER_SAVE_DEFAULT is set to 0 (which
is the default), lest the GPU stays awake. This is achieved by setting
the auto_runtime_pm flag on every codec and the AZX_DCAPS_PM_RUNTIME
flag on the HDA controller.
A side effect is that power consumption might be reduced if the GPU is
in use but the HDA controller is not, because the HDA controller is now
allowed to go to D3hot. Before, it was forced to stay in D0 as long as
the GPU was in use. (There is no reduction in power consumption on my
Nvidia GK107, but there might be on other chips.)
The code paths for legacy manual power control are adjusted such that
runtime PM is disabled during power off, thereby preventing the PM core
from resuming the HDA controller.
Note that the device link is not only added on vga_switcheroo capable
systems, but for *any* GPU with integrated HDA controller. The idea is
that the HDA controller streams audio via connectors located on the GPU,
so the GPU needs to be on for the HDA controller to do anything useful.
This commit implicitly fixes an unbalanced runtime PM ref upon unbind of
hda_intel.c: On ->probe, a runtime PM ref was previously released under
the condition "azx_has_pm_runtime(chip) || hda->use_vga_switcheroo", but
on ->remove a runtime PM ref was only acquired under the first of those
conditions. Thus, binding and unbinding the driver twice on a
vga_switcheroo capable system caused the runtime PM refcount to drop
below zero. The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag
is now always set if use_vga_switcheroo is true.
For more information on device links please refer to:
https://www.kernel.org/doc/html/latest/driver-api/device_link.html
Documentation/driver-api/device_link.rst
Cc: Dave Airlie <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: 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/51bd38360ff502a8c42b1ebf4405ee1d3f27118d.1520068884.git.lukas@wunner.de
Lukas Wunner [Sat, 3 Mar 2018 09:53:24 +0000 (10:53 +0100)]
vga_switcheroo: Deduplicate power state tracking
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 [Sat, 3 Mar 2018 09:53:24 +0000 (10:53 +0100)]
vga_switcheroo: Update PCI current_state on power change
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:
Lukas Wunner [Sat, 3 Mar 2018 09:53:24 +0000 (10:53 +0100)]
PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public
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.
PCI: Restore config space on runtime resume despite being unbound
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.
Neil Armstrong [Tue, 13 Mar 2018 10:07:50 +0000 (11:07 +0100)]
drm/meson: Add support for DMT modes on HDMI
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.
Wei Yongjun [Wed, 3 Jan 2018 03:08:58 +0000 (03:08 +0000)]
drm/panel: ili9322: Make local symbols static
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.
Philippe CORNU [Mon, 5 Feb 2018 09:45:32 +0000 (10:45 +0100)]
drm/panel: otm8009a: Add support for the optional power-supply
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.
Sean Paul [Thu, 8 Feb 2018 17:48:52 +0000 (12:48 -0500)]
drm/panel: simple: Use display_timing for lq123p1jx31
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: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-6-seanpaul@chromium.org
Sean Paul [Thu, 8 Feb 2018 17:48:48 +0000 (12:48 -0500)]
dt-bindings: Clarify timing subnode use as panel-timing
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: Sean Paul <seanpaul@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-2-seanpaul@chromium.org
Eric Anholt [Fri, 9 Mar 2018 23:33:32 +0000 (15:33 -0800)]
drm/panel: simple: Fix the bus format for the Ontat panel
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.
Stefan Schake [Fri, 9 Mar 2018 00:53:35 +0000 (01:53 +0100)]
drm/vc4: Check if plane requires background fill
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
Sean Paul [Mon, 5 Mar 2018 22:22:54 +0000 (23:22 +0100)]
drm/rockchip: Don't use atomic constructs for psr
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: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@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 [Mon, 5 Mar 2018 22:22:53 +0000 (23:22 +0100)]
drm/rockchip: analogix_dp: set psr activate/deactivate when enable/disable bridge
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: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180305222324.5872-2-enric.balletbo@collabora.com
Jeffy Chen [Fri, 2 Mar 2018 17:57:56 +0000 (18:57 +0100)]
drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind()
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().
Jeffy Chen [Fri, 2 Mar 2018 17:57:55 +0000 (18:57 +0100)]
drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind
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.
Jeffy Chen [Fri, 2 Mar 2018 17:57:53 +0000 (18:57 +0100)]
drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup.
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.
Ville Syrjälä [Tue, 20 Feb 2018 13:48:16 +0000 (15:48 +0200)]
drm/nouveau: Replace the iturbt_709 prop with the standard COLOR_ENCODING prop
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180220134816.15229-1-ville.syrjala@linux.intel.com Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Acked-by: Ben Skeggs <bskeggs@redhat.com> #irc
Linus Walleij [Wed, 7 Mar 2018 21:58:19 +0000 (22:58 +0100)]
drm/pl111: Use max memory bandwidth for resolution
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.
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.
Linus Walleij [Fri, 2 Mar 2018 09:09:47 +0000 (10:09 +0100)]
drm/pl111: Handle the RealView variant separately
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.
Linus Walleij [Fri, 2 Mar 2018 09:09:45 +0000 (10:09 +0100)]
drm/pl111: Make the default BPP a per-variant variable
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.
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.
Shirish S [Wed, 7 Mar 2018 03:10:03 +0000 (08:40 +0530)]
drm/atomic: Add new reverse iterator over all plane state (V2)
Add reverse iterator for_each_oldnew_plane_in_state_reverse to
compliment the for_each_oldnew_plane_in_state way or reading plane
states.
The plane states are required to be read in reverse order for
amd drivers, cause the z order convention followed in linux is
opposite to how the planes are supposed to be presented to DC
engine, which is in common to both windows and linux.
Ville Syrjälä [Tue, 6 Mar 2018 16:48:49 +0000 (18:48 +0200)]
drm: Reject bad property flag combinations
Pimp drm_property_type_valid() to check for more fails with the
property flags. Also make the check before adding the property,
and bail out if things look bad.
Since we're now chekcing for more than the type let's also
change the function name to drm_property_flags_valid().
Ville Syrjälä [Tue, 6 Mar 2018 16:48:47 +0000 (18:48 +0200)]
drm/uapi: Deprecate DRM_MODE_PROP_PENDING
DRM_MODE_PROP_PENDING is not used anywhere (except printed out
by libdrm proptest/modetest).
This seems to be yet another thing blindly copied from xrandr.
Quoting from the protocol spec:
"If 'pending' is TRUE, changes made to property values with
RRChangeOutputProperty will be saved in the pending property value
and be automatically copied to the current value on the next
RRSetCrtcConfig request involving the named output. If 'pending' is
FALSE, changes are copied immediately."
So it was some kind of early idea for atomic property updates.
If there is another bridge after analogix_dp, then the connector object
should not be created. This fixes following timeouts on Exynos5420-based
Chromebook2 Peach-PIT board during boot:
exynos-dp 145b0000.dp-controller: AUX CH cmd reply timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
This oops happens, because analogix_dp_bind() calls drm_dp_aux_register()
which registers i2c adapter. I2C core tries to runtime get i2c host
device during registration. This ends in analogix_dp_resume(), but dp
context is NULL there. dp context is set in exynos_dp_bind() after
executing analogix_dp_bind(). Fix this issue by postponing enabling runtime
power management after drm_dp_aux_register().
zain wang [Mon, 5 Mar 2018 08:57:39 +0000 (09:57 +0100)]
drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind
The bridge does not need to be powered in analogix_dp_bind(), so
remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
as well as their power-off counterparts.
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>
[the patch originally just removed the power_on portion, seanpaul removed
the power off code as well as improved the commit message] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180305085741.18896-2-m.szyprowski@samsung.com
Ville Syrjälä [Fri, 2 Mar 2018 14:03:00 +0000 (16:03 +0200)]
drm: Check property/enum name length
Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.
The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
identified needing this workaround.
This patch adds the corresponding version to enable a single iteration for
this specific version.
Joe Moriarty [Tue, 20 Feb 2018 19:11:57 +0000 (14:11 -0500)]
drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer dereference problem.
- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered. The
return of NULL was removed with BUG() from drm_minor_get_slot().
Joe Moriarty [Tue, 20 Feb 2018 19:11:56 +0000 (14:11 -0500)]
drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.
- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from calls to
drm_crtc_from_index(). There is a possibility, however minute, that
crtc->index may not be found when trying to find the struct crtc
from it's assigned index given in drm_crtc_init_with_planes().
3 return checks for NULL where added with a call to
WARN_ON(!crtc).
Ville Syrjälä [Tue, 23 Jan 2018 17:08:55 +0000 (19:08 +0200)]
drm/armada: Construct a temporary crtc state for plane checks
As armada isn't an atomic driver trying to pass a non-populated
crtc->state to drm_atomic_helper_check_plane_state() will end in tears.
Construct a temporary crtc state a la drm_plane_helper_check_update()
and pass that instead. For now we just really need crtc_state->enable
to be there.
Daniel Stone [Tue, 8 Aug 2017 16:44:48 +0000 (17:44 +0100)]
drm/vc4: Advertise supported modifiers for planes
The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.
v2:
- Only advertise T_TILED for RGB (Eric)
- Actually turn on allow_fb_modifiers (Eric)
Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/170828/
Ville Syrjälä [Wed, 14 Feb 2018 19:23:27 +0000 (21:23 +0200)]
drm/i915: Add support for the YCbCr COLOR_RANGE property
Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.
On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program the color
correction logic to pass the data through unmodified.
v2: Rebase
Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-9-ville.syrjala@linux.intel.com
projects / mirror_ubuntu-hirsute-kernel.git / log