| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Now after the move to use drm_plane_state directly struct drm_plane_state
has many unused fields, along with others that weren't used before the
plane state change. Thus remove them all.
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
For some fields the use of struct exynos_drm_plane filled with data from
the plane state just creates a source of duplicated information and
overhead. Here we change the crtc drivers to access the plane state
directly simplifying the code by not relying on a exynos internal struct.
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
We already have the plane pointer in before calling .update_plane() or
disable_plane() so pass it directly to those calls avoiding a new
conversion from zpos to struct exynos_drm_plane.
v2: don't remove check for suspended in FIMD (comment by Joonyoung)
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Rename win_commit() helper to update_plane() and win_disable() to
disable_plane().
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The same check is placed twice in fimd/decon_update_plane(), remove
one of them.
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Get rid of legacy DRM vblank function that are less clear to use.
The new ones basically requires only the crtc as parameters.
It also clean ups exynos_drm_crtc_finish_pageflip() parameters as a
consequence.
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Instead of giving -1 to as arg to drm_send_vblank_event() pass the
correct pipe number to it.
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
This is simplest solution about reported problem[1]. It's no problem to
clear channel only when iommu is enabled, if we consider that we cannot
recognize iommu errors when iommu is disabled and it have been valid
until now. But this cannot be nice solution.
[1] https://lkml.org/lkml/2015/7/21/404
Reported-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Already drm_iommu_attach_device checks whether support iommu internally.
It should clear channels always regardless iommu support. We didn't know
because we can detect the problem when iommu is enabled, so we don't
have to use drm_iommu_attach_device_if_possible and then we can remove
drm_iommu_attach_device_if_possible and clear_channels function pointer.
Signed-off-by: Joonyoung Shim <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The vidi is virtual kms driver and now it is registered earlier than
actual hw kms drivers, so it will occupy crtc index 0. Some users
assume the condition yet that actual hw kms driver has crtc index 0.
It may or may not be matter but let's arrange register order.
Signed-off-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Driver uses only VSYNC interrupts, so we need to cache VSYNC bit state only.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The driver uses bool protected by mutex to track power state.
The patch replaces this combo with single bit and atomic bitops.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Already drm_iommu_attach_device and drm_iommu_detach_device check
whether support iommu internally, so we don't have to call
is_drm_iommu_supported before call them.
Signed-off-by: Joonyoung Shim <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
If CONFIG_ARM_DMA_USE_IOMMU is disable, CONFIG_DRM_EXYNOS_IOMMU also is
disable. When CONFIG_DRM_EXYNOS_IOMMU is disable,
is_drm_iommu_supported() returns always false, so we can remove to use
ifdef CONFIG_ARM_DMA_USE_IOMMU in is_drm_iommu_supported().
Signed-off-by: Joonyoung Shim <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The unique results of all the combination of rotation and flip can
be represented by just 8 states. This patch handles all the combination
correctly.
Signed-off-by: Hyungwon Hwang <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The patch removes intermediate struct for HDMIv14 register configuration,
instead registry values are calculated on the fly.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The patch removes intermediate struct for HDMIv13 register configuration,
instead registry values are calculated on the fly.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The patch removes redundant fields from hdmi_conf_regs. Their values
can be calculated from current_mode. This patch is the first step to remove
whole hdmi_conf_regs structure.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The patch replaces duplicated driver data fields in private context with
pointer to driver data. It also simplifies driver data lookup code.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Most of the code is called by drm core framework, so it is already synchronized.
The only async function is irq routine which only calls drm framework so it
does not need to be synchronized.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
GPIO is tested only in hdmi_detect, so there is no reason to set it in
other places and to preserve its value in context.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
s5p_hdmi_platform_data were used before device tree introduction.
As HDMI driver is DT only we can drop this struct completely.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Once pm_runtime_set_active() gets called, the kernel assumes that given
device has already enabled runtime pm and will call pm_runtime_suspend()
without matching pm_runtime_resume(). In case of DRM FIMC IPP driver,
this will result in calling clk_disable() without respective call to
clk_enable(). This patch removes call to pm_runtime_set_active() to
ensure that pm_runtime_suspend/resume calls will match.
Signed-off-by: Marek Szyprowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
INT_EN cache field was updated only by mixer_enable_vblank.
The patch adds update also by mixer_disable_vblank function.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Specification advises to clear vsync indicator before configuring vsync.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The driver used incorrect flags to clear interrupt status.
The patch fixes it.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
edid returned by drm_get_edid should be freed.
The patch fixes it.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Joonyoung Shim <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The bits for rotation are not used as exclusively. So GSC_IN_ROT_270 can
not be used for swap detection. The definition of it is same with
GSC_IN_ROT_MASK. It is enough to check GSC_IN_ROT_90 bit is set or not to
check whether width / height size swapping is needed.
Signed-off-by: Hyungwon Hwang <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
git://people.freedesktop.org/~gabbayo/linux into drm-next
Two small bug fixes for the code you pulled for 4.3:
- Used a SHIFT define instead of a MASK define to check if a bit is turned on
when destroying hqd. Luckily, this is in gfx7 interface file with amdgpu,
which was used only for bring-up purposes of amdgpu, so no real effect on
a running system
- Used a logical AND instead of a bitwise AND operator, when initializing
sdma virtual memory when using SDMA queues
* tag 'drm-amdkfd-next-fixes-2015-08-05' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: fix bug when initializing sdma vm
drm/amdgpu: fix bug when amdkfd destroys hqd
|
|
http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next
This serie of patches fix minor bugs around how driver sub-components are
bind and planes z-ordering.
The main part is about atomic support: using more atomic helpers allow us
to simplify the code (~300 lines removed) and to ahve a better match between
drm concepts (planes and crtc) and hardware split.
[airlied: fixed up conflict in atomic code]
* 'drm-sti-next-atomic-2015-08-11' of http://git.linaro.org/people/benjamin.gaignard/kernel:
drm/sti: atomic crtc/plane update
drm/sti: rename files and functions
drm/sti: code clean up
drm/sti: fix dynamic z-ordering
drm: sti: fix sub-components bind
|
|
Instead of using the legacy VBLANK API, use the new KMS API. This is
part of an effort to convert all existing users so that the KMS API can
be changed to properly use per-CRTC data.
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Some of the functions are documented inconsistently. Add Returns:
sections where missing and use consistent style to describe the return
value.
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Name all references to the pipe number (CRTC index) consistently to make
it easier to distinguish which is a pipe number and which is a pointer
to struct drm_crtc.
While at it also make all references to the pipe number unsigned because
there is no longer any reason why it should ever be negative.
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
When accessing the array of per-CRTC VBLANK structures we must always
check that the index into the array is valid before dereferencing to
avoid crashing.
Signed-off-by: Thierry Reding <[email protected]>
[danvet: Squash in my own whitespace ocd fixup in drm_vblank_count.]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The drm_send_vblank_event() function treats negative CRTC indices as
meaning that a driver doesn't have proper VBLANK handling. This is the
only place where DRM needs negative CRTC indices, so in order to enable
subsequent cleanup, remove this special case and replace it by the more
obvious check for whether or not VBLANK support was initialized.
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Rather than a mix of the the sized uint32_t and signed integer, use an
unsized unsigned int to specify the format count.
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.
mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.
Changelog v2:
- change it to else if
Signed-off-by: Inki Dae <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Instead of our own duplicated one. This fixes a bug in the driver
unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
try to unregister the nonexistent fbdev drm_framebuffer.
Cc: Archit Taneja <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Reported-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Without this when a MST connector is removed drm_atomic_helper_set_config
can complain about set->mode && !set->num_connectors.
------------[ cut here ]------------
WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_helper.c:1673 drm_atomic_helper_set_config+0x22e/0x420()
CPU: 2 PID: 2403 Comm: kms_flip Not tainted 4.2.0-rc5 #4233
Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
ffffffff81ac75e8 ffff88004e4ffbf8 ffffffff81714c34 0000000080000000
0000000000000000 ffff88004e4ffc38 ffffffff8107bf81 ffff88004e4ffc48
ffff8800d8ca0690 ffff8800d8d7a080 ffff8800d8cc2290 ffff8800d07bc9f0
Call Trace:
[<ffffffff81714c34>] dump_stack+0x4f/0x7b
[<ffffffff8107bf81>] warn_slowpath_common+0x81/0xc0
[<ffffffff8107c065>] warn_slowpath_null+0x15/0x20
[<ffffffff813d9e3e>] drm_atomic_helper_set_config+0x22e/0x420
[<ffffffff813da174>] ? drm_atomic_helper_plane_set_property+0x84/0xc0
[<ffffffff813ee101>] drm_mode_set_config_internal+0x61/0x100
[<ffffffff813dc4ed>] restore_fbdev_mode+0xbd/0xe0
[<ffffffff813de1e4>] drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
[<ffffffffc0123d11>] intel_fbdev_restore_mode+0x21/0x80 [i915]
[<ffffffffc014bf69>] i915_driver_lastclose+0x9/0x10 [i915]
[<ffffffff813e2429>] drm_lastclose+0x29/0x130
[<ffffffff813e2844>] drm_release+0x314/0x500
[<ffffffff81194795>] __fput+0xe5/0x1f0
[<ffffffff811948d9>] ____fput+0x9/0x10
[<ffffffff810968d8>] task_work_run+0x88/0xb0
[<ffffffff8107d53f>] do_exit+0x37f/0xa90
[<ffffffff8127e258>] ? selinux_file_ioctl+0x48/0xc0
[<ffffffff81277dfe>] ? security_file_ioctl+0x3e/0x60
[<ffffffff8107ec80>] do_group_exit+0x40/0xa0
[<ffffffff8107ecef>] SyS_exit_group+0xf/0x10
[<ffffffff8171bdd7>] entry_SYSCALL_64_fastpath+0x12/0x6a
---[ end trace 0daf358c49351567 ]---
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We want to make sure that no one tries to acquire more locks and
states, and ww mutexes provide debug facilities for that. So use them.
v2: Only call acquire_done when ->atomic_check was successful to avoid
falling over an -EDEADLK (spotted by Maarten).
Cc: Rob Clark <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
In
commit 6f75cea66c8dd043ced282016b21a639af176642
Author: Daniel Vetter <[email protected]>
Date: Wed Nov 19 18:38:07 2014 +0100
drm/atomic: Only destroy connector states with connection mutex held
I tried to fix races of atomic commits against connector
hot-unplugging. The idea is to ensure lifetimes by holding the
connection_mutex long enough. That works for synchronous commits, but
not for async ones.
For async atomic commit we really need to fix up connector lifetimes
for real. But that's a much bigger task, so just add more duct-tape:
For cleaning up connector states we currently don't need the connector
itself. So NULL it out and remove the locking check. Of course that
check was to protect the entire sequence, but the modeset itself
should be save since currently DP MST hot-removal does a dpms-off. And
that should synchronize with any outstanding async atomic commit.
Or at least that's my hope, this is all a giant mess.
Reported-by: Maarten Lankhorst <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Spotted while reading code for random reasons.
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
It really doesn't protect anything which doesn't have other locks
already. It also doesn't seem to be wired up into the driver unload
code fwiw, but that's a different issue.
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This is only called in driver load/unload paths, no need to grab any
locks at all. Also, ttm takes care of itself anyway.
Cc: Ben Skeggs <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Aside: I stumbled over the mmap handler which directly does a
dma_mmap_attrs. But totally fails to grab a reference on the
underlying object and hence looks like it happily just leaks the ptes
since there's no guarantee the mmap isn't still around when
gem_free_object is called. Which the kerneldoc of dma_mmap_attrs
explicitly forbids.
v2: Fixup compile fail 0-day spotted.
Cc: Mark Yao <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Cc: Laurent Pinchart <[email protected]>
Cc: Rob Clark <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Looking up an obj, immediate dropping the acquired reference and then
continuing to use it isn't how this is supposed to work. Fix this by
holding a reference for the entire function.
While at it stop grabbing dev->struct_mutex, it doesn't protect
anything here.
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|