| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.
v2:
Change return type to bool (Ville)
Move the function drm_atomic.h (Daniel)
Fixed comment marker for documentation
Suggested-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Ben Skeggs <[email protected]>
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
[danvet: Move back to drmP.h because include hell.]
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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)
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This function is now completely unused, zap it.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481204729-9058-6-git-send-email-maarten.lankhorst@linux.intel.com
|
|
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.
Signed-off-by: Maarten Lankhorst <[email protected]>
[danvet: Completely new commit message.]
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481204729-9058-5-git-send-email-maarten.lankhorst@linux.intel.com
|
|
Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
crtc_state after commit. Move it to atomic_state->crtcs.
Also stop re-using new_crtc_state->enable, we can now simply set a
bitmask with crtc_crtc_mask.
Changes since v1:
- Keep last_vblank_count in __drm_crtc_state.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Atomic drivers may set properties like rotation on the same fb, which
may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver
decide when prepare_fb and cleanup_fb are noops.
This is a revert of:
commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
Author: Keith Packard <[email protected]>
Date: Sat Jun 4 01:16:22 2016 -0700
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.
Signed-off-by: Maarten Lankhorst <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/20161217010442.GA140619@beast
|
|
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.
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/20161217010402.GA140546@beast
|
|
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.
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/20161217010011.GA140300@beast
|
|
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.
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/20161217005929.GA140260@beast
|
|
Signed-off-by: Peter Meerwald-Stadler <[email protected]>
Cc: Xinliang Liu <[email protected]>
Cc: Xinwei Kong <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Peter Meerwald-Stadler <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- 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.
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Reviewed-by: Chris Wilson <[email protected]>
Cc: Chris Wilson <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Reported-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Reviewed-by: Harry Wentland <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
v3: Bail out after iter_put (Harry).
Cc: Harry Wentland <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Cc: Dave Airlie <[email protected]>
Cc: Chris Wilson <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Reviewed-by: Sean Paul <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The list walk will shortcircuit anyway.
Cc: Alex Deucher <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This is not driver interface stuff.
Fixes: 6559c901cb48 ("drm/atomic: add debugfs file to dump out atomic state")
Cc: Rob Clark <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Instead of detaching only the bridge directly connected to the encoder,
detach all bridges in the chain.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-6-git-send-email-laurent.pinchart+renesas@ideasonboard.com
|
|
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.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-5-git-send-email-laurent.pinchart+renesas@ideasonboard.com
|
|
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 <[email protected]>
Acked-by: Stefan Agner <[email protected]> # For DCU
Acked-by: Boris Brezillon <[email protected]> # For atmel-hlcdc
Acked-by: Vincent Abriou <[email protected]> # For STI
Acked-by: Maxime Ripard <[email protected]> # For sun4i
Acked-by: Xinliang Liu <[email protected]> # For hisilicon
Acked-by: Jyri Sarha <[email protected]> # For tilcdc
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com
|
|
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.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com
|
|
<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.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]> # For vmwgfx
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com
|
|
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.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Mark up the pointers as constant through the API where appropriate.
Signed-off-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
for walking the list of nodes safe against removal.
Note from Joonas:
"Most of the diff is about __drm_mm_nodes(mm), which could be split into
own patch and keep the R-b's."
But I don't feel like insisting on the resend.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
[danvet: Add note.]
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On most platforms, there exists this ifdef:
#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
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.
[1] http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2167.pdf
Signed-off-by: Jason A. Donenfeld <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
drm_modeset_helper.c:74: warning: No description found for parameter 'dev'
Cc: Laurent Pinchart <[email protected]>
Cc: Alex Deucher <[email protected]>
Fixes: a3f913ca9892 ("drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
different from commit.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1481812185-19098-2-git-send-email-maarten.lankhorst@linux.intel.com
|
|
drm_event_reserve_init_locked() is the correct function to call when
already holding the dev->event_lock lock.
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Fixes: ca984a998ad3 ("drm/fb_cma_helper: Replace drm_format_info() with fb->format")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
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.
Cc: Laurent Pinchart <[email protected]>
Suggested-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
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.
@@
struct drm_framebuffer *a;
struct drm_framebuffer *b;
@@
(
- a->format->format != b->format->format
+ a->format != b->format
|
- a->format->format == b->format->format
+ a->format == b->format
)
@@
struct drm_plane_state *a;
struct drm_plane_state *b;
@@
(
- a->fb->format->format != b->fb->format->format
+ a->fb->format != b->fb->format
|
- a->fb->format->format == b->fb->format->format
+ a->fb->format == b->fb->format
)
@@
struct drm_crtc *crtc;
struct drm_framebuffer *x;
@@
(
- crtc->primary->fb->format->format != x->format->format
+ crtc->primary->fb->format != x->format
|
- x->format->format != crtc->primary->fb->format->format
+ x->format != crtc->primary->fb->format
)
@@
struct drm_mode_set *set;
@@
- set->fb->format->format != set->crtc->primary->fb->format->format
+ set->fb->format != set->crtc->primary->fb->format
Cc: Laurent Pinchart <[email protected]>
Suggested-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
Replace uses of fb->pixel_format with fb->format->format.
Less duplicated information is a good thing.
Note that coccinelle failed to eliminate the
"/* fourcc format */" comment from drm_framebuffer.h, so I had
to do that part manually.
@@
struct drm_framebuffer *FB;
expression E;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
i9xx_get_initial_plane_config(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
ironlake_get_initial_plane_config(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
skylake_get_initial_plane_config(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- a->pixel_format
+ a->format->format
|
- b.pixel_format
+ b.format->format
)
@@
struct drm_plane_state *a;
struct drm_plane_state b;
@@
(
- a->fb->pixel_format
+ a->fb->format->format
|
- b.fb->pixel_format
+ b.fb->format->format
)
@@
struct drm_crtc *CRTC;
@@
(
- CRTC->primary->fb->pixel_format
+ CRTC->primary->fb->format->format
|
- CRTC->primary->state->fb->pixel_format
+ CRTC->primary->state->fb->format->format
)
@@
struct drm_mode_set *set;
@@
(
- set->fb->pixel_format
+ set->fb->format->format
|
- set->crtc->primary->fb->pixel_format
+ set->crtc->primary->fb->format->format
)
@@
@@
struct drm_framebuffer {
...
- uint32_t pixel_format;
...
};
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
Cc: Laurent Pinchart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Alex Deucher <[email protected]> (v1)
Reviewed-by: Laurent Pinchart <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
@@
struct drm_framebuffer *FB;
expression E;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
i9xx_get_initial_plane_config(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
ironlake_get_initial_plane_config(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
skylake_get_initial_plane_config(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer FB;
expression E;
@@
(
- E * FB.bits_per_pixel / 8
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel / 8
+ FB.format->cpp[0]
|
- E * FB.bits_per_pixel >> 3
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel >> 3
+ FB.format->cpp[0]
|
- (FB.bits_per_pixel + 7) / 8
+ FB.format->cpp[0]
|
- FB.bits_per_pixel
+ FB.format->cpp[0] * 8
|
- FB.format->cpp[0] * 8 != 8
+ FB.format->cpp[0] != 1
)
@@
struct drm_framebuffer *FB;
expression E;
@@
(
- E * FB->bits_per_pixel / 8
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel / 8
+ FB->format->cpp[0]
|
- E * FB->bits_per_pixel >> 3
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel >> 3
+ FB->format->cpp[0]
|
- (FB->bits_per_pixel + 7) / 8
+ FB->format->cpp[0]
|
- FB->bits_per_pixel
+ FB->format->cpp[0] * 8
|
- FB->format->cpp[0] * 8 != 8
+ FB->format->cpp[0] != 1
)
@@
struct drm_plane_state *state;
expression E;
@@
(
- E * state->fb->bits_per_pixel / 8
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel / 8
+ state->fb->format->cpp[0]
|
- E * state->fb->bits_per_pixel >> 3
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel >> 3
+ state->fb->format->cpp[0]
|
- (state->fb->bits_per_pixel + 7) / 8
+ state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel
+ state->fb->format->cpp[0] * 8
|
- state->fb->format->cpp[0] * 8 != 8
+ state->fb->format->cpp[0] != 1
)
@@
@@
- (8 * 8)
+ 8 * 8
@@
struct drm_framebuffer FB;
@@
- (FB.format->cpp[0])
+ FB.format->cpp[0]
@@
struct drm_framebuffer *FB;
@@
- (FB->format->cpp[0])
+ FB->format->cpp[0]
@@
@@
struct drm_framebuffer {
...
- int bits_per_pixel;
...
};
v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent)
v3: Adjusted the semantic patch a bit and regenerated due to code
changes
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Alex Deucher <[email protected]> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace uses of fb->depth with fb->format->depth. Less duplicate
information is a good thing.
@@
struct drm_framebuffer *fb;
expression E;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- fb->depth = E;
...
}
@@
struct nouveau_framebuffer *fb;
@@
- fb->base.depth
+ fb->base.format->depth
@@
struct drm_framebuffer fb;
@@
- fb.depth
+ fb.format->depth
@@
struct drm_framebuffer *fb;
@@
- fb->depth
+ fb->format->depth
@@
struct drm_framebuffer fb;
@@
- (fb.format->depth)
+ fb.format->depth
@@
struct drm_framebuffer *fb;
@@
- (fb->format->depth)
+ fb->format->depth
@@
@@
struct drm_framebuffer {
...
- unsigned int depth;
...
};
v2: Drop the vmw stuff (Daniel)
Rerun spatch due to code changes
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace drm_format_plane_{width,height}() usage with
drm_framebuffer_plane_{width,height}() to avoid the lookup of the format
info.
Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
|
|
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).
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Cc: Paulo Zanoni <[email protected]>
Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
|
|
Let's use the pointer to the format information cached under
drm_framebuffer rather than look it up manually.
Cc: Ben Skeggs <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
|
|
Get the format information via the neat fb->format pointer rather than
doing a linear search over all the format info structures.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace drm_format_plane_cpp(fb->pixel_format) with just
fb->format->cpp[]. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
expression E;
@@
(
- drm_format_plane_cpp(a->pixel_format, E)
+ a->format->cpp[E]
|
- drm_format_plane_cpp(b.pixel_format, E)
+ b.format->cpp[E]
)
@@
struct drm_plane_state *a;
struct drm_plane_state b;
expression E;
@@
(
- drm_format_plane_cpp(a->fb->pixel_format, E)
+ a->fb->format->cpp[E]
|
- drm_format_plane_cpp(b.fb->pixel_format, E)
+ b.fb->format->cpp[E]
)
@@
struct drm_framebuffer *a;
identifier T;
expression E;
@@
T = a->pixel_format
<+...
- drm_format_plane_cpp(T, E)
+ a->format->cpp[E]
...+>
@@
struct drm_framebuffer b;
identifier T;
expression E;
@@
T = b.pixel_format
<+...
- drm_format_plane_cpp(T, E)
+ b.format->cpp[E]
...+>
v2: Rerun spatch due to code changes
Cc: Laurent Pinchart <[email protected]>
Suggested-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
|
|
Replace drm_format_num_planes(fb->pixel_format) with just
fb->format->num_planes. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- drm_format_num_planes(a->pixel_format)
+ a->format->num_planes
|
- drm_format_num_planes(b.pixel_format)
+ b.format->num_planes
)
@@
struct drm_plane_state *a;
struct drm_plane_state b;
@@
(
- drm_format_num_planes(a->fb->pixel_format)
+ a->fb->format->num_planes
|
- drm_format_num_planes(b.fb->pixel_format)
+ b.fb->format->num_planes
)
@@
struct drm_framebuffer *a;
identifier T;
@@
T = a->pixel_format
<+...
- drm_format_num_planes(T)
+ a->format->num_planes
...+>
@@
struct drm_framebuffer b;
identifier T;
@@
T = b.pixel_format
<+...
- drm_format_num_planes(T)
+ b.format->num_planes
...+>
v2: Rerun spatch due to code changes
Cc: Laurent Pinchart <[email protected]>
Suggested-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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.
Cc: Laurent Pinchart <[email protected]>
Suggested-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
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.
Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
|
|
To avoid having to look up the format information struct every time,
let's just store a pointer to it under drm_framebuffer.
v2: Don't populate the fb->format pointer in drm_framebuffer_init().
instead we'll treat a NULL format as an error later
Cc: Laurent Pinchart <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Alex Deucher <[email protected]> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Laurent Pinchart <[email protected]>
|