If the driver is in suspended mode, the dp block may be disabled, and
chip registers may not be accessible. Yet, the worker may be triggered
in this situation by an extcon event. If that happens, the following crash
will be seen.
cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] *ERROR* Enable dp failed -19
cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Connected, not enabled. Enabling cdn
Bad mode in Error handler detected, code 0xbf000002 -- SError
CPU: 1 PID: 10357 Comm: kworker/1:2 Not tainted 4.4.21-05903-ge0514ea #1
Hardware name: Google Kevin (DT)
Workqueue: events cdn_dp_pd_event_work
task: ffffffc0cda67080 ti: ffffffc0b9b80000 task.ti: ffffffc0b9b80000
PC is at cdn_dp_clock_reset+0x30/0xa8
LR is at cdn_dp_enable+0x1e0/0x69c
...
Call trace:
[<ffffffc0005a7e24>] cdn_dp_pd_event_work+0x58/0x3f4
[<ffffffc0002397f0>] process_one_work+0x240/0x424
[<ffffffc00023a28c>] worker_thread+0x2fc/0x424
[<ffffffc00023f5fc>] kthread+0x10c/0x114
[<ffffffc000203dd0>] ret_from_fork+0x10/0x40
Problem is two-fold: The worker should not run while suspended, and the
suspend function should not call cdn_dp_disable() while the worker is
running.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
If no monitor is connected, suspend/resume cycles result in firmware
load errors because the driver attempts to load the firmware while
the system is in suspend state. This results in a kernel warning and
traceback.
Loading the firmware during boot fixes the problem. Note that we can not
just call schedule_work conditionally in cdn_dp_pd_event() if the insertion
status changed. The problem would still be seen if a monitor is connected
for the first time during suspend.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
[seanpaul fixed up some races between the worker and modeset]
[seanpaul squashed ~15 commits from chromium.org gerrit]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[groeck fixed compilation errors when building as module]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
rockchip_drm_framebuffer_init is only used in one case, in
rockchip_drm_fbdev.c, where its return value is tested using IS_ERR. To
enable propagating the reason for the error, change the definition so that
it returns an ERR_PTR value.
Problem found with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
The setting of vop registers need a reg_done writing to take effect.
In vop_enable the vop return to work by by restoring registers, but the
registers do not take effect immediately, it should a vop_cfg_done
after it. The same thing is needed by windows_disabled in
vop_crtc_disable.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202114434.3060-2-chris@chris-wilson.co.uk
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.
v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> # vmwgfx
Reviewed-by: Lucas Stach <l.stach@pengutronix.de> #etnaviv
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202210438.28702-1-chris@chris-wilson.co.uk
It includes code cleanups from Bhumika and Liviu, a significant shader
performance fix and additions to the cmdstream validator from Wladimir
and the addition of a cmdbuf suballocator by myself.
The suballocator improves performance on all chips by reducing the CPU
overhead of the kernel driver and side steps the GC3000 FE MMU flush
erratum, now making the workarounds in IOVA allocation we had before
unnecessary, which results in a nice cleanup of the code in that area.
* 'drm-etnaviv-next' of https://git.pengutronix.de/git/lst/linux:
drm/etnaviv: Remove duplicate header file include
Revert "drm/etnaviv: trick drm_mm into giving out a low IOVA"
drm/etnaviv: add cmdbuf suballocator
drm/etnaviv: get cmdbuf physical address through the cmdbuf abstraction
drm/etnaviv: wire up iova handling in new cmdbuf abstraction
drm/etnaviv: move cmdbuf de-/allocation into own file
drm/etnaviv: always flush MMU TLBs on map/unmap
drm/etnaviv: constify etnaviv_iommu_ops structures
drm/etnaviv: set up initial PULSE_EATER register
drm/etnaviv: add new GC3000 sensitive states
Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is
disabled because it didn't update the prototype for drm_fb_helper_init
in that case.
Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization")
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202193900.22075-1-krisman@collabora.co.uk
We don't add any fences do the buffer, but just use it's address.
Additional to that we don't need a duplicates list here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Somebody could try to free the bo_va between mapping and updating it.
v2: fix typos in comment
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.
I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates. The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.
// <smpl>
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
// </smpl>
Changes since v1:
- Rebased on top of the tip of drm-misc-next.
- Remove mention to sti since a proper fix got merged.
Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected (i.e. the current
pattern of the driver tearing down its state and then releasing a
reference to the drm device) and yet touch driver private state when
destroyed.
v2: Export drm_dev_fini() and move the responsibility for finalizing the
drm_device and freeing it to the release callback. (If no callback is
provided, the core will call drm_dev_fini() and kfree(dev) as before.)
v3: Remember to add drm_dev_fini() to drm_drv.h
v4: Tidy language for kerneldoc
v5: Cross reference from drm_dev_init() to note that driver->release()
allows for arbitrary embedding.
v6: Refer to driver data rather than driver state, as state is now
becoming associated with the struct drm_atomic_state and friends.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[danvet: Use the proper reference for struct members, which is
&drm_driver.release.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202093632.31017-1-chris@chris-wilson.co.uk
The platform driver name is currently "meson" which can lead to some
confusion, this patch renames it to "meson-drm" and removes the owner
attribute since is always added by __platform_driver_register called by the
module_platform_driver() macro.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1486028864-19622-3-git-send-email-narmstrong@baylibre.com
Since all sub-protocols of MHL3 are already supported MHL3 mode can be
enabled. With this patch it is possible to use packed pixel modes and
clocks up to 300MHz - 1920x1080@60Hz and 4K modes.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1485935272-17337-25-git-send-email-a.hajda@samsung.com
MHL3 protocol requires registry adjustments depending on chosen video mode.
Necessary information is gathered in mode_fixup callback. In case of HDMI
video modes driver should also send special AVI and MHL3 infoframes.
The patch introduces generic helpers for handling MHL3 infoframes, in
case of appearance of other users of MHL3 infoframes these function can
be moved to common library.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1485935272-17337-21-git-send-email-a.hajda@samsung.com
The Single-ended eCBUS Mode (eCBUS-S) mode provides 60 Mb/s full-duplex
bidirectional traffic for three channels:
- CBUS data (CBUS1 channel),
- High-bandwidth MHL data (eMSC channel),
- tunneling data (T-CBUS channel).
It is required to fully support MHL3 dongles.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1485935272-17337-6-git-send-email-a.hajda@samsung.com
Due to asynchronous nature of MHL flow of execution is dispersed.
Logical continuation of some actions happens after response of peer,
i.e in interrupt handler. To simplify coding continuation mechanism
has been added - it is now possible to provide continuation callback,
which will be called after peer responds to given action.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1485935272-17337-5-git-send-email-a.hajda@samsung.com
Now that commandstreams are handled through the cmdbuf suballocator
the workaround to make the IOVA games work is not needed anymore.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
There are 3 big benefits to suballocating a single big DMA buffer
for command submission:
1. Avoid hammering CMA. The old way of allocating and freeing a DMA
buffer for each submission was hitting some of the real slow
pathes in CMA, as this allocator was not designed for a concurrent
small buffers load.
2. Less TLB flushes on IOMMUv2. If a new command buffer is mapped into
the GPU address space the MMU TLBs need to be flushed. By having
one big buffer statically mapped to the GPU, a lot of those flushes
can be avoided.
3. No funky workarounds for GC3000. The FE TLB flush on GC3000 isn't
reliable. To work around that we tried to lay out the cmdbufs in
the GPU address space in a way to avoid this issue. This hasn't
always worked if the address space is crowded. A single statically
mapped buffer avoids the erratum completely.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Don't allow IOMMUv2 to peek directly into the cmdbuf, but get the
needed PA through a dedicated function.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Don't call the IOMMU directly, but go through the new cmdbuf abstraction.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This will get more complex with the following changes, so move it
into its own place.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This ensures that the GPU isn't able to write into already freed
objects, as doing this in the IOVA reaper isn't enough, as the
gem_free_object path will also cause unmaps to happen.
On MMUv2 this also ensures that stale entries, which may have
been prefetched into the TLB will be purged.
The flush is low overhead, as it gets batched up with the next
user command buffer, so this isn't incuring an overhead for
each buffer map/unmap.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Declare etnaviv_iommu_ops structure as const as it is only used when
the reference of one of its field is stored in the ops field of a
iommu_domain structure. This ops field is of type const, so
etnaviv_iommu_ops structures having similar properties can be declared
const too.
Done using Coccinelle.
Before and after size details of .o file remains the same after
cross compiling for arm architecture.
lst: Trimmed commit message, apply the same change to iommu_v2.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
