This patch adds compatible strings for the remaining documented
components of the Allwinner A80 display pipeline.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180315114136.24747-5-wens@csie.org
The Allwinner A80 SoC has 2 documented TCONs. The display pipeline
diagram from the user manual shows a third TCON, but it's missing
an interrupt line, and its registers are not explained either.
It's also not used in Allwinner's vendor BSP.
The first TCON only has channel 0, for LCD panel output. The TCON
hardware setup is peculiar in that the eDP reset must also be
deasserted to allow access to the TCON. How the eDP module is wired
in the SoC itself is never explained.
The second TCON only has channel 1, and its output is connected to
the HDMI encoder block.
This patch adds a "needs_edp_reset" field to the tcon quirks structure,
and adds quirks and compatible strings for the 2 documented TCONs.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180315114136.24747-4-wens@csie.org
The display pipeline on the A80 SoC has what is called the Detail
Enhancement Unit, or DEU for short, block in between the display
frontend and backend. This unit can sharpen images in both luma
and chroma channels. It seems to also do colorspace conversion.
This patch adds the device tree binding for this hardware block.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180315114136.24747-3-wens@csie.org
The A80 has 2 or 3 TCONs. The documentation and vendor kernel are very
vague about the third TCON, to the point that it might not exist.
In the documentation, the first TCON is missing channel 1, and the
second is missing channel 0. However the vendor kernel seems to be
able to use them regardless. Here we model them like the old TCONs.
An oddity is that TCON0 requires the reset control for the eDP block
to be deasserted, for any register access to stick.
This patch adds compatible strings for TCON0 and TCON1, with TCON0
requiring an extra "edp" reset control.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180315114136.24747-2-wens@csie.org
These macros are similar to the DRM_<LEVEL> with the addition
of a struct device * to the arguments.
Convert the single drm_dev_printk function into 2 separate functions.
drm_dev_printk with a KERN_<LEVEL> * for generic use and drm_dev_dbg
for conditional masked use.
Remove the __func__ argument and use __builtin_return_address(0) to be
similar to the DRM_<LEVEL> macros uses.
Convert the DRM_DEV_<LEVEL> macros to remove now unnecessary arguments
and use a consistent style.
These macros are rarely used in the generic gpu/drm code so the code
size does not change much for a defconfig, but when more drivers are
enabled, there is ~4k savings.
Many of these macros have no existing use at all.
$ size -t drivers/gpu/drm/built-in.a | tail -1
1877530 44651 995 1923176 1d5868 (TOTALS)
$ size -t drivers/gpu/drm/built-in.a | tail -1
1877527 44651 995 1923173 1d5865 (TOTALS)
$ size -t drivers/gpu/drm/built-in.a | tail -1
17166750 2689238 108352 19964340 130a1b4 (TOTALS)
$ size -t drivers/gpu/drm/built-in.a | tail -1
17168888 2691734 108352 19968974 130b3ce (TOTALS)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/e5c164946e15375ac71b69b75f296efdf0b76e6d.1521233717.git.joe@perches.com
We have quite a few driver docs now, which is great, but having them
all in the top-level gpu documentation chapter makes it harder to spot
the core/shared bits.
Stuff them into a separate chapter and ecourage people to add even
more!
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316075926.13584-1-daniel.vetter@ffwll.ch
This patch remove the compatibility aliases
drm_mode_object_{reference/unreference} of drm_mode_object_{get/put}
since all callers have been converted to the prefered _{get/put}.
Remove the helpers from the semantic patch drm-get-put-cocci.
Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180319055820.GA17502@haneen-VirtualBox
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
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180313143151.GA27486@embeddedgus
Do the refresh rate calculation with a single division. This gives
us slightly more accurate results, especially for interlaced since
we don't just double the final truncated result.
We do lose one bit compared to the old way, so with an interlaced
mode the new code can only handle ~2GHz instead of the ~4GHz the
old code handeled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180313150759.27620-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While we want to potentially support multiple different gamma/degamma
LUT sizes we can (and should) at least check that the blob length
is a multiple of the LUT entry size.
v2: s/expected_size_mod/expected_elem_size/ (Daniel)
Add kernel doc (Daniel)
v3: s/we/were/ typo in the docs
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180315152241.7113-1-ville.syrjala@linux.intel.com
Using a flexible array for the blob data was a mistake by me. It
forces all users of the blob data to cast blob->data to something
else. void* is clearly superior so let's go back to the original
scheme.
Not a clean revert as the code has moved.
This reverts commit d63f5e6bf6.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-1-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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
drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
arguments that can be removed by creating separate functins.
Create specific functions for these calls to reduce x86/64 defconfig
size by ~20k.
Modify the existing macros to use the specific calls.
new:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1876562 44542 995 1922099 1d5433 (TOTALS)
old:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1897565 44542 995 1943102 1da63e (TOTALS)
Miscellanea:
o intel_display requires a change to use the specific calls.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/016b5cb84cede20fd0f91ed6965421d99fd5f2ce.1520978414.git.joe@perches.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 9aaf880ed4 ("imx-drm: Add mx6 hdmi transmitter support").
Remove the cable_plugin element and the hdmi_enable_overflow_interrupts()
function that is never called.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> # On R-Car H3
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1518812170-22687-1-git-send-email-festevam@gmail.com
This patch replace instances of drm_framebuffer_unreference with _put()
suffix, because it is shorter and consistent with the kernel use of
*_get/put() suffixes.
This was done with the following Coccinelle script:
@r@
expression e;
@@
(
-drm_framebuffer_reference(e);
+drm_framebuffer_get(e);
|
-drm_framebuffer_unreference(e);
+drm_framebuffer_put(e);
)
Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
Acked-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180311233313.GA19721@Haneen
The rockchip DRM driver is quite careful to disable interrupts
when taking a lock that is also taken in interrupt context,
which is a good thing.
What is a bit over the top is to use spin_lock_irqsave when
already in interrupt context, as you cannot take another
interrupt again, and disabling interrupt is just pure
overhead.
Switching to the non _irqsave version in interrupt context is
more logical, and less heavy handed.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-4-marc.zyngier@arm.com
memcpy is only meant to be used for memory, and only that.
MMIO accessors should be used to access MMIO regions, preferably
the ones that correspond to the size of the register accessed.
Let's convert the bulk register copy to writel/readl_relaxed,
which is the correct API.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-3-marc.zyngier@arm.com
Calling request_irq() followed by disable_irq() is usually a bad idea,
specially if the interrupt can be pending, and you're not yet in a
position to handle it.
This is exactly what happens on my kevin system when rebooting in a
second kernel using kexec: Some interrupt is left pending from
the previous kernel, and we take it too early, before disable_irq()
could do anything.
Let's clear the pending interrupts as we initialize the HW, and move
the interrupt request after that point. This ensures that we're in
a sane state when the interrupt is requested.
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
[adapted to recent rockchip-drm changes]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-2-marc.zyngier@arm.com
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
Like many other panel drivers, this one fails to build when backlight
support is disabled:
drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
panel-raydium-rm68200.c:(.text+0x14a): undefined reference to `devm_of_find_backlight'
This adds the appropriate dependency.
Note that while include/linux/backlight.h provides a stub inline when
backlight support is not enabled, this isn't enough to deal with the
case where backlight support is built as a module but the panel driver
is built-in, in which case linking will still fail as above.
One way to avoid this is to add a dependency such as this:
depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
but that is rather complex and misses the point that the panel support
is mostly useless without backlight support.
Fixes: 2b7ed18bed ("drm/panel: Add support for Raydium RM68200 panel driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[treding@nvidia.com: clarify the need for the dependency]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180313210015.3344380-1-arnd@arndb.de
Add a lock to vop to avoid disabling the crtc while waiting for a line
flag while enabling psr. If we disable in the middle of waiting for the
line flag, we'll end up timing out or worse.
Signed-off-by: zain wang <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>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-5-enric.balletbo@collabora.com
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
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
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
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
Handle both positive and negative dclk polarity,
according to bus_flags, taking care of this:
On A20 and similar SoCs, the only way to achieve Positive Edge
(Rising Edge), is setting dclk clock phase to 2/3(240°).
By default TCON works in Negative Edge(Falling Edge), this is why phase
is set to 0 in that case.
Unfortunately there's no way to logically invert dclk through IO_POL
register.
The only acceptable way to work, triple checked with scope,
is using clock phase set to 0° for Negative Edge and set to 240° for
Positive Edge.
On A33 and similar SoCs there would be a 90° phase option, but it divides
also dclk by 2.
This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers
for using A33 90° phase divided by 2 and consequently increase code
complexity.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1520963677-124239-1-git-send-email-giulio.benetti@micronovasrl.com
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: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1520941017-81177-1-git-send-email-giulio.benetti@micronovasrl.com
Commit 5addcf0a5f ("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
When switching the display on muxed machines, we currently force the HDA
controller into runtime suspend on the previously used GPU and into
runtime active state on the newly used GPU.
That's unnecessary if the GPU uses driver power control, we can just let
the audio device autosuspend or autoresume as it sees fit.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/098ed883460eb4976a899eac6f5192fefc877c0f.1520068884.git.lukas@wunner.de
Back in 2013, runtime PM for GPUs with integrated HDA controller was
introduced with commits 0d69704ae3 ("gpu/vga_switcheroo: add driver
control power feature. (v3)") and 246efa4a07 ("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
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
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: 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/8416958482c8c42d6f311ea5c1e5a65ccf21f5db.1520068884.git.lukas@wunner.de
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: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/2962443259e7faec577274b4ef8c54aad66f9a94.1520068884.git.lukas@wunner.de
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: Bjorn 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[lukas: add commit message, bikeshed code comments for clarity]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.de
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
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
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: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1514948938-19996-1-git-send-email-weiyongjun1@huawei.com
Chen-Yu Tsai