drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.
Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.
Only moving and changing fb is allowed.
Changes since v1:
- Set page flip to always_unused for trybot.
- Copy fence correctly, ignore plane_state->state, should be NULL.
- Check crtc_state for !active and modeset, go to slowpath if the case.
Changes since v2:
- Make error handling work correctly. (Matthew Auld)
drm/atomic: Wait for vblank whenever a plane is added to state.
There's 2 reasons for doing a vblank wait:
- To fulfill uabi expectations, but the legacy ioctls are ill-defined
enough that we really only need this when we do send out an event.
- To make sure we don't tear down mappings before the scanout engine
stops accessing it.
The later is problematic with the current code since e.g. rotation
might need a different mapping than normal orientation. And rotation
is a plane property, and not on the fb. Hence we need to remove this
optimization.
drm: Don't prepare or cleanup unchanging frame buffers [v3]
The original commit mentions that this prevents waiting in i915 on all
previous rendering during cursor updates, but there are better ways to
fix this.
Kees Cook [Sat, 17 Dec 2016 01:04:42 +0000 (17:04 -0800)]
drm/nouveau: use designated initializers
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Kees Cook [Sat, 17 Dec 2016 01:04:02 +0000 (17:04 -0800)]
drm/vmwgfx: use designated initializers
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Kees Cook [Sat, 17 Dec 2016 01:00:11 +0000 (17:00 -0800)]
drm/ttm: use designated initializers
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Kees Cook [Sat, 17 Dec 2016 00:59:29 +0000 (16:59 -0800)]
drm/ttm: use designated initializers
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Daniel Vetter [Tue, 13 Dec 2016 23:08:10 +0000 (00:08 +0100)]
drm: Tighten locking in drm_mode_getconnector
- Modeset state needs mode_config->connection mutex, that covers
figuring out the encoder, and reading properties (since in the
atomic case those need to look at connector->state).
- Don't hold any locks for stuff that's invariant (i.e. possible
connectors).
- Same for connector lookup and unref, those don't need any locks.
- And finally the probe stuff is only protected by mode_config->mutex.
While at it updated the kerneldoc for these fields in drm_connector
and add docs explaining what's protected by which locks.
Daniel Vetter [Sun, 18 Dec 2016 13:35:45 +0000 (14:35 +0100)]
drm: prevent double-(un)registration for connectors
If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.
v2: Also update the kerneldoc for @registered!
v3: Review from Chris:
- Improve kerneldoc for late_register/early_unregister callbacks.
- Use mutex_destroy.
Daniel Vetter [Tue, 13 Dec 2016 23:08:08 +0000 (00:08 +0100)]
drm: Clean up connectors by unreferencing them
Only static connectors should be left at this point, and we should be
able to clean them out by simply dropping that last reference still
around from drm_connector_init.
If that leaves anything behind then we have a driver bug.
Doing the final cleanup this way also allows us to use
drm_connector_iter, removing the very last place where we walk
connector_list explicitly in drm core&helpers.
Daniel Vetter [Thu, 15 Dec 2016 15:58:43 +0000 (16:58 +0100)]
drm: Convert all helpers to drm_connector_list_iter
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing best to just wrap the entire thing up in one critical
section.
Daniel Vetter [Tue, 13 Dec 2016 23:08:06 +0000 (00:08 +0100)]
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Daniel Vetter [Tue, 13 Dec 2016 23:08:05 +0000 (00:08 +0100)]
drm: Drop locking cargo-cult from drm_mode_config_init
This is single-threaded setup code, no need for locks. And anyway,
all properties need to be set up before the driver is registered
anyway, they can't be hot-added.
Daniel Vetter [Tue, 13 Dec 2016 23:08:03 +0000 (00:08 +0100)]
drm: Move atomic debugfs functions into drm_crtc_internal.h
This is not driver interface stuff.
Fixes: 6559c901cb48 ("drm/atomic: add debugfs file to dump out atomic state") Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-3-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 13 Dec 2016 23:08:02 +0000 (00:08 +0100)]
drm/irq: drm_legacy_ prefix for legacy ioctls
Spotted while auditing our ioctl table. Also nuke the
not-really-kerneldoc comments, we don't document internals and
definitely don't want to mislead people with the old dragons.
I think with this all the legacy ioctls now have proper drm_legacy_
prefixes.
Laurent Pinchart [Mon, 28 Nov 2016 16:32:05 +0000 (18:32 +0200)]
drm: bridge: Detach bridge from encoder at encoder cleanup time
Most drivers that use bridges forgot to detach them at cleanup time.
Instead of fixing them one by one, detach the bridge in the core
drm_encoder_cleanup() function.
Laurent Pinchart [Mon, 28 Nov 2016 15:59:08 +0000 (17:59 +0200)]
drm: bridge: Link encoder and bridge in core code
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the drm_bridge
encoder pointer), do so in core code. The drm_bridge_attach() function
needs the encoder and optional previous bridge to perform that task,
update all the callers.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Stefan Agner <stefan@agner.ch> # For DCU Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> # For atmel-hlcdc Acked-by: Vincent Abriou <vincent.abriou@st.com> # For STI Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> # For sun4i Acked-by: Xinliang Liu <z.liuxinliang@hisilicon.com> # For hisilicon Acked-by: Jyri Sarha <jsarha@ti.com> # For tilcdc Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com
Laurent Pinchart [Mon, 28 Nov 2016 19:03:49 +0000 (21:03 +0200)]
drm: Fix compilation warning caused by static inline forward declaration
The drm_crtc_mask() function used in <drm/drm_encoder.h> is a static
inline defined in <drm/drm_crtc.h>. If the first header is included in a
compilation unit without the second one, the following compilation
warning will be issued.
In file included from <linux>/drivers/gpu/drm/drm_bridge.c:29:0:
<linux>/include/drm/drm_encoder.h:192:95: warning: ‘drm_crtc_mask’ used but never defined
static inline uint32_t drm_crtc_mask(const struct drm_crtc *crtc);
Fix this by including the header defining the function instead of using
a forward declaration.
Laurent Pinchart [Mon, 28 Nov 2016 18:51:09 +0000 (20:51 +0200)]
drm: Don't include <drm/drm_encoder.h> in <drm/drm_crtc.h>
<drm/drm_crtc.h> used to define most of the in-kernel KMS API. It has
now been split into separate files for each object type, but still
includes most other KMS headers to avoid breaking driver compilation.
As a step towards fixing that problem, remove the inclusion of
<drm/drm_encoder.h> from <drm/drm_crtc.h> and include it instead where
appropriate. Also remove the forward declarations of the drm_encoder and
drm_encoder_helper_funcs structures from <drm/drm_crtc.h> as they're not
needed in the header.
<drm/drm_encoder.h> now has to include <drm/drm_mode.h> and contain a
forward declaration of struct drm_encoder in order to allow including it
as the first header in a compilation unit.
Chris Wilson [Fri, 16 Dec 2016 07:46:40 +0000 (07:46 +0000)]
drm/i915: Simplify i915_gtt_color_adjust()
If we remember that node_list is a circular list containing the fake
head_node, we can use a simple list_next_entry() and skip the NULL check
for the allocated check against the head_node.
This makes this patch functionally useless. However, on PPC, there is
actually an explicit definition of atomic_inc_not_zero with its own
assembly that is slightly more optimized than atomic_add_unless. So,
this patch changes kref to use atomic_inc_not_zero instead, for PPC and
any future platforms that might provide an explicit implementation.
This also puts this usage of kref more in line with a verbatim reading
of the examples in Paul McKenney's paper [1] in the section titled "2.4
Atomic Counting With Check and Release Memory Barrier", which uses
atomic_inc_not_zero.
Ville Syrjälä [Thu, 15 Dec 2016 14:29:27 +0000 (16:29 +0200)]
drm/cma: Fix compile fail due to fomat->format typo
Apparently my arm .config had reverted to CMA=n at some point, so I
failed to notice that I typoed the code. Fix it up so that the
cma helper will compile again.
Reported-by: kbuild test robot <fengguang.wu@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Fixes: ca984a998ad3 ("drm/fb_cma_helper: Replace drm_format_info() with fb->format") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161215142927.20761-1-ville.syrjala@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Ville Syrjälä [Fri, 18 Nov 2016 19:53:11 +0000 (21:53 +0200)]
drm: Eliminate the useless "non-RGB fb" debug message
No point in spamming the log whenever a non-RGB fb is being
constructed. And since there's nothing to do anymore that
fb->bits_per_pixel and fb->depth are gone, we can just kill
off this entire piece of code.
Ville Syrjälä [Fri, 18 Nov 2016 19:53:10 +0000 (21:53 +0200)]
drm: Replace 'format->format' comparisons to just 'format' comparisons
Rather than compare the format u32s of two format infos, we can direclty
compare the format info pointers themselves. Noramlly all the ->format
pointers all point to somwehere in the big array, so this is a valid
way to test for equality.
Also drivers may want to point ->format at a private format info struct
instead (eg. for special compressed formats with extra planes), so
just comparing the pixel format values wouldn't necessaritly even work.
But comparing the pointers will also take care of that case.
v2: Fix commit message (Laurent)
Rebase due to earlier removal of many fb->pixel_format uses,
including the 'fb->format = drm_format_info(fb->format->format);'
snafu
v3: Adjusted the semantic patch a bit and regenerated due to code
changes
Ville Syrjälä [Wed, 14 Dec 2016 21:32:20 +0000 (23:32 +0200)]
drm: Nuke fb->bits_per_pixel
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.
Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, and tried to look over the entire diff to spot if
any dangerous expressions were produced. I didn't see any.
There are some cases where previously the code did X*bpp/8, so the
division happened after the multiplication. Those are now just X*cpp
so the division effectively happens before the multiplication,
but that is perfectly fine since bpp is always a multiple of 8.
Ville Syrjälä [Fri, 18 Nov 2016 19:53:05 +0000 (21:53 +0200)]
drm: Add drm_framebuffer_plane_{width,height}()
Add variants of drm_format_plane_{width,height}() that take an entire fb
object instead of just the format. These should be more efficent as they
can just look up the format info from the fb->format pointer rather than
having to look it up (using a linear search based on the format).
Ville Syrjälä [Fri, 18 Nov 2016 19:53:04 +0000 (21:53 +0200)]
drm/i915: Store a pointer to the pixel format info for fbc
Rather than store the pixel format and look up the format info as
needed, let's just store a pointer to the format info directly
and speed up our lookups.
Ville Syrjälä [Fri, 18 Nov 2016 19:53:00 +0000 (21:53 +0200)]
drm/i915: Eliminate the ugly 'fb?:' constructs from the ilk/skl wm code
Don't access plane_state->fb until we know the plane to be visible.
It it's visible, it will have an fb, and thus we don't have to
consider the NULL fb case. Makes the code look nicer.
Ville Syrjälä [Fri, 18 Nov 2016 19:52:58 +0000 (21:52 +0200)]
drm: Reject fbs w/o format info in drm_framebuffer_init()
Any framebuffer that doesn't have proper format information when
drm_framebuffer_init() is called is a bug. Let's warn and return
an error to avoid oopsing the kernel later due to dereferencing the
NULL fb->format pointer.
Ville Syrjälä [Fri, 18 Nov 2016 19:52:57 +0000 (21:52 +0200)]
drm/i915: Populate fb->format early for inherited fbs
Make sure the framebuffer format info is available as early as possible
for fbs we inherit from the BIOS. This will allow us to use the fb as
if it was fully formed before we register it.
Ville Syrjälä [Fri, 18 Nov 2016 19:52:54 +0000 (21:52 +0200)]
drm: Populate fb->dev from drm_helper_mode_fill_fb_struct()
Populating fb->dev before drm_framebuffer_init() allows us to use
fb->dev already while validating the framebuffer. Let's have
drm_helper_mode_fill_fb_struct() do that for us.
Also make drm_framebuffer_init() warn us if a different device
pointer is passed to it than was passed to
drm_helper_mode_fill_fb_struct().
Ville Syrjälä [Fri, 18 Nov 2016 19:52:53 +0000 (21:52 +0200)]
drm/i915: Set fb->dev early on for inherited fbs
We want the fbs inherited from the BIOS to be more or less fully working
prior to actually registering them. This will allow us to just pass the
fb to various helper function instead of having to pass all the
different parameters separately.
Ville Syrjälä [Fri, 18 Nov 2016 19:52:52 +0000 (21:52 +0200)]
drm/virtio: Call drm_helper_mode_fill_fb_struct() before drm_framebuffer_init()
We want framebuffers to be mostly useable already before
drm_framebuffer_init() get called, and so we will start demanding that
all the interesting format/size/etc. information be filled in before
drm_framebuffer_init(). drm_helper_mode_fill_fb_struct() will do that
for us, so let's make sure it gets called before drm_framebuffer_init().
Ville Syrjälä [Fri, 18 Nov 2016 19:52:51 +0000 (21:52 +0200)]
drm/qxl: Call drm_helper_mode_fill_fb_struct() before drm_framebuffer_init()
We want framebuffers to be mostly useable already before
drm_framebuffer_init() is called, and so we will start demanding that
all the interesting format/size/etc. information be filled in before
drm_framebuffer_init(). drm_helper_mode_fill_fb_struct() will do that
for us, so let's make sure it gets called before drm_framebuffer_init().
Ville Syrjälä [Wed, 14 Dec 2016 20:48:59 +0000 (22:48 +0200)]
drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
populate fb->dev early. Will make it easier to use the fb before we
register it.
Ville Syrjälä [Fri, 18 Nov 2016 19:52:46 +0000 (21:52 +0200)]
drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail
So it looks like the code is trying to pick between the passed in fb and
crtc->primary->fb based on that funky 'bool atomic'. But later it will
mix uses of both drm_fb (which was picked by the aforementioned logic)
and crtc->primary->fb. So looks like a bug to me. Let's make it use
drm_fb only.
Daniel Vetter [Tue, 13 Dec 2016 17:54:49 +0000 (18:54 +0100)]
drm/fsl: don't use drm_put_dev
fsl is already fully demidlayered in the probe function, but for
convenience stuck with drm_put_dev. Call the unregister/unref parts
separately, to make sure this driver works correct.
Daniel Vetter [Tue, 13 Dec 2016 21:23:18 +0000 (22:23 +0100)]
Merge tag 'drm-for-v4.10' of git://people.freedesktop.org/~airlied/linux into drm-misc-next
Main pull request for drm for 4.10 kernel - resync drm-misc with full
4.10 state (2 new drivers) so that we can start pulling in all the
refactorings for 4.11!
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Thu, 8 Dec 2016 11:07:36 +0000 (12:07 +0100)]
drm/etnaviv: Use drm_dev_unref, not drm_put_dev
drm_put_dev is the old midlayer-broken device cleanup function, but
etnaviv has a proper unbind function which first unregisters and then
drops the final reference. No functional change since
drm_dev_unregister happens to be idempotent.
Daniel Vetter [Thu, 8 Dec 2016 11:07:38 +0000 (12:07 +0100)]
drm/mediatek: don't use drm_put_dev
fsl is already fully demidlayered in the probe function, but for
convenience stuck with drm_put_dev. Call the unregister/unref parts
separately, to make sure this driver works correct.
Daniel Vetter [Fri, 9 Dec 2016 21:50:55 +0000 (22:50 +0100)]
dma-buf: Final bits of doc polish
- Put all the remaing bits of the old doc into suitable places in the
new sphinx world.
- Also document the poll support, we forgot to do that.
- Delete dma-buf-sharing.txt.
Daniel Vetter [Fri, 9 Dec 2016 18:53:08 +0000 (19:53 +0100)]
dma-buf: Update cpu access documentation
- Again move the information relevant for driver writers next to the
callbacks.
- Put the overview and userspace interface documentation into a DOC:
section within the code.
- Remove the text that mmap needs to be coherent - since the
DMA_BUF_IOCTL_SYNC landed that's no longer the case. But keep the text
that for pte zapping exporters need to adjust the address space.
- Add a FIXME that kmap and the new begin/end stuff used by the SYNC
ioctl don't really mix correctly. That's something I just realized
while doing this doc rework.
- Augment function and structure docs like usual.
Daniel Vetter [Fri, 9 Dec 2016 18:53:07 +0000 (19:53 +0100)]
dma-buf: Reorganize device dma access docs
- Put the initial overview for dma-buf into dma-buf.rst.
- Put all the comments about detailed semantics into the right
kernel-doc comment for functions or ops structure member.
- To allow that detail, switch the reworked kerneldoc to inline style
for dma_buf_ops.
- Tie everything together into a much more streamlined overview
comment, relying on the hyperlinks for all the details.
- Also sprinkle some links into the kerneldoc for dma_buf and
dma_buf_attachment to tie it all together.
Daniel Vetter [Fri, 9 Dec 2016 18:53:06 +0000 (19:53 +0100)]
dma-buf: Update kerneldoc for sync_file_create
This was missed when adding a dma_fence_get call. While at it also
remove the kerneldoc for the static inline helper - no point
documenting internals down to every detail.
Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating sync_file") Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-3-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 13 Dec 2016 09:36:39 +0000 (10:36 +0100)]
Merge tag 'docs-4.10' of git://git.lwn.net/linux into drm-misc-next
Backmerge the docs-next branch from Jon into drm-misc so that we can
apply the dma-buf documentation cleanup patches. Git found a conflict
where there was none because both drm-misc and docs had identical
patches to clean up file rename issues in the rst include directives.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Fri, 9 Dec 2016 14:19:38 +0000 (15:19 +0100)]
drm/hisilicon: Don't set drm_device->platformdev
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus points for implementing abstraction, and then storing the vfunc
in a global variable.
v2: Don't break the build soooo badly :(
Note that the cleanup function is a bit confused: ade_data was never
set as drvdata, and calling drm_crtc_cleanup directly is a bug - this
is called indirectly through drm_mode_config_cleanup, which calls into
crtc->destroy, which already has the call to drm_crtc_cleanup. Which
means we can just nuke it.
Note this is the 2nd attempt after the first one failed and had to be
reverted again in
Revert "drm/hisilicon: Don't set drm_device->platformdev"
Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161209141944.22121-1-daniel.vetter@ffwll.ch
Daniel Vetter [Sat, 10 Dec 2016 21:52:54 +0000 (22:52 +0100)]
drm: Enforce BKL-less ioctls for modern drivers
With the last round of changes all ioctls called by modern drivers now
have their own locking. Everything else is only allowed for legacy
drivers and hence the lack of locking doesn't matter.
One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag.
But that only works its magic on the context and bufs ioctls. And
drm_bufs.c is protected with dev->struct_mutex, and drm_context.c by
the same and dev->ctxlist_mutex. That should be all safe, and we can
finally mandata drm-bkl-less ioctls for everyone!
Daniel Vetter [Sat, 10 Dec 2016 21:52:53 +0000 (22:52 +0100)]
drm: setclientcap doesn't need the drm BKL
It only updates per-file feature flags. And all the ioctl which change
behaviour depending upon these flags (they're all kms features) do
_not_ hold the BKL. Therefor this is pure cargo-cult and can be
removed.
Note that there's a risk that the ioctl will behave inconsistently
when userspace is racing with itself, but that's ok. The only thing
it's not allowed to do is oops the kernel, and from an audit all
places are safe.
v2: Clarify that the inconsistency is only when userspace races
(Chris).
Daniel Vetter [Sat, 10 Dec 2016 21:52:52 +0000 (22:52 +0100)]
drm: Protect master->unique with dev->master_mutex
No one looks at the major/minor versions except the unique/busid
stuff. If we protect that with the master_mutex (since it also affects
the unique of each master, oh well) we can mark these two IOCTL with
DRM_UNLOCKED.
While doing this I realized that the comment for the magic_map is
outdated, I've forgotten to update it in:
Daniel Vetter [Wed, 9 Nov 2016 12:36:36 +0000 (13:36 +0100)]
drm_fourcc: Document linear modifier
Not setting the fb modifiers flag is something different from setting
the fb modifiers to 0 (which means explicitly linear). We kinda failed
to document that properly. Spotted by Kristian.
Dave Airlie [Tue, 13 Dec 2016 04:29:05 +0000 (14:29 +1000)]
Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next
- Regression fix from atomic conversion (rotation on the original G80).
- Concurrency fix when clearing compression tags.
- Fixes DP link training issues on GP102/4/6.
- Fixes backlight handling in the presence of Apple GMUX.
- Improvements to GPU error recovery in a number of scenarios.
- GP106 support.
* 'linux-4.10' of git://github.com/skeggsb/linux:
drm/nouveau/kms/nv50: fix atomic regression on original G80
drm/nouveau/bl: Do not register interface if Apple GMUX detected
drm/nouveau/bl: Assign different names to interfaces
drm/nouveau/bios/dp: fix handling of LevelEntryTableIndex on DP table 4.2
drm/nouveau/ltc: protect clearing of comptags with mutex
drm/nouveau/gr/gf100-: handle GPC/TPC/MPC trap
drm/nouveau/core: recognise GP106 chipset
drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas
drm/nouveau/gr/gf100-: FECS intr handling is not relevant on proprietary ucode
drm/nouveau/gr/gf100-: properly ack all FECS error interrupts
drm/nouveau/fifo/gf100-: recover from host mmu faults
Dave Airlie [Tue, 13 Dec 2016 04:27:41 +0000 (14:27 +1000)]
Merge tag 'drm/tegra/for-4.10-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.10-rc1
This has a couple of fixes for IOMMU support and some fixes for error
handling.
* tag 'drm/tegra/for-4.10-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Set sgt pointer in BO pin
drm/tegra: Support kernel mappings with IOMMU
gpu: host1x: Add locking to syncpt
gpu: host1x: Store device address to all bufs
drm/tegra: gem: Remove some dead code
drm/tegra: sor: No need to free devm_ allocated memory
drm/tegra: Fix error handling
drm/tegra: dpaux: Fix error handling
Dave Airlie [Tue, 13 Dec 2016 04:26:28 +0000 (14:26 +1000)]
Merge tag 'drm/panel/for-4.10-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.10-rc1
This adds support for a couple more panels to the simple-panel driver.
There is also a fix for a long-standing bug, but it's not critical since
no code will currently trigger it.
* tag 'drm/panel/for-4.10-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: simple: Add support for AUO G185HAN01
drm/panel: simple: Add support for AUO G133HAN01
drm/panel: simple: Add more properties to Innolux G121I1-L01
drm/panel: simple: Add bits-per-component for Sharp LQ123P1JX31
drm/panel: simple: Check against num_timings when setting preferred for timing
drm/panel: Add support for Chunghwa CLAA070WP03XG panel
drm/panel: simple: Add NVD9128 as a simple panel
drm/panel: simple: Add support for AUO T215HVN01
drm/panel: simple: Add support for Sharp LQ150X1LG11 panels
dt-bindings: display: Add Sharp LQ150X1LG11 panel binding
Dave Airlie [Tue, 13 Dec 2016 02:05:12 +0000 (12:05 +1000)]
Merge tag 'drm-vc4-next-2016-12-09' of https://github.com/anholt/linux into drm-next
This pull request brings in VEC (TV-out) support for vc4, along with a
pageflipping race fix.
* tag 'drm-vc4-next-2016-12-09' of https://github.com/anholt/linux:
drm/vc4: Don't use drm_put_dev
drm/vc4: Document VEC DT binding
drm/vc4: Add support for the VEC (Video Encoder) IP
drm: Add TV connector states to drm_connector_state
drm: Turn DRM_MODE_SUBCONNECTOR_xx definitions into an enum
drm/vc4: Fix ->clock_select setting for the VEC encoder
drm/vc4: Fix race between page flip completion event and clean-up
Pierre Moreau [Wed, 7 Dec 2016 23:57:08 +0000 (00:57 +0100)]
drm/nouveau/bl: Assign different names to interfaces
Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.
v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.
v3:
* Define a macro for the size of the backlight name, to avoid defining
it multiple times;
* Use snprintf in place of sprintf.
v4:
* Do not create similarly named interfaces when reaching the maximum
amount of unique names, but fail instead, as pointed out by Lukas Wunner
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Mon, 12 Dec 2016 07:52:45 +0000 (17:52 +1000)]
drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas
TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.
That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.
This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org [v4.8+]
projects / karo-tx-linux.git / log