IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The goal is to push all the kms locking down into these separate
_atomic and _legacy functions, so that we can correctly pass the
acquire ctx into all atomic drivers. Instead of playing games with
hidden ctx in mode_config.acquire_ctx. All the fbdev state will be
protected by a new fbdev private lock that Thierry is working on.
This here is just prep by creating a clean split between atomic and
legacy paths, which also simplifies the control flow a bit.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-16-daniel.vetter@ffwll.ch
It just doesn't work. It probably stopped working way, way before that
(e.g. i915 grabbed random mutexes all over in modeset code at least
since gen6), but with atomic and all the ww_mutex stuff it's indeed
hopeless.
Remove ->mode_set_base_atomic from the 2 atomic drivers (i915 and
nouveau) that still had one (both had dummy implementations already
anyway), and shunt atomic drivers in the helpers debug_enter/leave
functions.
I'll leave the code in for radeon and amdgpu, but I think as soon as
amdgpu is atomic we should think about just ripping it out. Only
having it around for radeon and pre-nv50 is rather pointless. This
would also allow us to nuke all that code from fbdev.
Funny part is that _all_ kms drivers set this hook, despite that no
one else provides the required ->mode_set_base_atomic implementation.
The reason I'm jumping on this is that I want to wire up a full
acquire ctx for the benefit of atomic drivers, everywhere. And the
debug_enter/leave implementations call ->gamma_set. And there's just
no way ever we can create an acquire_ctx in the nmi context of kgdb.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-11-daniel.vetter@ffwll.ch
Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
the i.MX6.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently the functions that initialize and tear down a connector
iterator use the _get() and _put() suffixes. However, these suffixes
are typically used by reference counting functions.
Make these function names a little more consistent by changing the
suffixes to _begin() and _end(), which is a fairly common pattern in
the rest of the Linux kernel.
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-8-thierry.reding@gmail.com
For consistency with other reference counting APIs in the kernel, add
drm_connector_get() and drm_connector_put() functions to reference count
connectors.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.
The existing semantic patch for mode object reference count conversion
is extended for these new helpers.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-4-thierry.reding@gmail.com
Backmerge the main pull request to sync up with all the newly landed
drivers. Otherwise we'll have chaos even before 4.12 started in
earnest.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.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
drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.
Note that register_framebuffer will do a modeset (when fbcon is enabled)
and hence must be moved out of the critical section. A follow-up patch
will add new locking for the fb list, hence move all the related
registration code together.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-2-chris@chris-wilson.co.uk
The fb_helper->connector_count is modified when a new connector is
constructed following a hotplug event (e.g. DP-MST). This causes trouble
for drm_setup_crtcs() and friends that assume that fb_helper is
constant:
[ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at addr ffff88074cdd2608
[ 1250.873020] Write of size 40 by task kworker/u8:3/480
[ 1250.873039] CPU: 2 PID: 480 Comm: kworker/u8:3 Tainted: G U 4.9.0-rc6+ #285
[ 1250.873043] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 1250.873050] Workqueue: events_unbound async_run_entry_fn
[ 1250.873056] ffff88070f9d78f0 ffffffff814b72aa ffff88074e40c5c0 ffff88074cdd2608
[ 1250.873067] ffff88070f9d7918 ffffffff8124ff3c ffff88070f9d79b0 ffff88074cdd2600
[ 1250.873079] ffff88074e40c5c0 ffff88070f9d79a0 ffffffff812501e4 0000000000000005
[ 1250.873090] Call Trace:
[ 1250.873099] [<ffffffff814b72aa>] dump_stack+0x67/0x9d
[ 1250.873106] [<ffffffff8124ff3c>] kasan_object_err+0x1c/0x70
[ 1250.873113] [<ffffffff812501e4>] kasan_report_error+0x204/0x4f0
[ 1250.873120] [<ffffffff81698df0>] ? drm_dev_printk+0x140/0x140
[ 1250.873127] [<ffffffff81250ac3>] kasan_report+0x53/0x60
[ 1250.873134] [<ffffffff81688b40>] ? drm_setup_crtcs+0x320/0xf80
[ 1250.873142] [<ffffffff8124f18e>] check_memory_region+0x13e/0x1a0
[ 1250.873147] [<ffffffff8124f5f3>] memset+0x23/0x40
[ 1250.873154] [<ffffffff81688b40>] drm_setup_crtcs+0x320/0xf80
[ 1250.873161] [<ffffffff810be7c5>] ? wake_up_q+0x45/0x80
[ 1250.873169] [<ffffffff81b0c180>] ? mutex_lock_nested+0x5a0/0x5a0
[ 1250.873176] [<ffffffff8168a0e6>] drm_fb_helper_initial_config+0x206/0x7a0
[ 1250.873183] [<ffffffff81689ee0>] ? drm_fb_helper_set_par+0x90/0x90
[ 1250.873303] [<ffffffffa0b68690>] ? intel_fbdev_fini+0x140/0x140 [i915]
[ 1250.873387] [<ffffffffa0b686b2>] intel_fbdev_initial_config+0x22/0x40 [i915]
[ 1250.873391] [<ffffffff810b50ff>] async_run_entry_fn+0x7f/0x270
[ 1250.873394] [<ffffffff810a64b0>] process_one_work+0x3d0/0x960
[ 1250.873398] [<ffffffff810a641d>] ? process_one_work+0x33d/0x960
[ 1250.873401] [<ffffffff810a60e0>] ? max_active_store+0xf0/0xf0
[ 1250.873406] [<ffffffff810f6f9d>] ? do_raw_spin_lock+0x10d/0x1a0
[ 1250.873413] [<ffffffff810a767d>] worker_thread+0x8d/0x840
[ 1250.873419] [<ffffffff810a75f0>] ? create_worker+0x2e0/0x2e0
[ 1250.873426] [<ffffffff810b0454>] kthread+0x194/0x1c0
[ 1250.873432] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873438] [<ffffffff810f095d>] ? trace_hardirqs_on+0xd/0x10
[ 1250.873446] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873453] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873457] [<ffffffff81b12277>] ret_from_fork+0x27/0x40
[ 1250.873460] Object at ffff88074cdd2608, in cache kmalloc-32 size: 32
However, when holding the mode_config.lock around the fb_helper, we have
to be careful of any callbacks that may reenter the fb_helper and so try
to reacquire the mode_config.lock (e.g. register_framebuffer). To avoid
the mutex recursion, we have to rearrange the sequence to move the
registration into the caller outside of the mode_config.lock.
v2: drop the 1; following the lockdep assertion inside the for(;;), I
anticipated an error that doesn't happen!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-1-chris@chris-wilson.co.uk
smatch correctly warns:
drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn: should '1 << i' be a 64 bit type?
drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn: should '1 << i' be a 64 bit type?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A drm driver that is implementing
fb_debug_enter and fb_debug_leave
in struct fb_ops with drm fb helper functions
drm_fb_helper_debug_enter and drm_fb_helper_debug_leave
must also implement the callback 'mode_set_base_atomic' in struct
drm_crtc_helper_funcs. See Documentation/DocBook/kgdb.tmpl. The current
implementation will segfault when 'mode_set_base_atomic' is a NULL
pointer.
Before this patch at least the drm drivers armada, ast, qxl, udl and
virtio do not have a 'mode_set_base_atomic' implementation but using
drm_fb_helper_debug_(enter|leave). So these drivers may segfault when
callbacks fb_debug_(enter|leave) are called.
Avoid the issue by just checking for NULL pointers. So all drivers can
unconditionally implement fb_debug_(enter|leave) with the drm_fb_helper
functions. If callback 'mode_set_base_atomic' is not implemented, the
code in drm_fb_helper_debug_(enter|leave) does effectively nothing.
Signed-off-by: Stefan Christ <contact@stefanchrist.eu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1479078208-25221-2-git-send-email-contact@stefanchrist.eu
The fbdev helper code keeps around two lists of connectors. One is the
list of all connectors it could use, and that list already holds
references for all the connectors. However the other list, or rather
lists, is the one actively being used. That list is tracked per-crtc
and currently doesn't hold any extra references. Let's grab those
extra references to avoid oopsing when the connector vanishes. The
list of all possible connectors should get updated when the hpd happens,
but the list of actively used connectors would not get updated until
the next time the fb-helper picks through the set of possible connectors.
And so we need to hang on to the connectors until that time.
Since we need to clean up in drm_fb_helper_crtc_free() as well,
let's pull the code to a common place. And while at it let's
pull in up the modeset->mode cleanup in there as well. The case
of modeset->fb is a bit less clear. I'm thinking we should probably
hold a reference to it, but for now I just slapped on a FIXME.
v2: Cleanup things drm_fb_helper_crtc_free() too (Chris)
v3: Don't leak modeset->connectors (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com> (v1)
Tested-by: Kirill A. Shutemov <kirill@shutemov.name> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477492878-4990-1-git-send-email-ville.syrjala@linux.intel.com
Since 4.7 kernel, we've seen the error messages like
kernel: [TTM] Buffer eviction failed
kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001)
kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO
on QXL when switching and accessing on VT. The culprit was the
generic deferred_io code (qxl driver switched to it since 4.7).
There is a race between the dirty clip update and the call of
callback.
In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
while it kicks off the update worker outside the spinlock. Meanwhile
the update worker clears the dirty clip in the spinlock, too. Thus,
when drm_fb_helper_dirty() is called concurrently, schedule_work() is
called after the clip is cleared in the first worker call.
This patch addresses it by validating the clip before calling the
dirty fb callback.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
Fixes: eaa434defa ('drm/fb-helper: Add fb_deferred_io support')
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161020150530.5787-1-tiwai@suse.de
Linux 4.8-rc8
There was a lot of fallout in the imx/amdgpu/i915 drivers, so backmerge
it now to avoid troubles.
* tag 'v4.8-rc8': (1442 commits)
Linux 4.8-rc8
fault_in_multipages_readable() throws set-but-unused error
mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing
radix tree: fix sibling entry handling in radix_tree_descend()
radix tree test suite: Test radix_tree_replace_slot() for multiorder entries
fix memory leaks in tracing_buffers_splice_read()
tracing: Move mutex to protect against resetting of seq data
MIPS: Fix delay slot emulation count in debugfs
MIPS: SMP: Fix possibility of deadlock when bringing CPUs online
mm: delete unnecessary and unsafe init_tlb_ubc()
huge tmpfs: fix Committed_AS leak
shmem: fix tmpfs to handle the huge= option properly
blk-mq: skip unmapped queues in blk_mq_alloc_request_hctx
MIPS: Fix pre-r6 emulation FPU initialisation
arm64: kgdb: handle read-only text / modules
arm64: Call numa_store_cpu_info() earlier.
locking/hung_task: Fix typo in CONFIG_DETECT_HUNG_TASK help text
nvme-rdma: only clear queue flags after successful connect
i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended
perf/core: Limit matching exclusive events to one PMU
...
There can only be one current master, and it's for the overall device.
Render/control minors don't support master-based auth at all.
This simplifies the master logic a lot, at least in my eyes: All these
additional pointer chases are just confusing.
While doing the conversion I spotted some locking fail:
- drm_lock/drm_auth check dev->master without holding the
master_mutex. This is fallout from
commit c996fd0b95
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date: Tue Feb 25 19:57:44 2014 +0100
drm: Protect the master management with a drm_device::master_mutex v3
but I honestly don't care one bit about those old legacy drivers
using this.
- debugfs name info should just grab master_mutex.
- And the fbdev helper looked at it to figure out whether someone is
using KMS. We just need a consistent value, so READ_ONCE. Aside: We
should probably check if anyone has opened a control node too, but I
guess current userspace doesn't really do that yet.
v2: Balance locking, reported by Julia.
v3: Rebase on top of Chris' oops fixes.
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-1-git-send-email-daniel.vetter@ffwll.ch
