This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180703160354.59955-3-noralf@tronnes.org
Add a convenience macro for iterating connector->encoder_ids[].
Isolates the users from the implementation details.
Note that we don't seem to pass the file_priv down to drm_encoder_find()
because encoders apparently don't get leased. No idea why
drm_encoder_finc() even takes the file_priv actually.
Also use ARRAY_SIZE() when populating the array to avoid spreading
knowledge about the array size all over.
v2: Hide the drm_encoder_find() in the macro, and
rename the macro appropriately (Daniel)
v3: Fix kernel docs (Daniel)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628131315.14156-4-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of using the .best_encoder() hook to figure out whether a given
connector+crtc combo will work, let's instead do what userspace does and
just iterate over all the encoders for the connector, and then check
each crtc against each encoder's possible_crtcs bitmask.
v2: Avoid oopsing on NULL encoders (Daniel)
s/connector_crtc_ok/connector_has_possible_crtc/
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628131315.14156-2-ville.syrjala@linux.intel.com
Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any refcounts as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-14-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).
Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.
Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Lin, Jia <lin.a.jia@intel.com>
Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2)
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-10-git-send-email-ankit.k.nautiyal@intel.com
Add helper for initializing fbdev deferred I/O.
The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo which lives in Greg's staging tree.
So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
but not that bad either.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-6-noralf@tronnes.org
fb_helper is being dereferenced before it is null checked,
hence there is a potential null pointer dereference.
Fix this by moving the pointer dereference after fb_helper
has been null checked.
This issue was detected with the help of Coccinelle.
Fixes: c777990fb4 ("drm/fb-helper: Handle function NULL argument")
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171205174628.GA31189@embeddedor.com
Apply the "panel orientation" drm connector prop to the primary plane so
that fbcon and fbdev using userspace programs display the right way up.
Changes in v3:
-Use a rotation member in struct drm_fb_helper_crtc and set that from
drm_setup_crtcs instead of looping over all crtc's to find the right one
later
-Since we now no longer look at rotation quirks directly in the fbcon
code, set fb_info.fbcon_rotate_hint when the panel is not mounted upright
and we cannot use hardware rotation
Changes in v4:
-Make drm_fb_helper_init() init drm_fb_helper_crtc.rotation to
DRM_MODE_ROTATE_0 for all crtcs, so that we do not end up setting the
plane_state's rotation to an invalid value for disabled crtcs
(caught by Fi.CI)
Changes in v5:
-Only use hardware (crtc primary plane) rotation for DRM_ROTATE_180,
90 / 270 degree rotation requires special handling which we lack atm
-Add a TODO comment for 90 / 270 degree hardware rotation
-Add some comments to better document the default case when mapping
sw_rotations to fbcon_rotate_hints
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-5-hdegoede@redhat.com
Cross-subsystem Changes:
- device tree doc for the Mitsubishi AA070MC01 and Tianma TM070RVHG71
panels (Lukasz Majewski) and for a 2nd endpoint on stm32 (Philippe Cornu)
Core Changes:
The most important changes are:
- Add drm_driver .last_close and .output_poll_changed helpers to reduce
fbdev emulation footprint in drivers (Noralf)
- Fix plane clipping in core and for vmwgfx (Ville)
Then we have a bunch of of improvement for print and debug such as the
addition of a framebuffer debugfs file. ELD connector, HDMI and
improvements. And a bunch of misc improvements, clean ups and style
changes and doc updates
[airlied: drop eld bits from amdgpu_dm]
Driver Changes:
- sii8620: filter unsupported modes and add DVI mode support (Maciej Purski)
- rockchip: analogix_dp: Remove unnecessary init code (Jeffy Chen)
- virtio, cirrus: add fb create_handle support to enable screenshots(Lepton Wu)
- virtio: replace reference/unreference with get/put (Aastha Gupta)
- vc4, gma500: Convert timers to use timer_setup() (Kees Cook)
- vc4: Reject HDMI modes with too high of clocks (Eric)
- vc4: Add support for more pixel formats (Dave Stevenson)
- stm: dsi: Rename driver name to "stm32-display-dsi" (Philippe Cornu)
- stm: ltdc: add a 2nd endpoint (Philippe Cornu)
- via: use monotonic time for VIA_WAIT_IRQ (Arnd Bergmann)
* tag 'drm-misc-next-2017-11-30' of git://anongit.freedesktop.org/drm/drm-misc: (96 commits)
drm/bridge: tc358767: add copyright lines
MAINTAINERS: change maintainer for Rockchip drm drivers
drm/vblank: Fix vblank timestamp debugs
drm/via: use monotonic time for VIA_WAIT_IRQ
dma-buf: Fix ifnullfree.cocci warnings
drm/printer: Add drm_vprintf()
drm/edid: Allow HDMI infoframe without VIC or S3D
video/hdmi: Allow "empty" HDMI infoframes
dma-buf/fence: Fix lock inversion within dma-fence-array
drm/sti: Handle return value of platform_get_irq_byname
drm/vc4: Add support for NV21 and NV61.
drm/vc4: Use .pixel_order instead of custom .flip_cbcr
drm/vc4: Add support for DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888
drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c
drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state()
drm/vmwgfx: Try to fix plane clipping
drm/vmwgfx: Use drm_plane_helper_check_state()
drm/vmwgfx: Remove bogus crtc coords vs fb size check
gpu: gma500: remove unneeded DRIVER_LICENSE #define
drm: don't link DP aux i2c adapter to the hardware device node
...
Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.
Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: ca91a2758f ("drm/fb-helper: Support deferred setup")
Cc: <stable@vger.kernel.org> # v4.14+
Reported-by: Thomas Voegtle <tv@lio96.de>
Tested-by: Thomas Voegtle <tv@lio96.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarten.lankhorst@linux.intel.com
We don't want fbcon to get used on non-desktop dislays,
don't pass them as enabled connectors to the fb helper setup.
This prevents my HMD from getting disorted fbcon, and from
affecting other displays console.
v2: Change description from non-standard to non-desktop
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
struct drm_device. This makes it possible to add callback helpers for
.last_close and .output_poll_changed further reducing fbdev emulation
footprint in drivers. The pointer is set by drm_fb_helper_init() and
cleared by drm_fb_helper_fini().
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171030153951.56269-3-noralf@tronnes.org
Make functions tolerate that the drm_fb_helper argument is NULL.
This is useful for drivers that continue probing when fbdev emulation
fails and not having to do this check themselves.
Update docs for functions that already handles this.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171030153951.56269-2-noralf@tronnes.org
drm_fb_helper_resume_worker() uses fb_helper->fbdev to call
fb_set_suspend() which dereferences the pointer.
Move sync-canceling of the resume worker in drm_fb_helper_fini() before
setting fb_helper->fbdev to NULL. Move dirty_work as well.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1503940668-25883-2-git-send-email-noralf@tronnes.org
The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.
This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs()
because fb_helper->fbdev may be NULL in drm_setup_crtcs().
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1501863924-7154-1-git-send-email-david@lechnology.com
This adds a new drm_setup_crtcs_fb() function to handle the parts of
drm_setup_crtcs() that touch fb_helper->fb and fb_helper->fbdev. When
drm_setup_crtcs() is called during initialization, these fields are NULL
because they have not been allocated yet.
There is currently a hack at the end of drm_fb_helper_single_fb_probe()
that sets fb_helper->fb, so it is moved to the new drm_setup_crtcs_fb()
function.
This is also done in preparation for addition setup that requires access
to fb_helper->fbdev.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1501777149-8310-2-git-send-email-david@lechnology.com
fb_crtc is used before a null check, so move the use after the null check.
This was just identified by inspection. I haven't actually observed a crash
here, so it is possible that the null check could be unnecessary.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1501696813-8807-1-git-send-email-david@lechnology.com
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fallback is in place because VGA connectors can happen to report an
unknown connection status even when they are in fact connected.
Some drivers have custom solutions in place to defer FB helper setup
until at least one output is connected. But the logic behind these
solutions is always the same and there is nothing driver-specific about
it, so a better alterative is to fix the FB helper core and add support
for all drivers automatically.
This patch adds support for deferred FB helper setup. It checks all the
connectors for their connection status, and if all of them report to be
disconnected marks the FB helper as needing deferred setup. Whet setup
is deferred, the FB helper core will automatically retry setup after a
hotplug event, and it will keep trying until it succeeds.
v2: Rebase onto my entirely reworked fbdev helper locking. One big
difference is that this version again drops&reacquires the fbdev lock
(which is now fb_helper->lock, but before this patch series it was
mode_config->mutex), because register_framebuffer must be able to
recurse back into fbdev helper code for the initial screen setup.
v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
return, I've fumbled that in the deferred setup case (Liviu).
v4: I was blind, redo this all. __drm_fb_helper_initial_config
shouldn't need to reacquire fb_helper->lock, that just confuses
callers. I myself got confused by kernel_fb_helper_lock and somehow
thought it's the same as fb_helper->lock. Tsk.
Also simplify the logic a bit (we don't need two functions to probe
connectors), we can stick much closer to the existing code. And update
some comments I've spotted that are outdated.
v5: Don't pass -EAGAIN to drivers, it's just an internal error code
(Liviu).
v6: Add _and_unlock suffix to clarify locking (Maarten)
Cc: Liviu Dudau <liviu@dudau.co.uk>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Reviewed-by: Liviu Dudau <liviu@dudau.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The legacy path implements setcmap in terms of crtc .gamma_set.
The atomic path implements setcmap by directly updating the crtc gamma_lut
property.
This has a couple of benefits:
- it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
completely obsolete. They are now unused and subject for removal.
- atomic drivers that support clut modes get fbdev support for those from
the drm core. This includes atmel-hlcdc, but perhaps others as well?
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-4-peda@axentia.se
I think the gamma_store can end up invalid on error. But the way I read
it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
this pesky legacy fbdev stuff be any better?
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-3-git-send-email-peda@axentia.se
Like with panning and modesetting, and like with those, stick with
simple drm_modeset_locking_all for the legacy path, and the full
atomic dance for atomic drivers.
This means a bit more boilerplate since setting up the atomic state
machinery is rather verbose, but then this is shared code for 30+
drivers or so, so meh.
After this patch there's only the LUT/cmap path which is still using
drm_modeset_lock_all for an atomic driver. But Peter is already
locking into reworking that, so I'll leave that code as-is for now.
v2: Squash in patches from Maarten to unify all the various atomic
paths into just one atomic update function for fbdev overall. On top
do one s/restore_fbdev_mode/restore_fbdev_mode_atomic/ so that we have
all-atomic callchains after the first check.
Cc: Peter Rosin <peda@axentia.se>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-10-daniel.vetter@ffwll.ch
Those are now all protected using fb_helper->lock.
v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.
v3: I forgot to hold mode_config.mutex while looking at
connector->status and the mode list. Also, we need to patch up the
i915 ->initial_config callback to grab the locks it needs to inspect
the modeset state recovered from the fw.
v4: Don't reorder the probe too much (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705045629.31265-1-daniel.vetter@ffwll.ch
Same game as with the panning function, use drm_modeset_lock_all for
legacy paths, and a proper acquire ctx w/w mutex dance for atomic.
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-8-daniel.vetter@ffwll.ch
For the legacy path we'll keep drm_modeset_lock_all, for the atomic
one we drop the use of the magic implicit context and wire it up
properly.
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-7-daniel.vetter@ffwll.ch
Like with the drm-native vblank wait ioctl we can entirely rely on the
spinlocks in drm_vblank.c, no need at all to take expensive mutexes.
The only reason we had to take mode_config.mutex was to protect the
fbdev helper's data-structures, but that's now done by
fb_helper->lock.
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-6-daniel.vetter@ffwll.ch
That function only needs to take the individual crtc locks, not all
the kms locks. Push down the locking and then minimize it.
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-5-daniel.vetter@ffwll.ch
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
This patch just adds the new lock everywhere we currently grab
mode_config->mutex (explicitly, or through drm_modeset_lock_all).
Follow-up patches will push the kms locking down into only the places
that need it.
v2:
- use lockdep_assert_held
- use drm_fb_helper_for_each_connector where possible
- use the new top-level lock consistently, i.e. in all the places
we're currently acquiring mode_config.mutex.
- small polish to the kerneldoc
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-4-daniel.vetter@ffwll.ch
Move the modeset locking from drivers into FB helpers.
v2: Also handle intel_connector_add_to_fbdev.
v3: Prevent race in intel_dp_mst with ->detect (Maarten)
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-2-daniel.vetter@ffwll.ch
Remove drm_mode_config_fb, I don't see the point of it.
To make it clear that it's ok to use plane->fb directly,
move up drm_drv_uses_atomic_modeset so the code is skipped for atomic
drivers that require plane_state->fb.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170703115106.18783-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI
as a convenience.
Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
through the atomic API, but realizing that userspace is likely to take
shortcuts and assume that the enum values are what is sent over the
wire.
As a result these defines are provided purely as a convenience to
userspace applications.
Changes since v3:
- Switched away from past tense in comments
- Add define name change to previously mis-spelled DRM_REFLECT_X comment
- Improved the comment for the DRM_MODE_REFLECT_<axis> comment
Changes since v2:
- Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_
- Fix compilation errors
- Changed comment formatting
- Deduplicated comment lines
- Clarified DRM_MODE_PROP_REFLECT_ comment
Changes since v1:
- Moved defines from drm.h to drm_mode.h
- Changed define prefix from DRM_ to DRM_MODE_PROP_
- Updated uses of the defines to the new prefix
- Removed include from drm_rect.c
- Stopped using the BIT() macro
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com
While examining output from trial builds with -Wformat-security enabled,
many strings were found that should be defined as "const", or as a char
array instead of char pointer. This makes some static analysis easier,
by producing fewer false positives.
As these are all trivial changes, it seemed best to put them all in a
single patch rather than chopping them up per maintainer.
Link: http://lkml.kernel.org/r/20170405214711.GA5711@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Jes Sorensen <jes@trained-monkey.org> [runner.c]
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: Antonio Quartulli <a@unstable.cc>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Kejian Yan <yankejian@huawei.com>
Cc: Daode Huang <huangdaode@hisilicon.com>
Cc: Qianqian Xie <xieqianqian@huawei.com>
Cc: Philippe Reynes <tremyfr@gmail.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Christian Gromm <christian.gromm@microchip.com>
Cc: Andrey Shvetsov <andrey.shvetsov@k2l.de>
Cc: Jason Litzinger <jlitzingerdev@gmail.com>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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
Atomic helpers really want this instead of the hacked-up legacy
backoff trick, which unfortunately prevents drivers from using their
own private drm_modeset_locks.
Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which
don't yet use the new atomic color mgmt/gamma table stuff. Would be
nice if they could switch over and just hook up
drm_atomic_helper_legacy_gamma_set() instead.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-13-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
Add a couple of temporary variables and use shorter names for existing
variables in drm_fb_helper_add_one_connector() for better readability.
Tested-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-4-thierry.reding@gmail.com
An unlocked version of the drm_fb_helper_add_one_connector() function
will be added in a subsequent patch. Reshuffle the code separately to
make the diff more readable later on.
Tested-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-3-thierry.reding@gmail.com
Fix up a couple of checkpatch warnings, such as whitespace or coding
style issues.
Tested-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-2-thierry.reding@gmail.com
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJY2C9qAAoJEHm+PkMAQRiGaBQIAIGzdlZ6ImiP6zoukrRv7qUr
44ITm0lsBiL85QGedhQQL+Y9UqwUmlqgFqnH0Gr8YHNbLJWXzdjGbl5aVo4KjASq
104NLUDXtPww/xZdH4wJMzhuwucYwZOUyDOjOr0ak3cGxOE2xjNjHMZXxWUf20GO
EpRr6WhV1DUAvAdjdNa9KlcOjMluNpMLLyL1CFLjrkkArrWAyqOURKHAb6ZLghfv
iZV1qJTVPyYGpnlI3kuEgu2GuDjxqpoNLSr3wHyEHm/pBPEl7MX6zPbzcegBV8TY
cRRlXo4notdsuknmSNcj0hHuTQvw1kl7BhieLKVsnCyCIM6jjX4TSQZFutmbzwM=
=5iRl
-----END PGP SIGNATURE-----
Backmerge tag 'v4.11-rc4' into drm-next
Linux 4.11-rc4
The i915 GVT team need the rc4 code to base some more code on.
Otherwise this can also prevent modesets e.g. for switching VTs, when
multiple monitors with different native resolutions are connected.
The depths must match though, so keep the != test for that.
Also update the DRM_DEBUG output to be slightly more accurate, this
doesn't only affect requests from userspace.
Bugzilla: https://bugs.freedesktop.org/99841
Fixes: 865afb1194 ("drm/fb-helper: reject any changes to the fbdev")
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170323085326.20185-1-michel@daenzer.net
Noralf Trønnes