| Age | Commit message (Collapse) | Author |
|---|
|
Since the function ipu_dmfc_init_channel() always returns zero, we may
change the return type to void to simplify the code.
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
To avoid race condition issue, we should protect the function
ipu_dmfc_init_channel() with the mutex dmfc->priv->mutex, since it
configures the register DMFC_GENERAL1 at runtime which contains
several control bits for various display channels. This matches
better with fine grained locking logic in upper layer.
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The IMX dw_hdmi driver just called platform_set_drvdata() to get
your hopes up that maybe, somehow, you'd be able to retrieve the 'struct
imx_hdmi' from a pointer to the 'struct device'. You can't. When
we call dw_hdmi_bind() the main driver calls dev_set_drvdata(), which
clobbers our setting.
Let's just remove the platform_set_drvdata() to avoid dashing people's
hopes.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The drm_encoder_cleanup() was missing both from the error path of
dw_hdmi_imx_bind(). This caused a crash when slub_debug was
enabled and we ended up deferring probe of HDMI at boot.
This call isn't needed from unbind() because if dw_hdmi_bind() returns
no error then it takes over the job of freeing the encoder (in
dw_hdmi_unbind).
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The driver already advertises multi-planar YUV support, but
previously the U/V offset and stride setup was missing.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The IPU addresses multiplanar formats using a base address and relative
offsets for the secondary planes. Since those offsets must be positive
and not too large, and none of the plane parameters except the base address
may be changed while scanout is active, store the pitches and u/v offsets
and check all values against IDMAC limitations.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Let ipu_cpmem_set_yuv_planar_full take a DRM_FORMAT instead of a
V4L2_PIXFMT and allow better control over U/V stride, U offset and
V offset settings in the CPMEM.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The SPICE protocol considers the position of a cursor to be the location
of its active pixel on the display, so the cursor is drawn with its
top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor
position gives the location where the top-left corner should be drawn,
with the hotspot being a hint for drivers that need it.
This fixes the location of the window resize cursors when using Fluxbox
with the QXL DRM driver and both the QXL and modesetting X drivers.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
With async modesets this is no longer protected with connection_mutex,
so ensure that each pll has its own lock. The pll configuration state
is still protected; it's only the pll updates that need locking against
concurrency.
Changes since v1:
- Rebased.
- Fix locking to protect all accesses. (Durgadoss)
Changes since v2:
- Make the dpll_lock global to protect concurrent updates to the
same register, for example DPLL_CTRL1 on skl. (Ander)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56F29F50.1090708@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
|
|
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458342904-23326-3-git-send-email-robdclark@gmail.com
|
|
And move the comment to the right macro. This was mixed up in
commit cfb23ed622d040619abb91e625fcba74d356b8a8
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Tue Jul 14 12:17:40 2015 +0200
drm/i915: Allow fuzzy matching in pipe_config_compare, v2
v2: Rebase.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330476-32453-1-git-send-email-daniel.vetter@ffwll.ch
|
|
We now have KBL machines running in our CI systems and with no
blocking issues that could cause a full hangs or blank screens.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459349881-951-1-git-send-email-rodrigo.vivi@intel.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
drivers.
v2: Make the dummy function actually return a sane value, spotted by
Ville.
v3: Because the patch is still in limbo there's no more drivers to
convert, noticed by Emil.
v4: Rebase once more, because hooray. I'll just go ahead an apply this
one later on to drm-misc.
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This goes all the way back to the original KMS commit aeons ago
commit f453ba0460742ad027ae0c4c7d61e62817b3e7ef
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Nov 7 14:05:41 2008 -0800
DRM: add mode setting support
But it seems to be completely unused. Only i915 and nouveau even
register these properties, and the corresponding DDX don't even look
at them. Also the sysfs files are read-only, so not useful to
configure anything.
I suspect that this was added with the goal to have read-only access
to all properties in sysfs, but we never followed through on that.
Also, that should be done in a more generic fashion.
Since it would be real work to fix up the locking (with atomic we're
now chasing pointers when reading properties) and it seems unused lets
just nuke this all. It's easier. Of course we'll keep the properties
themselves, those are still exposed through the KMS ioctls.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459331120-27864-5-git-send-email-daniel.vetter@ffwll.ch
|
|
It tries to do fancy things with excluding agp support if ttm is
built-in, but agp isn't. Instead just express this depency like drm
does and use CONFIG_AGP everywhere.
Also use the neat Makefile magic to make the entire ttm_agp_backend
file optional.
v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville
v3: Review from Emil.
v4: Actually get it right as spotted by 0-day.
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459337046-25882-1-git-send-email-daniel.vetter@ffwll.ch
|
|
This effectively reverts
commit 8e5fd599eb219f1054e39b40d18b217af669eea9
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Apr 9 13:28:50 2014 +0300
drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed
as under continuous execlists load we can saturate the IRQ handler,
destablising the tsc clock and triggering the NMI watchdog to declare a hung
CPU.
[ 552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:
[ 552.756080] clocksource: 'refined-jiffies' wd_now: 10003b480 wd_last: 10003b28c mask: ffffffff
[ 552.756091] clocksource: 'tsc' cs_now: d55d31aa50 cs_last: d17446166c mask: ffffffffffffffff
[ 552.756210] clocksource: Switched to clocksource refined-jiffies
[ 575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18
[ 575.217905] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 575.217915] 0000000000000000 ffff88027fd05bc0 ffffffff81288c6d 0000000000000000
[ 575.217935] 0000000000000001 ffff88027fd05be0 ffffffff810e72d1 0000000000000000
[ 575.217951] ffff88027fd05c80 ffff88027fd05c20 ffffffff81114b60 0000000181015f1e
[ 575.217967] Call Trace:
[ 575.217973] <NMI> [<ffffffff81288c6d>] dump_stack+0x4f/0x72
[ 575.217994] [<ffffffff810e72d1>] watchdog_overflow_callback+0x151/0x160
[ 575.218003] [<ffffffff81114b60>] __perf_event_overflow+0xa0/0x1e0
[ 575.218016] [<ffffffff811154c4>] perf_event_overflow+0x14/0x20
[ 575.218028] [<ffffffff8101d2ca>] intel_pmu_handle_irq+0x1da/0x460
[ 575.218042] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218052] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218064] [<ffffffff81014ae8>] perf_event_nmi_handler+0x28/0x50
[ 575.218075] [<ffffffff81007540>] nmi_handle+0x60/0x130
[ 575.218086] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218096] [<ffffffff810079c0>] do_nmi+0x140/0x470
[ 575.218108] [<ffffffff81559ec7>] end_repeat_nmi+0x1a/0x1e
[ 575.218119] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218129] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218139] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218148] <<EOE>> [<ffffffff814a8353>] cpuidle_enter_state+0xf3/0x2f0
[ 575.218164] [<ffffffff814a8587>] cpuidle_enter+0x17/0x20
[ 575.218175] [<ffffffff810aaa3a>] call_cpuidle+0x2a/0x40
[ 575.218185] [<ffffffff810aade3>] cpu_startup_entry+0x273/0x330
[ 575.218196] [<ffffffff81033a1e>] start_secondary+0x10e/0x130
However, not servicing all available IIR within the handler does hurt the
throughput of pathological nop execbuf by about 20%, with a similar effect
upon the dispatch latency of a series of execbuf.
v2: use do {} while(0) for a smaller patch, and easier to revert again
I have reasonable confidence that we do not miss GT interrupts (as
execlists provides a stress case with a failure mechanism easily
detected by igt), however I have less confidence about all the other
sources of interrupts and worry that may lose a display hotplug
interrupt, for example.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467
Testcase: igt/gem_exec_nop/basic # requires NMI watchdog
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Antti Koskipää <antti.koskipaa@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457946117-6714-1-git-send-email-chris@chris-wilson.co.uk
|
|
__force_wake_get() only acquires a temporary wakeref on forcewake that is
automatically released when a timer expires. When reading the code
again, I confused __intel_uncore_forcewake_get() for __force_wake_get()
and to my shame thought I found a bug in unbalanced wake_count handling.
I claim that if the function had been called __force_wake_auto() instead
I would not have embarrassed myself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458829907-26596-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Rename and document the GGTT init functions to give a better
idea of the context where they are called from.
i915_gem_gtt_init => i915_ggtt_init_hw
i915_gem_init_global_gtt => i915_gem_init_ggtt
i915_global_gtt_cleanup => i915_ggtt_cleanup_hw
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458830866-12578-1-git-send-email-joonas.lahtinen@linux.intel.com
|
|
Lets BUG_ON and don't bother with a WARN and returning an error, so we can
remove the need to pollute the code with error handling, after all it is
a programmer error to provide NULL view. Also while we're here remove
redundant NULL ggtt_view check.
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834860-7898-1-git-send-email-matthew.auld@intel.com
|
|
commit e2c8b8701e2d moved modeset locking inside resume/suspend
functions, but missed a code path only executed on lid close/open
on older hardware. The result was a deadlock when closing and
opening the lid without suspending on such hardware:
=============================================
[ INFO: possible recursive locking detected ]
4.6.0-rc1 #385 Not tainted
---------------------------------------------
kworker/0:3/88 is trying to acquire lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
but task is already holding lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&dev->mode_config.mutex);
lock(&dev->mode_config.mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by kworker/0:3/88:
#0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
#1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
#2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65
#3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915]
#4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
#5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm]
#6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm]
stack backtrace:
CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
Workqueue: kacpi_notify acpi_os_execute_deferred
0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0
ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70
000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0
Call Trace:
[<ffffffff8124af06>] dump_stack+0x67/0x90
[<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71
[<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a
[<ffffffff8108fae2>] lock_acquire+0x137/0x1cb
[<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm]
[<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm]
[<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915]
[<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c
[<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65
[<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16
[<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button]
[<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button]
[<ffffffff812b07df>] acpi_device_notify+0x19/0x1b
[<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64
[<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20
[<ffffffff81068f17>] process_one_work+0x265/0x50b
[<ffffffff810696f5>] worker_thread+0x1fc/0x2dd
[<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
[<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
[<ffffffff8106e2d6>] kthread+0xe0/0xe8
[<ffffffff8107bc47>] ? local_clock+0x19/0x22
[<ffffffff81484f42>] ret_from_fork+0x22/0x40
[<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no
|
|
We don't need to keep empty callbacks for the (pre/post) enable/disable
drm_bridge ops anymore. Remove the nop callback used here for
pre_enable and post_disable ops.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459329804-10488-1-git-send-email-architt@codeaurora.org
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This reverts commit e91abf80a0998f326107874c88d549f94839f13c.
Since
commit 24e4a8c3e8868874835b0f1ad6dd417341e99822
Author: John Stultz <john.stultz@linaro.org>
Date: Wed Jul 16 21:03:53 2014 +0000
ktime: Kill non-scalar ktime_t implementation for 2038
there is no longer a 32bit version that's unsigned, and we don't have
to jump through ridiculous hoops to make the calculations correct.
I didn't look whether there's more of this pattern in the kernel.
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459249942-21589-1-git-send-email-daniel.vetter@ffwll.ch
|
|
Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.
This order was originally changed in
commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
In order to fix some unclaimed register errors, however the actual cause
of those has since been fixed.
CC: stable@vger.kernel.org
Signed-off-by: Lyude <cpaul@redhat.com>
[danvet: Resolve conflicts with locking changes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.
We might likewise receive hotplug events before we've had a chance to
fully set up the fbdev.
Fix by waiting for the asynchronous thread to finish.
v2:
An async_synchronize_full() was also added to intel_fbdev_set_suspend()
in v1 which turned out to be entirely gratuitous. It caused a deadlock
on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela
for CI support) and was unnecessary since a device is never suspended
until its ->probe callback (and all asynchronous tasks it scheduled)
have finished. See dpm_prepare(), which calls wait_for_device_probe(),
which calls async_synchronize_full().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: Gustav Fägerlind <gustav.fagerlind@gmail.com>
Reported-by: "Li, Weinan Z" <weinan.z.li@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160309115147.67B2B6E0D3@gabe.freedesktop.org
|
|
Accidentally fell through the cracks in
commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
Author: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Date: Wed Mar 23 11:42:54 2016 +0300
drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()
despite that Boris acked that patch.
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Set from VBT, but never used. Good riddance.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-5-git-send-email-jani.nikula@intel.com
|
|
Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-4-git-send-email-jani.nikula@intel.com
|
|
Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-3-git-send-email-jani.nikula@intel.com
|
|
Housekeeping, similar to psr, backlight, and dsi. No functional changes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-2-git-send-email-jani.nikula@intel.com
|
|
Current name is a bit misleading because what that helper function
really does it calls drm_connector_unregister() for all connectors.
This all has nothing to do with hotplugging so let's name things
properly.
And while at it remove potentially dangerous locking around
drm_connector_unregister() in rcar_du_remove() as mentioned
in kerneldoc for drm_connector_unregister_all().
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: linux-renesas-soc@vger.kernel.org
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458722577-20283-2-git-send-email-abrodkin@synopsys.com
|
|
Instead of forcing bridges to implement empty callbacks make them all
optional.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456480266-7904-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com
Acked-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
The purpose of pinning is to prevent a buffer from moving.
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The purpose of pinning is to prevent a buffer from moving.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Higher mclk values are not stable due to a bug somewhere.
Limit them for now.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=115291
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
The Rockchip dw_hdmi driver just called platform_set_drvdata() to get
your hopes up that maybe, somehow, you'd be able to retrieve the 'struct
rockchip_hdmi' from a pointer to the 'struct device'. You can't. When
we call dw_hdmi_bind() the main driver calls dev_set_drvdata(), which
clobbers our setting.
Let's just remove the platform_set_drvdata() to avoid dashing people's
hopes.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
|
|
This fixes a few problems in the vop crtc cleanup (handling error
paths and cleanup upon exit):
* The vop_create_crtc() error path had an unsafe version of the
iterator used for iterating over all planes (though it was
destroying planes in the iterator so should have used the safe
version)
* vop_destroy_crtc() - wasn't calling vop_plane_destroy(), which made
slub_debug unhappy, at least if we ended up running this due to a
deferred probe.
* In vop_create_crtc() if we were missing the "port" device tree node
we would fail but not return an error (found by code inspection).
Fix these problems.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
|
|
The drm_encoder_cleanup() was missing both from the error path of
dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was
enabled and we ended up deferring probe of HDMI at boot.
This call isn't needed from unbind() because if dw_hdmi_bind() returns
no error then it takes over the job of freeing the encoder (in
dw_hdmi_unbind).
Signed-off-by: Douglas Anderson <dianders@chromium.org>
|
|
When a VOP is re-enabled, it will start scanning right away the
framebuffers that were configured from the last time, even if those have
been destroyed already.
To prevent the VOP from trying to access freed memory, disable all its
windows when the CRTC is being disabled, then each window will get a
valid framebuffer address before it's enabled again.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw@mail.gmail.com
|
|
So that when DRM_IOCTL_MODE_SETCRTC is called without a FB nor mode, the
CRTC gets disabled.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw@mail.gmail.com
|
|
When closing the DRM device while a vblank is pending, we access
file_priv after it has been free'd, which gives:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
PC is at __list_add+0x5c/0xe8
LR is at send_vblank_event+0x54/0x1f0
...
[<c02952e8>] (__list_add) from [<c031a7b4>] (send_vblank_event+0x54/0x1f0)
[<c031a760>] (send_vblank_event) from [<c031a9c0>] (drm_send_vblank_event+0x70/0x78)
[<c031a950>] (drm_send_vblank_event) from [<c031a9f8>] (drm_crtc_send_vblank_event+0x30/0x34)
[<c031a9c8>] (drm_crtc_send_vblank_event) from [<c0339ad8>] (vop_isr+0x224/0x28c)
[<c03398b4>] (vop_isr) from [<c0081780>] (handle_irq_event_percpu+0x12c/0x3e4)
This can be triggered somewhat reliably with:
modetest -M rockchip -v -s ...
Add a preclose hook to the driver so that we can discard any pending
vblank events when the device is closed.
Signed-off-by: John Keeping <john@metanate.com>
|
|
If the geometry of a crtc is changing in an atomic update then we must
validate the plane size against the new state of the crtc and not the
current size, otherwise if the crtc size is increasing the plane will be
cropped at the previous size and will not fill the screen.
Signed-off-by: John Keeping <john@metanate.com>
|
|
Pull drm fixes from Dave Airlie:
"Just a couple of dma-buf related fixes and some amdgpu fixes, along
with a regression fix for radeon off but default feature, but makes my
30" monitor happy again"
* 'drm-next' of git://people.freedesktop.org/~airlied/linux:
drm/radeon/mst: cleanup code indentation
drm/radeon/mst: fix regression in lane/link handling.
drm/amdgpu: add invalidate_page callback for userptrs
drm/amdgpu: Revert "remove the userptr rmn->lock"
drm/amdgpu: clean up path handling for powerplay
drm/amd/powerplay: fix memory leak of tdp_table
dma-buf/fence: fix fence_is_later v2
dma-buf: Update docs for SYNC ioctl
drm: remove excess description
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
drm/atmel-hlcdc: use helper to get crtc state
drm/atomic: use helper to get crtc state
|
|
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=94692
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
The current "text" needs a user to use a crystal ball in order to find
out what this ACP thing is.
Use the text from
a8fe58cec351 ("drm/amd: add ACP driver support")
to make it a bit more understandable to the rest of the world.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Jammy Zhou <Jammy.Zhou@amd.com>
Cc: Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
Cc: Murali Krishna Vemuri <murali-krishna.vemuri@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
into drm-next
some amd fixes
* 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/mst: cleanup code indentation
drm/radeon/mst: fix regression in lane/link handling.
drm/amdgpu: add invalidate_page callback for userptrs
drm/amdgpu: Revert "remove the userptr rmn->lock"
drm/amdgpu: clean up path handling for powerplay
drm/amd/powerplay: fix memory leak of tdp_table
|
|
Having provided for_each_engine_id() for cases where the third (id)
argument is useful, we can now replace all the remaining instances with
a simpler version that takes only two parameters. In many cases, this
also allows the elimination of the local variable used in the iterator
(usually 'i').
v2:
s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson]
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458757194-17783-2-git-send-email-david.s.gordon@intel.com
|
|
Equivalent to the existing for_each_engine() macro, this will replace
the latter wherever the third argument *is* actually wanted (in most
places, it is not used). The third argument is renamed to emphasise
that it is an engine id (type enum intel_engine_id). All the callers of
the macro that actually need the third argument are updated to use this
version, and the argument (generally 'i') is also updated to be 'id'.
Other callers (where the third argument is unused) are untouched for
now; they will be updated in the next patch.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Currently the machine hangs during booting while accessing the
BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some
experimentation I found that the hang is caused by the DSI PLL being
disabled, or it being enabled but with an incorrect divider
configuration. Enabling the PLL got rid of the boot problem, so fix
this by checking the PLL enabled state/configuration before attempting
to read out the HW state.
The DSI_PLL_ENABLE register is in the always-on power well, while the
BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the
transcoder power domain, but what we really need is just a runtime PM
reference, which is provided by any power domain.
Ville also found this dependency specified in BSpec, so I added a
reference to that too.
v2:
- Make sure we hold a power reference while accessing the PLL registers.
v3: (Jani)
- Simplify check in bxt_get_dsi_transcoder_state()
- Add comment explaining why we check for valid dividers in
bxt_dsi_pll_is_enabled()
CC: Shashank Sharma <shashank.sharma@intel.com>
CC: Uma Shankar <uma.shankar@intel.com>
CC: Jani Nikula <jani.nikula@intel.com>
Fixes: c6c794a2fc5e ("drm/i915/bxt: Initialize MIPI DSI for BXT")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458816100-31269-1-git-send-email-imre.deak@intel.com
|
