drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more beneficial when the lifetime of the state becomes more
convoluted than being passed to a single worker thread for the commit.
v2: Double check !intel atomic_commit functions for missing gets
v3: Update kerneldocs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161014121833.439-27-chris@chris-wilson.co.uk
Here are some patches for drm-next.
It contains:
- minor fixes for typo and warning.
- sparse and coccicheck warning fixes
- bunch of patches fixing issues found while testing drm/sti with an
atomic version of weston
- the removal of the support of stih415-416 sti platform
* 'sti-drm-next-2016-09-20' of https://github.com/vinceab/linux:
drm/sti: remove stih415-416 platform support
drm/sti: fix compositor debugfs creation
drm/sti: use valid video mode
drm/sti: in crtc_atomic_flush, enable only planes of this crtc
drm/sti: use vtg array instead of vtg_main/aux
drm/sti: use different notifier_block for each pipe
drm/sti: fix atomic_disable check
drm/sti: run gdp init sequence only once
drm/sti: run hqvdp init sequence only once
drm/sti: fix debug logs
drm/sti: dpms function missing for HDMI connector
drm/sti: Fix sparse warnings
drm: sti: fix coccicheck warnings
drm: sti: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
There are many reasons other than ENOMEM that drm_dev_init() can
fail. Return ERR_PTR rather than NULL to be able to distinguish
these in the caller.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20160921145919.13754-2-teg@jklm.no
drm/sti/sti_mixer.c:361:6: warning: symbol 'sti_mixer_set_matrix' was not declared. Should it be static?
drm/sti/sti_gdp.c:476:5: warning: symbol 'sti_gdp_field_cb' was not declared. Should it be static?
drm/sti/sti_gdp.c:885:24: warning: symbol 'sti_gdp_plane_helpers_funcs' was not declared. Should it be static?
drm/sti/sti_cursor.c:348:24: warning: symbol 'sti_cursor_plane_helpers_funcs' was not declared. Should it be static?
drm/sti/sti_compositor.c:28:28: warning: symbol 'stih407_compositor_data' was not declared. Should it be static?
drm/sti/sti_compositor.c:49:28: warning: symbol 'stih416_compositor_data' was not declared. Should it be static?
drm/sti/sti_vtg.c:75:1: warning: symbol 'vtg_lookup' was not declared. Should it be static?
drm/sti/sti_vtg.c:476:24: warning: symbol 'sti_vtg_driver' was not declared. Should it be static?
drm/sti/sti_dvo.c:109:5: warning: symbol 'dvo_awg_generate_code' was not declared. Should it be static?
drm/sti/sti_dvo.c:602:24: warning: symbol 'sti_dvo_driver' was not declared. Should it be static?
drm/sti/sti_vtac.c:209:24: warning: symbol 'sti_vtac_driver' was not declared. Should it be static?
drm/sti/sti_tvout.c:914:24: warning: symbol 'sti_tvout_driver' was not declared. Should it be static?
drm/sti/sti_hqvdp.c:786:5: warning: symbol 'sti_hqvdp_vtg_cb' was not declared. Should it be static?
drm/sti/sti_hqvdp.c:1253:24: warning: symbol 'sti_hqvdp_plane_helpers_funcs' was not declared. Should it be static?
drm/sti/sti_hqvdp.c:1292:5: warning: symbol 'sti_hqvdp_bind' was not declared. Should it be static?
drm/sti/sti_hqvdp.c:1385:24: warning: symbol 'sti_hqvdp_driver' was not declared. Should it be static?
drm/sti/sti_drv.c:143:6: warning: symbol 'sti_drm_dbg_cleanup' was not declared. Should it be static?
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Vincent Abriou <vincent.abriou@st.com>
Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a plane if the CRTC of the old plane state needs a modesetting
operation. Of course, the drivers need to disable the planes in their CRTC
disable callbacks since no one else would do that.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Peter Senna Tschudin <peter.senna@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1472461923-14364-1-git-send-email-gnuiyl@gmail.com
Since commit 4984979b9b ("drm/irq: simplify irq checks in
drm_wait_vblank"), the drm driver feature flag DRIVER_HAVE_IRQ is only
required for drivers that have an IRQ handler managed by the DRM core.
Some drivers, armada, etnaviv, kirin and sti, set this flag without
.irq_handler setup in drm_driver. These drivers manage IRQ handler
by themselves and the flag DRIVER_HAVE_IRQ makes no sense there.
Drop the flag for these drivers to avoid confusion.
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk> (for armada and etnaviv)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1471331168-5601-1-git-send-email-shawnguo@kernel.org
Use drm_dev_alloc() and drm_dev_register() instead of .load()
To simplify init sequence only create fbdev when requested
in output_poll_changed().
version 2:
remove call to drm_connector_unregister_all() and
drm_dev_set_unique()
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466514580-15194-4-git-send-email-benjamin.gaignard@linaro.org
The async name is deprecated and should be changed to nonblocking.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461679905-30177-9-git-send-email-maarten.lankhorst@linux.intel.com
Thanks to "drm: prime: Honour O_RDWR during prime-handle-to-fd"
commit we don't need to hack flags anymore.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Display fps on demand for each used plane:
cat /sys/kernel/debug/dri/0/fps_get
Display fps in live in the console for each used plane:
echo 255 > /sys/kernel/debug/dri/0/fps_show
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
sti now support of atomic modesetting so set the flag to enable it.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
The drm_fbdev_cma_init function always calls the
drm_helper_disable_unused_functions. Since it's part of the usual probe
process, all the drivers using that helper will end up having their encoder
and CRTC disable functions called at probe if their device has not been
reported as enabled.
This could be fixed by reading out from the registers the current state of
the device if it is enabled, but even that will not handle the case where
the device is actually disabled.
Moreover, the drivers using the atomic modesetting expect that their enable
and disable callback to be called when the device is already enabled or
disabled (respectively).
We can however fix this issue by moving the call to
drm_helper_disable_unused_functions out of drm_fbdev_cma_init and make the
drivers needing it (all the drivers calling drm_fbdev_cma_init and not
using the atomic modesetting) explicitly call it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452785109-6172-14-git-send-email-maxime.ripard@free-electrons.com
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation
for the sti kms driver.
Remove this local config option and use the core fb helpers with
drm_kms_helper.fbdev_emulation module option to enable/disable fbdev
at runtime.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
There's no use building the individual drivers as separate modules
because they are all only useful if combined into a single DRM/KMS
device.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
drm_vblank_count() returns the software counter. We should not pretend
it's the hw counter since we use the hw counter to figuere out what the
software counter value should be. So instead provide a new function
drm_vblank_no_hw_counter() for drivers that don't have a real hw
counter. The new function simply returns 0, which is about the only
thing it can do.
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
[danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface
change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.
Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set this to
true.
v2: Check for NULL state->crtc before chasing the pointer. Also check
both old and new crtc if there's a switch. Finally just outright
disallow switching crtcs for a plane if the plane is in active use, on
most hardware that doesn't make sense.
v3: Since commit_planes(active_only = true) is for enabling things
only after all the crtc are on we should only look at the new crtc to
decide whether to call the plane hooks - if the current CRTC isn't on
then skip. If the old crtc (when moving a plane) went down then the
plane should have been disabled as part of the pipe shutdown work
already. For which there's currently no helper really unfortunately.
Also move the check for wether a plane gets a new CRTC assigned while
still in active use out of this patch.
v4: Rebase over exynos changes.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
replace all "sti_drm_" occurences by "sti_"
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Chris Wilson