Just a few small fixes for 4.13.
* 'drm-fixes-4.13' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: Use list_del_init in amdgpu_mn_unregister
drm/amdgpu: Fix undue fallthroughs in golden registers initialization
drm/amdgpu: fix header on gfx9 clear state
Otherwise bo->shadow_list (which is aliased by bo->mn_list) will not
appear empty in amdgpu_ttm_bo_destroy and cause an oops when freeing
former userptr BOs.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As I was staring at the si_init_golden_registers code, I noticed that
the Pitcairn initialization silently falls through the Cape Verde
initialization, and the Oland initialization falls through the Hainan
initialization. However there is no comment stating that this is
intentional, and the radeon driver doesn't have any such fallthrough,
so I suspect this is not supposed to happen.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: 62a3755341 ("drm/amdgpu: add si implementation v10")
Cc: Ken Wang <Qingqing.Wang@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Marek Olšák" <maraeo@gmail.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
i915 fixes for -rc3
Bit more than usual since we missed -rc2. 4x cc: stable, 2 gvt
patches, but all fairly minor stuff. Last minute rebase was to add a
few missing cc: stable, I did prep the pull this morning already and
made sure CI approves.
* tag 'drm-intel-fixes-2017-07-27' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Fix bad comparison in skl_compute_plane_wm.
drm/i915: Force CPU synchronisation even if userspace requests ASYNC
drm/i915: Only skip updating execobject.offset after error
drm/i915: Only mark the execobject as pinned on success
drm/i915: Remove assertion from raw __i915_vma_unpin()
drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence
drm/i915: Fix scaler init during CRTC HW state readout
drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
drm/i915: Unbreak gpu reset vs. modeset locking
drm/i915: Fix cursor updates on some platforms
drm/i915: Fix user ptr check size in eb_relocate_vma()
drm/i915/gvt: Extend KBL platform support in GVT-g
drm/i915/gvt: Fix the vblank timer close issue after shutdown VMs in reverse
Core Changes:
- dp: A few fixes in drm_dp_downstream_debug() (Chris)
- rockchip: sanitize the Kconfig dependencies (fallout from EXTCON) (Arnd)
- host1x: Free the iommu domain when attach_device fails (Paul)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Kocialkowski <contact@paulk.fr>
* tag 'drm-misc-fixes-2017-07-27' of git://anongit.freedesktop.org/git/drm-misc:
gpu: host1x: Free the IOMMU domain when there is no device to attach
drm/rockchip: fix Kconfig dependencies
drm/dp: Don't trust drm_dp_downstream_id()
drm/dp: Fix read pointer for drm_dp_downsteam_debug()
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same
as ddb_allocation >= blocks_per_line, so use the latter to simplify
this.
This fixes the following compiler warning:
drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a
boolean expression with an integer other than 0 or 1.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: d555cb5827 ("drm/i915/skl+: use linetime latency if ddb size is not available")
Cc: "Mahesh Kumar" <mahesh1.kumar@intel.com>
Reported-by: David Binderman <dcb314@hotmail.com>
Cc: David Binderman <dcb314@hotmail.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+
Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
(cherry picked from commit 54d20ed1ff)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170717111355.4523-1-maarten.lankhorst@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The goal here was to minimise doing any thing or any check inside the
kernel that was not strictly required. For a userspace that assumes
complete control over the cache domains, the kernel is usually using
outdated information and may trigger clflushes where none were
required.
However, swapping is a situation where userspace has no knowledge of the
domain transfer, and will leave the object in the CPU cache. The kernel
must flush this out to the backing storage prior to use with the GPU. As
we use an asynchronous task tracked by an implicit fence for this, we
also need to cancel the ASYNC flag on the object so that the object will
wait for the clflush to complete before being executed. This also absolves
userspace of the responsibility imposed by commit 77ae995789 ("drm/i915:
Enable userspace to opt-out of implicit fencing") that its needed to ensure
that the object was out of the CPU cache prior to use on the GPU.
Fixes: 77ae995789 ("drm/i915: Enable userspace to opt-out of implicit fencing")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101571
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-5-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 0f46daa1a2)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I was being overly paranoid in not updating the execobject.offset after
performing the fallback copy where we set reloc.presumed_offset to -1.
The thinking was to ensure that a subsequent NORELOC execbuf would be
forced to process the invalid relocations. However this is overkill so
long as we *only* update the execobject.offset following a successful
update of the relocation value witin the batch. If we have to repeat the
execbuf due to a later interruption, then we may skip the relocations on
the second pass (honouring NORELOC) since the execobject.offset match
the actual offsets (even though reloc.presumed_offset is garbage).
Subsequent calls to execbuf with NORELOC should themselves ensure that
the reloc.presumed_offset have been corrected in case of future
migration.
Reporting back the actual execobject.offset, even when
reloc.presumed_offset is garbage, ensures that reuse of those objects
use the latest information to avoid relocations.
Fixes: 2889caa923 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101635
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-4-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 1f727d9e72)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After we detect a i915_vma pin overflow, we call __i915_vma_unpin to
cleanup. However, on an overflow the pin_count bitfield will be zero,
triggering an assertion, even though we the intention is to merely warn
and report the error back to the user (as historically the culprit has
be a leak in the display code).
Fixes: 20dfbde463 ("drm/i915: Wrap vma->pin_count accessors with small inline helpers")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 67fddd902b)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The condition for setting the Loadgen Select bit of
PORT_TX_DW4 register during DDI Vswing Sequence should be
Bit rate <=6 GHz whereas the existing code checks only
Bit Rate < 6GHz. This patch fixes this condition.
While at it also remove the redundant paranthesis.
Fixes: cf54ca8bc5 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500329122-32662-1-git-send-email-manasi.d.navare@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit a8e45a1c42)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
(added in a follow-up patchset by Shashank) when booting with the screen
off: after the initial HW readout and modeset which enables the scaler a
subsequent modeset will disable the scaler which isn't properly
allocated. This results in a funky HW state where the pipe scaler HW
registers can't be modified and the normally black screen is grey and
shifted to the right or jitters.
The problem was revealed by Shashank's YUV420 patchset and first
reported by Ville.
v2:
- In the stable tag also include versions which need backporting (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: <stable@vger.kernel.org> # 4.2.x
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: a1b2278e4d ("drm/i915: skylake panel fitting using shared scalers")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 5fb9dadf33)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Goto the right label in case of error, otherwise there is a leak.
This has been introduced by c5cf9a9147. In this patch a goto has not been
updated.
Fixes: c5cf9a9147 ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719223503.30580-1-christophe.jaillet@wanadoo.fr
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit a5ec7fe81a)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Taking the modeset locks unconditionally isn't the greatest idea,
because atm that part is still broken and times out (and then atomic
keels over). And there's really no reason to do so, the old code
didn't do that either.
To make the patch a bit simpler let's also nuke 2 cases that are only
around for the old mmioflip paths. Atomic nonblocking workers will not
die (minus bugs) when a gpu reset happens.
And of course this doesn't fix any of the gpu reset vs. modeset
deadlock fun, but it at least stop modern CI machines from keeling
over all over the place for no reason at all.
And we still have the explicit testcases to run the fake gpu reset, so
coverage isn't that much worse.
v2: Split out additional changes on top, restrict this to purely reducing
the critical section of modeset locks.
v2: Review from Maarten
- update comments
- don't oops when state is NULL in intel_finish_reset, but try to at
least still drop locks properly. The hw is going to be toast anyway.
Fixes: 7397489399 ("drm/i915: Fix modeset handling during gpu reset, v5.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-3-daniel.vetter@ffwll.ch
(cherry picked from commit ce87ea15eb)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When there is no device to attach to the IOMMU domain, as may be the
case when the device-tree does not contain the proper iommu node, it is
best to keep going without IOMMU support rather than failing.
This allows the driver to probe and function instead of taking down
all of the tegra drm driver, leading to missing display support.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Fixes: 404bfb78da ("gpu: host1x: Add IOMMU support")
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170710193305.5987-1-contact@paulk.fr
This got missed when we open sourced this.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.
Even worse, a write to any of the cursor register apart from CURBASE
will cancel an already pending cursor update. So if we have armed a
CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
would cancel that armed update. Thus we're left with a cursor that
doesn't appear to move, or even change shape.
Fix the problem by always performing the CURBASE write after a
CURPOS write. Bspec is somewhat unclear which platforms actually
require this CURBASE write and which don't. So to keep it simple
and to make sure we really fix the problem across all supported
devices, let's just perform the CURBASE write unconditionally.
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790
Fixes: 75343a44c9 ("drm/i915: Drop useless posting reads from cursor commit")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com
(cherry picked from commit 8753d2bc5e)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
Fixes: 2889caa923 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-2-imre.deak@intel.com
(cherry picked from commit edd9003f7f)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The rework of the exynos DRM clock handling introduced
warnings for configurations that have CONFIG_PM disabled:
drivers/gpu/drm/exynos/exynos_hdmi.c:736:13: error: 'hdmi_clk_disable_gates' defined but not used [-Werror=unused-function]
static void hdmi_clk_disable_gates(struct hdmi_context *hdata)
^~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/exynos/exynos_hdmi.c:717:12: error: 'hdmi_clk_enable_gates' defined but not used [-Werror=unused-function]
static int hdmi_clk_enable_gates(struct hdmi_context *hdata)
The problem is that the PM functions themselves are inside of
an #ifdef, but some functions they call are not.
This patch removes the #ifdef and instead marks the PM functions
as __maybe_unused, which is a more reliable way to get it right.
Link: https://patchwork.kernel.org/patch/8436281/
Fixes: 9be7e98984 ("drm/exynos/hdmi: clock code re-factoring")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
If the s5p-cec driver is a module and the drm exynos driver is built-in, then
the CEC core will be a module also, causing the CEC notifier to fail (will be
compiled as empty functions).
To prevent this select CEC_CORE if CEC_NOTIFIER is set to ensure the CEC core
is also built into the kernel.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The "Fixes" patch was incorrectly merged, as a result PHY is prematurely
powered off and for example Odroid-U3 cannot disable TV power domain
when HDMI cable is unplugged.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 625e63e2 ("drm/exynos/hdmi: fix pipeline disable order")
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch moves drm_bridge_add call into probe.
It doesn't need to call drm_bridge_add call every time
bind callback is called.
Changelog v2
- moved drm_bridge_remove call into remove callback.
- corrected description.
Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Remove the error handling of bridge_node because the bridge_node is
optional.
For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is optional.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
It doesn't need to try to find a bridge if bridge node doesn't exist.
Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com>
Tested-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
12294 1192 0 13486 34ae drivers/gpu/drm/exynos/exynos_hdmi.o
File size after constify hdmi_match_types.
text data bss dec hex filename
13318 176 0 13494 34b6 drivers/gpu/drm/exynos/exynos_hdmi.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
num_ioctls is already assigned when declaring the exynos_drm_driver
structure. No need to duplicate it here.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copy the approach taken by gfx8, which simplifies the code, and set the
instance index properly. The latter is required for debugging, e.g. for
reading wave status by UMR.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
two more fixes for issues nouveau found in fedora 26.
* 'linux-4.13' of git://github.com/skeggsb/linux:
drm/nouveau/bar/gf100: fix access to upper half of BAR2
drm/nouveau/disp/nv50-: bump max chans to 21
Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.
We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.
This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
Shout-out to NVIDIA for the quick response with the potential cause!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org # 4.3+
GP102's cursors go from chan 17..20. Increase the array size to hold
their data properly.
Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Extend KBL platform support in GVT-g. Validation tests
are done on KBL server and KBL NUC. Both show the same
quality.
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
These on()/off() calls should be done as a result of modesetting actions,
and as we shut down all heads already on unload/suspend, it's pointless
to call off() again.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We don't support them on G80, but we need to add them to the mapping to
avoid triggering a WARN_ON() on GPUs where the ports are present.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since switching the I2C-over-AUX helpers, there have been regressions on
some display combinations due to us not having support for "address only"
transactions.
This commits enables support for them for GF119 and newer.
Earlier GPUs have been reverted to a custom I2C-over-AUX algorithm.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A bug that I had fixed earlier just came back, with CONFIG_EXTCON=m,
the rockchip drm driver will fail to link:
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_get_port_lanes':
cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x30): undefined reference to `extcon_get_state'
cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x6c): undefined reference to `extcon_get_property'
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_check_sink_connection':
cdn-dp-core.c:(.text.cdn_dp_check_sink_connection+0x80): undefined reference to `extcon_get_state'
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_enable':
cdn-dp-core.c:(.text.cdn_dp_enable+0x748): undefined reference to `extcon_get_property'
The problem is that that the sub-drivers are now all linked into the
main rockchip drm module, which breaks all the Kconfig dependencies
that are specified in the options for those sub-drivers.
This clarifies the dependency to ensure that we can only turn on the DP
driver when EXTCON is reachable. As the 'select' statements can now
cause additional options to become built-in when they should be
loadable modules, I'm moving those into the main driver config option.
The dependency on DRM_ROCKCHIP can be reduced into a single 'if'
statement here for brevity, but this has no functional effect.
Fixes: b6705157b2 ("drm/rockchip: add extcon dependency for DP")
Fixes: 8820b68bd3 ("drm/rockchip: Refactor the component match logic.")
Link: https://patchwork.kernel.org/patch/9648761/
Acked-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721211214.3386387-1-arnd@arndb.de
- Fix a regression where the parallel-display driver would not probe
anymore if no panel is specified in the device tree, since the
introduction of drm_of_find_panel_or_bridge.
- Fix a typo in the plane format list: replace a duplicate BGRA8888 format
with BGRX8888, as originally intended.
-----BEGIN PGP SIGNATURE-----
iQJMBAABCAA2FiEEBsBxhV1FaKwXuCOBUMKIHHCeYOsFAlltvcoYHHBoaWxpcHAu
emFiZWxAZ21haWwuY29tAAoJEFDCiBxwnmDrlCgQANHXCT5QIY9VG575NpCQvT6F
wm3Bl4uTiIlIQOFSabUznZB15egQFe9StUpa4JvWpPHPlLpiYvjkLEuX1jSVHucD
s4gQR9vZ43h6xMtSY06TXr/aqy1LSM91ozmYCNawAa9/4nkp2DS/B9p3McbUJf+s
GBXWPdQ4ldRMYWtT+Yy/5uJPos825E0pjR2N+2AsiE1dzCnGm4NW5Pj6xdJGVqJA
OHrO8OWW7bg1XZRqRIWcFT+39fSPy9/ua94dgQMKlh6DZ+snWdQmSFH3j3UMiFVs
vMXXqQ4R52gNWoR0a4FOPytmEnKLB5qB6HnQoATMiExWTVhFAh1gabUSqcwognrh
gFDMeHXG+AX2hPz0qxldwuHLHd5yLuaYcUMpY0fMhph4j6veBDLUpgyUvopaWQFx
w2emsQ+1kJCjIEiHmaNbnK58i+m7jEIg558WUVgYAyXQHQMuY2pb1plyUopONZwU
QDt898nsVfPDBcu6s29l0PmGNlW4jZ5Nt1NzUd8plHQq7m4vl6nhrlH0lig/fqoC
luQewOTQ+HAp/2OGnHhcVyBJQD11w5jr0K0kwILOMPUHH4NlWWAKrC7S+QHoviOx
ZKBlHcMz5bgVHGguOa2dFx8LpEMQzeXGk7QwKBfKktDjpmXHT6kiyDX+Yjg8IV0S
pMFdMvItdyx1dnaOzVp5
=0w4j
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-2017-07-18' of git://git.pengutronix.de/git/pza/linux into drm-fixes
imx-drm: fix parallel display regression and typo in plane format list
- Fix a regression where the parallel-display driver would not probe
anymore if no panel is specified in the device tree, since the
introduction of drm_of_find_panel_or_bridge.
- Fix a typo in the plane format list: replace a duplicate BGRA8888 format
with BGRX8888, as originally intended.
* tag 'imx-drm-fixes-2017-07-18' of git://git.pengutronix.de/git/pza/linux:
drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failure
drm/imx: fix typo in ipu_plane_formats[]
Core Changes:
- fence: Introduce new fence flag to signify timestamp is populated (Chris)
- mst: Avoid processing incomplete data + fix NULL dereference (Imre)
Driver Changes:
- vc4: Avoid WARN from grabbing a ref from vblank that's not on (Boris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Imre Deak <imre.deak@intel.com>
* tag 'drm-misc-fixes-2017-07-20' of git://anongit.freedesktop.org/git/drm-misc:
drm/mst: Avoid processing partially received up/down message transactions
drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()
drm/mst: Fix error handling during MST sideband message reception
drm/vc4: Fix VBLANK handling in crtc->enable() path
dma-buf/fence: Avoid use of uninitialised timestamp
Currently we may process up/down message transactions containing
uninitialized data. This can happen if there was an error during the
reception of any message in the transaction, but we happened to receive
the last message correctly with the end-of-message flag set.
To avoid this abort the reception of the transaction when the first
error is detected, rejecting any messages until a message with the
start-of-message flag is received (which will start a new transaction).
This is also what the DP 1.4 spec 2.11.8.2 calls for in this case.
In addtion this also prevents receiving bogus transactions without the
first message with the the start-of-message flag set.
v2:
- unchanged
v3:
- git add the part that actually skips messages after an error in
drm_dp_sideband_msg_build()
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lyude <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719134632.13366-1-imre.deak@intel.com
In case of an unknown broadcast message is sent mstb will remain unset,
so check for this.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lyude <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-3-imre.deak@intel.com
Handle any error due to partial reads, timeouts etc. to avoid parsing
uninitialized data subsequently. Also bail out if the parsing itself
fails.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lyude <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-2-imre.deak@intel.com
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
13765 800 20 14585 38f9 gpu/drm/vmwgfx/vmwgfx_drv.o
File size After adding 'const':
text data bss dec hex filename
13829 736 20 14585 38f9 gpu/drm/vmwgfx/vmwgfx_drv.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
