| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The power well IDs are used for lookup, so they must be unique on a
given platform; ensure this on CHV. This didn't cause an actual problem
since we didn't need to look up power wells which happened to share an
ID.
Mark this new power well as custom, since its programming pattern
doesn't follow that of the rest of VLV/CHV power wells.
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The crtc state starts out being bzero'd, so no need to clear
scaler_users. Also intel_crtc_init_scalers() knows already which
platforms have scalers, so no need for the platform check here.
Similarly intel_crtc_init_scalers() will init scaler_id as required,
so no need to do it here separately.
Cc: Chandra Konduru <[email protected]>
Cc: Matt Roper <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Mahesh Kumar <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
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 <[email protected]>
Cc: Shashank Sharma <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Chandra Konduru <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: <[email protected]> # 4.2.x
Reported-by: Ville Syrjälä <[email protected]>
Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Mahesh Kumar <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
If all goes well, resetting one engine should not affect the operation of
any others. So to test this, we setup a continuous stream of requests
onto to each of the "innocent" engines whilst constantly resetting our
target engine.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Michel Thierry <[email protected]>
Reviewed-by: Michel Thierry <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Triggering a GPU reset for one engine affects another, notably
corrupting the context status buffer (CSB) effectively losing track of
inflight requests.
Adding a few printks:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ad41836fa5e5..a969456bc0fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1953,6 +1953,7 @@ int i915_reset_engine(struct intel_engine_cs *engine)
goto out;
}
+ pr_err("Resetting %s\n", engine->name);
ret = intel_gpu_reset(engine->i915, intel_engine_flag(engine));
if (ret) {
/* If we fail here, we expect to fallback to a global reset */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 716e5c9ea222..a72bc35d0870 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -355,6 +355,7 @@ static void execlists_submit_ports(struct intel_engine_cs *engine)
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
port_set(&port[n], port_pack(rq, count));
desc = execlists_update_context(rq);
+ pr_err("%s: in (rq=%x) ctx=%d\n", engine->name, rq->global_seqno, upper_32_bits(desc));
GEM_DEBUG_EXEC(port[n].context_id = upper_32_bits(desc));
} else {
GEM_BUG_ON(!n);
@@ -594,9 +595,23 @@ static void intel_lrc_irq_handler(unsigned long data)
if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
continue;
+ pr_err("%s: out CSB (%x head=%d, tail=%d), ctx=%d, rq=%d\n",
+ engine->name,
+ readl(csb_mmio),
+ head, tail,
+ readl(buf+2*head+1),
+ port->context_id);
+
/* Check the context/desc id for this event matches */
- GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
- port->context_id);
+ if (readl(buf + 2 * head + 1) != port->context_id) {
+ pr_err("%s: BUG CSB (%x head=%d, tail=%d), ctx=%d, rq=%d\n",
+ engine->name,
+ readl(csb_mmio),
+ head, tail,
+ readl(buf+2*head+1),
+ port->context_id);
+ BUG();
+ }
rq = port_unpack(port, &count);
GEM_BUG_ON(count == 0);
Results in:
[ 6423.006602] Resetting rcs0
[ 6423.009080] rcs0: in (rq=fffffe70) ctx=1
[ 6423.009216] rcs0: in (rq=fffffe6f) ctx=3
[ 6423.009542] rcs0: out CSB (2 head=1, tail=2), ctx=3, rq=3
[ 6423.009619] Resetting bcs0
[ 6423.009980] rcs0: BUG CSB (0 head=1, tail=2), ctx=0, rq=3
Note that this bug may be affect all machines and not just Broxton,
Broxton is just the first machine on which I have confirmed this bug.
Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang recovery")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Michel Thierry <[email protected]>
Acked-by: Michel Thierry <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Although a banned context will be told to -EIO off if they try to submit
more requests, we have a discrepancy between whole device resets and
per-engine resets where we report the GPU reset but not the engine
resets. This leaves a bit of mystery as to why the context was banned,
and also reduces awareness overall of when a GPU (engine) reset occurs
with its possible side-effects.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Michel Thierry <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Michel Thierry <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since we make call i915_gem_context_mark_guilty() concurrently when
resetting different engines in parallel, we need to make sure that our
updates are safe for the unlocked access.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Michel Thierry <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
When the GPU is reset, we want to discard all pending notifications as
either we have manually completed them, or they are no longer
applicable. Make sure we do reset the engine->irq_posted prior to
re-enabling the engine (e.g. the interrupt tasklets) in
i915_gem_reset_finish_engine().
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Michel Thierry <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We should only ever do nop_submit_request when the machine is wedged, so
assert it is so.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Michel Thierry <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
After setting the WEDGED bit, make sure that we do wake up waiters as
they may not be waiting for a request completion yet, just for its
execution.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
intel_engine_init_globa_seqno() may be called from an uncontrolled
set-wedged path where we have given up waiting for broken hw and declare
it defunct. Along that path, any sanity checks that the hw is idle
before we adjust its state will expectedly fail, so we simply cannot.
Instead of asserting inside init_global_seqno, we move them to the
normal caller reset_all_global_seqno() as it handles runtime seqno
wraparound.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
When we wedge the device, we clear out the in-flight requests and
advance the breadcrumb to indicate they are complete. However, the
breadcrumb advance includes an assert that the engine is idle, so that
advancement needs to be the last step to ensure we pass our own sanity
checks.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Including a check against the execlist queue before calling the engine
idle and passing hangcheck.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Before we declare an engine as idle, check if there are any pending
execlist context-switches and if the ring itself reports as idle.
Otherwise, we may be left in a situation where we miss a crucial
execlist event (or something more sinister) yet the requests complete.
Since the seqno write happens, we believe the engine to be truly idle.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Michel Thierry <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
When doing a GPU reset, the CSB register will be trashed and we will
lose any context-switch notifications that happened since the tasklet
was disabled. If we find that all requests on this engine were
completed, we want to make sure that the ELSP tracker is similarly empty
so that we do not feed back in the completed requests upon recovering
from the reset.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We rely on disabling the execlists (by stopping the tasklet) to prevent
new requests from submitting to the engine ELSP before we are ready.
However, we re-enable the engine before we call init_hw which gives
userspace the opportunity to subit a new request which is then
overwritten by init_hw -- but not before the HW may have started
executing. The subsequent out-of-order CSB is detected by our sanity
checks in intel_lrc_irq_handler().
Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Michel Thierry <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Michel Thierry <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We try to fixup the context image after the reset to ensure that there
are no more pending writes from the hw that may conflict and to fixup
any that were in flight.
Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Michel Thierry <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
As part of the knowing whether there is outstanding data in the CSB,
also check whether there is an outstanding IRQ notification.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Resync with upstream to avoid git getting too badly confused. Also, we
have a conflict with the drm_vblank_cleanup removal, which cannot be
resolved by simply taking our side. Bake that in properly.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
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: 9be7e9898444 ("drm/exynos/hdmi: clock code re-factoring")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
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 <[email protected]>
Reported-by: Marek Szyprowski <[email protected]>
Fixes: 625e63e2 ("drm/exynos/hdmi: fix pipeline disable order")
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Hoegeun Kwon <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
It doesn't need to try to find a bridge if bridge node doesn't exist.
Reviewed-by: Shuah Khan <[email protected]>
Tested-by: Shuah Khan <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
File size before:
text data bss dec hex filename
9983 1424 0 11407 2c8f drivers/gpu/drm/exynos/exynos_mixer.o
File size after constify:
text data bss dec hex filename
11231 176 0 11407 2c8f drivers/gpu/drm/exynos/exynos_mixer.o
Signed-off-by: Arvind Yadav <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
num_ioctls is already assigned when declaring the exynos_drm_driver
structure. No need to duplicate it here.
Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Backmerge drm-next with -rc2 in it to pull in a couple stm patches that
were previously incorrectly applied to -misc-next. By picking them up in
the correct manner, git will hopefully fix any errant trees that are out
in the wild.
Signed-off-by: Sean Paul <[email protected]>
|
|
Linux 4.13-rc2
This is required for drm-misc fixing.
|
|
This will let drivers reduce the error cleanup they need, in
particular the "is_panel_bridge" flag.
v2: Slight cleanup of remove function by Andrzej
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Philippe Cornu <[email protected]>
Tested-by: Philippe Cornu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This patch adds support to VC4 for CEC. It is under a separate
Kconfig option to keep everyone using VC4 from needing to pull in the
CEC core.
Thanks to Eric Anholt for providing me with the CEC register information.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order to support CEC the hsm clock needs to be enabled in
vc4_hdmi_bind(), not in vc4_hdmi_encoder_enable(). Otherwise you wouldn't
be able to support CEC when there is no hotplug detect signal, which is
required by some monitors that turn off the HPD when in standby, but keep
the CEC bus alive so they can be woken up.
The HDMI core also has to be enabled in vc4_hdmi_bind() for the same
reason.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Constify dw_mipi_dsi_stm_phy_ops as these ops are not supposed
to change at runtime.
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Rename the returned value from "res" to "ret" as it is more "readable".
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use devm_reset_control_get_exclusive to avoid resource leakage (based
on patch "Convert drivers to explicit reset API" from Philipp Zabel).
Also use platform_get_resource, which is more usual and
consistent with platform_get_irq called later.
Signed-off-by: Fabien Dessenne <[email protected]>
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Cc: Philipp Zabel <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Constify drm funcs structures.
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Lindent then checkpatch --strict cleanups
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The GCR_PCPOL/DEPOL/VSPOL/HSPOL defines are sufficient to
describe the HS, VS, DE & PC signal polarities.
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Rename the platform driver name from "stm" to "stm32-display"
for a better readability in /sys/bus/platform/drivers entries.
Note: We keep "stm" as drm_driver.name because it is better
when using "modetest -M stm ..." (even if recent modetest patch
avoids using -M).
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
To do not force stm driver to be build by default
Signed-off-by: Benjamin Gaignard <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.
Signed-off-by: Philippe CORNU <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Archit Taneja <[email protected]>
Signed-off-by: Benjamin Gaignard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We cannot reference priv->fbdev outside of the #ifdef:
drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not used [-Werror=unused-function]
static int virtnet_restore_up(struct virtio_device *vdev)
drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but not used [-Werror=unused-function]
static void virtnet_freeze_down(struct virtio_device *vdev)
As the #ifdef is a bit annoying here, this removes it entirely
and uses an IS_ENABLED() check in it place where needed.
Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
Signed-off-by: Arnd Bergmann <[email protected]>
[danvet: One step further, also remove the IS_ENABLED checks, core
no-ops out the fb helper functions that the cma helpers use. Discussed
with Arnd on dri-devel.]
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The current drm_atomic_helper_commit_tail helper works only if the CRTC is
accessible, and documents an alternative implementation that is supposed to
be used if that happens.
That implementation is then duplicated by some drivers. Instead of
documenting it, let's implement an helper that all the relevant users can
use directly.
Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/a8f92dc70048bab746e94dadd1c23200626aff60.1500555652.git-series.maxime.ripard@free-electrons.com
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Explain better when the drm_modeset_acquire_ctx parameter can
be skipped for drm_modeset_lock() call.
Signed-off-by: Liviu Dudau <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Dont' resurrect drm_vblank_cleanup.
Cc: Xinliang Liu <[email protected]>
Cc: Rongrong Zou <[email protected]>
Cc: Xinwei Kong <[email protected]>
Cc: Chen Feng <[email protected]>
Signed-off-by: Thierry Reding <[email protected]> (v1)
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already.
Cc: Inki Dae <[email protected]>
Cc: Joonyoung Shim <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Kyungmin Park <[email protected]>
Signed-off-by: Thierry Reding <[email protected]> (v1)
Reviewed-by: Inki Dae <[email protected]>
Tested-by: Inki Dae <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fallback is in place because VGA connectors can happen to report an
unknown connection status even when they are in fact connected.
Some drivers have custom solutions in place to defer FB helper setup
until at least one output is connected. But the logic behind these
solutions is always the same and there is nothing driver-specific about
it, so a better alterative is to fix the FB helper core and add support
for all drivers automatically.
This patch adds support for deferred FB helper setup. It checks all the
connectors for their connection status, and if all of them report to be
disconnected marks the FB helper as needing deferred setup. Whet setup
is deferred, the FB helper core will automatically retry setup after a
hotplug event, and it will keep trying until it succeeds.
v2: Rebase onto my entirely reworked fbdev helper locking. One big
difference is that this version again drops&reacquires the fbdev lock
(which is now fb_helper->lock, but before this patch series it was
mode_config->mutex), because register_framebuffer must be able to
recurse back into fbdev helper code for the initial screen setup.
v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
return, I've fumbled that in the deferred setup case (Liviu).
v4: I was blind, redo this all. __drm_fb_helper_initial_config
shouldn't need to reacquire fb_helper->lock, that just confuses
callers. I myself got confused by kernel_fb_helper_lock and somehow
thought it's the same as fb_helper->lock. Tsk.
Also simplify the logic a bit (we don't need two functions to probe
connectors), we can stick much closer to the existing code. And update
some comments I've spotted that are outdated.
v5: Don't pass -EAGAIN to drivers, it's just an internal error code
(Liviu).
v6: Add _and_unlock suffix to clarify locking (Maarten)
Cc: Liviu Dudau <[email protected]>
Cc: John Stultz <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Tested-by: John Stultz <[email protected]>
Signed-off-by: Thierry Reding <[email protected]> (v1)
Reviewed-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Liviu Dudau <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring <[email protected]>
Cc: Russell King <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: Inki Dae <[email protected]>
Cc: Joonyoung Shim <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Kyungmin Park <[email protected]>
Cc: Kukjin Kim <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Xinliang Liu <[email protected]>
Cc: Rongrong Zou <[email protected]>
Cc: Xinwei Kong <[email protected]>
Cc: Chen Feng <[email protected]>
Cc: CK Hu <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Matthias Brugger <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Carlo Caione <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Mark Yao <[email protected]>
Cc: Heiko Stuebner <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Chen-Yu Tsai <[email protected]>
Cc: Jyri Sarha <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Partially-Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
[seanpaul changed subject prefix and fixed conflict in stm/ltdc.c]
Signed-off-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
I need this to be able to apply the deferred fbdev setup patches, I
need the relevant prep work that landed through the drm-intel tree.
Also squash in conflict fixup from Laurent Pinchart.
Signed-off-by: Daniel Vetter <[email protected]>
|