So my original plan was that the drm core refcounts framebuffers like
with the legacy ioctls. But that doesn't work for a bunch of reasons:
- State objects might live longer than until the next fb change
happens for a plane. For example delayed cleanup work only happens
_after_ the pageflip ioctl has completed. So this definitely doesn't
work without the plane state holding its own references.
- The other issue is transition from legacy to atomic implementations,
where the driver works under a mix of both worlds. Which means
legacy paths might not properly update the ->fb pointer under
plane->state->fb. Which is a bit a problem when then someone comes
around and _does_ try to clean it up when it's long gone.
The second issue is just a bit a transition bug, since drivers should
update plane->state->fb in all the paths that aren't converted yet.
But a bit more robustness for the transition can't hurt - we pull
similar tricks with cleaning up the old fb in the transitional helpers
already.
The pattern for drivers that transition is
if (plane->state)
drm_atomic_set_fb_for_plane(plane->state, plane->fb);
inserted after the fb update has logically completed at the end of
->set_config (or ->set_base/mode_set if using the crtc helpers),
->page_flip, ->update_plane or any other entry point which updates
plane->fb.
v2: Update kerneldoc - copypasta fail.
v3: Fix spelling in the commit message (Sean).
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In all cases the text requires that new drivers are converted to the
atomic interfaces.
v2: Add overview for state handling.
v3: Review from Sean: Some spelling fixes and drop the misguided
hunk to remove rgba8888 from the plane helpers compat list.
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So this is finally the integration of the crtc and plane helper
interfaces into the atomic helper functions.
In the check function we now have a few steps:
- First we update the output routing and figure out which crtcs need a
full mode set. Suitable encoders are selected using ->best_encoder,
with the same semantics as the crtc helpers of implicitly disabling
all connectors currently using the encoder.
- Then we pull all other connectors into the state update which feed
from a crtc which changes. This must be done do catch mode changes
and similar updates - atomic updates are differences on top of the
current state.
- Then we call all the various ->mode_fixup to compute the adjusted
mode. Note that here we have a slight semantic difference compared
to the crtc helpers: We have not yet updated the encoder->crtc link
when calling the encoder's ->mode_fixup function. But that's a
requirement when converting to atomic since we want to prepare the
entire state completely contained with the over drm_atomic_state
structure. So this must be carefully checked when converting drivers
over to atomic helpers.
- Finally we do call the atomic_check functions on planes and crtcs.
The commit function is also quite a beast:
- The only step that can fail is done first, namely pinning the
framebuffers. After that we cross the point of no return, an async
commit would push all that into the worker thread.
- The disabling of encoders and connectors is a bit tricky, since
depending upon the final state we need to select different crtc
helper functions.
- Software tracking is a bit clarified compared to the crtc helpers:
We commit the software state before starting to touch the hardware,
like crtc helpers. But since we just swap them we still have the old
state (i.e. the current hw state) around, which is really handy to
write simple disable functions. So no more
drm_crtc_helper_disable_all_unused_functions kind of fun because
we're leaving unused crtcs/encoders behind. Everything gets shut
down in-order now, which is one of the key differences of the i915
helpers compared to crtc helpers and a really nice additional
guarantee.
- Like with the plane helpers the atomic commit function waits for one
vblank to pass before calling the framebuffer cleanup function.
Compared to Rob's helper approach there's a bunch of upsides:
- All the interfaces which can fail are called in the ->check hook
(i.e. ->best_match and the various ->mode_fixup hooks). This means
that drivers can just reuse those functions and don't need to move
everything into ->atomic_check callbacks. If drivers have no need
for additional constraint checking beyong their existing crtc
helper callbacks they don't need to do anything.
- The actual commit operation is properly stage: First we prepare
framebuffers, which can potentially still fail (due to memory
exhausting). This is important for the async case, where this must
be done synchronously to correctly return errors.
- The output configuration changes (done with crtc helper functions)
and the plane update (using atomic plane helpers) are correctly
interleaved: First we shut down any crtcs that need changing, then
we update planes and finally we enable everything again. Hardware
without GO bits must be more careful with ordering, which this
sequence enables.
- Also for hardware with shared output resources (like display PLLs)
we first must shut down the old configuration before we can enable
the new one. Otherwise we can hit an impossible intermediate state
where there's not enough PLLs (which is the point behind atomic
updates).
v2:
- Ensure that users of ->check update crtc_state->enable correctly.
- Update the legacy state in crtc/plane structures. Eventually we want
to remove that, but for now the drm core still expects this (especially
the plane->fb pointer).
v3: A few changes for better async handling:
- Reorder the software side state commit so that it happens all before
we touch the hardware. This way async support becomes very easy
since we can punt all the actual hw touching to a worker thread. And
as long as we synchronize with that thread (flushing or cancelling,
depending upon what the driver can handle) before we commit the next
software state there's no need for any locking in the worker thread
at all. Which greatly simplifies things.
And as long as we synchronize with all relevant threads we can have
a lot of them (e.g. per-crtc for per-crtc updates) running in
parallel.
- Expose pre/post plane commit steps separately. We need to expose the
actual hw commit step anyway for drivers to be able to implement
asynchronous commit workers. But if we expose pre/post and plane
commit steps individually we allow drivers to selectively use atomic
helpers.
- I've forgotten to call encoder/bridge ->mode_set functions, fix
this.
v4: Add debug output and fix a mixup between current and new state
that resulted in crtcs not getting updated correctly. And in an
Oops ...
v5:
- Be kind to driver writers in the vblank wait functions.. if thing
aren't working yet, and vblank irq will never come, then let's not
block forever.. especially under console-lock.
- Correctly clear connector_state->best_encoder when disabling.
Spotted while trying to understand a report from Rob Clark.
- Only steal encoder if it actually changed, otherwise hilarity ensues
if we steal from the current connector and so set the ->crtc pointer
unexpectedly to NULL. Reported by Rob Clark.
- Bail out in disable_outputs if an output currently doesn't have a
best_encoder - this means it's already disabled.
v6: Fixupe kerneldoc as reported by Paulo. And also fix up kerneldoc
in drm_crtc.h.
v7: Take ownership of the atomic state and clean it up with
drm_atomic_state_free().
v8 Various improvements all over:
- Polish code comments and kerneldoc.
- Improve debug output to make sure all failure cases are logged.
- Treat enabled crtc with no connectors as invalid input from userspace.
- Don't ignore the return value from mode_fixup().
v9:
- Improve debug output for crtc_state->mode_changed.
v10:
- Fixup the vblank waiting code to properly balance the vblank_get/put
calls.
- Better comments when checking/computing crtc->mode_changed
v11: Fixup the encoder stealing logic: We can't look at encoder->crtc
since that's not in the atomic state structures and might be updated
asynchronously in and async commit. Instead we need to inspect all the
connector states and check whether the encoder is currently in used
and if so, on which crtc.
v12: Review from Sean:
- A few spelling fixes.
- Flatten control flow indent by converting if blocks to early
continue/return in 2 places.
- Capture connectors_for_crtc return value in int num_connectors
instead of bool has_connectors and do an explicit int->bool
conversion with !!. I think the helper is more useful for drivers if
it returns the number of connectors (e.g. to detect cloning
configurations), so decided to keep that return value.
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These two functions allow drivers to reuse their atomic plane helpers
functions for the primary plane to implement the interfaces required
by the crtc helpers for the legacy ->set_config callback.
This is purely transitional and won't be used once the driver is fully
converted. But it allows partial conversions to the atomic plane
helpers which are functional.
v2:
- Use ->atomic_duplicate_state if available.
- Don't forget to run crtc_funcs->atomic_check.
v3: Shift source coordinates correctly for 16.16 fixed point.
v4: Don't forget to call ->atomic_destroy_state if available.
v5: Fixup kerneldoc.
v6: Reuse the plane_commit function from the transitional plane
helpers to avoid too much duplication.
v7:
- Remove some stale comment.
- Correctly handle the lack of plane->state object, necessary for
transitional use.
v8: Fixup an embarrassing h/vdisplay mixup.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The "flags" parameter of the DRM_IOCTL_MODE_ADDFB2 ioctl must be
propagated and used by the driver.
The only possible value of flags is DRM_MODE_FB_INTERLACED.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Benjamin GAIGNARD <benjamin.gaignard@st.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge drm-fixes into drm-next.
Both i915 and radeon need this done for later patches.
Conflicts:
drivers/gpu/drm/drm_crtc_helper.c
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem_execbuffer.c
drivers/gpu/drm/i915/i915_gem_gtt.c
For atomic, it will be quite necessary to not need to care so much
about locking order. And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.
Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
and drm_modeset_acquire_ctx to track acquired locks.
Atomic will use this to keep track of which locks have been acquired
in a transaction.
v1: original
v2: remove a few things not needed until atomic, for now
v3: update for v3 of connection_mutex patch..
v4: squash in docbook
v5: doc tweaks/fixes
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
modeset-relevant connector state (e.g. properties which control the
panel fitter).
The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.
Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.
The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.
For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.
Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.
I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
sprinkle mode_config.connection_mutex over this file a bit, but
since it already lacks mode_config.mutex this patch wont make the
situation any worse. This is material for a follow-up patch.
- omap has a omap_framebuffer_flush function which walks the
connector->encoder->crtc links and is called from many contexts.
Some look like they don't acquire mode_config.mutex, so this is
already racy. Again fixing this is material for a separate patch.
- The radeon hot_plug function to retrain DP links looks at
connector->dpms. Currently this happens without any locking, so is
already racy. I think radeon_hotplug_work_func should gain
mutex_lock/unlock calls for the mode_config.connection_mutex.
- Same applies to i915's intel_dp_hot_plug. But again, this is already
racy.
- i915 load_detect code needs to acquire this lock. Which means the
w/w dance due to Rob's work will be nicely contained to _just_ this
function.
I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.
v1: original (only compile tested)
v2: missing mutex_init(), etc (from Rob Clark)
v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Skip locking checks in drm_helper_*_in_use() if they are called in panicking
path. See similar code in drm_warn_on_modeset_not_all_locked().
After panic information has been output, these WARN_ONs go off outputing a lot
of lines and scrolling the panic information out of the screen. Here is a
partial call trace showing how execution reaches them:
? drm_helper_crtc_in_use()
? __drm_helper_disable_unused_functions()
? several *_set_config functions
? drm_fb_helper_restore_fbdev_mode()
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The function can never fail, and always returns 0, so it may just as
well not return anything.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've forgotten to clean this all up correctly in
commit e3d6ddb35f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Apr 1 22:15:00 2014 +0200
drm/crtc-helper: don't disable disconnected outputs
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.
The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.
It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Here's the latest iteration of the universal planes work, which I believe is
finally ready for merging. Aside from the minor driver patches to use the
new drm_for_each_legacy_plane() macro for plane loops, these should all have
an r-b from Rob Clark now.
Actual userspace-visibility is currently hidden behind a
drm.universal_planes module parameter so that we can do some experimental
testing of this before flipping it on universally.
* 'primary-plane' of git://people.freedesktop.org/~robclark/linux:
drm/doc: Update plane documentation and add plane helper library
drm: Allow userspace to ask for universal plane list (v2)
drm: Remove unused drm_crtc->fb
drm: Replace crtc fb with primary plane fb (v3)
drm/msm: Switch to universal plane API's
drm: Add drm_crtc_init_with_planes() (v2)
drm: Add plane type property (v2)
drm: Add drm_universal_plane_init()
drm: Add primary plane helpers (v3)
drm: Make drm_crtc_check_viewport non-static
drm/shmobile: Restrict plane loops to only operate on legacy planes
drm/i915: Restrict plane loops to only operate on overlay planes (v2)
drm/exynos: Restrict plane loops to only operate on overlay planes (v2)
drm: Add support for multiple plane types (v2)
This is the equivalent change in the crtc helpers as done to the i915
modeset infrastructure in
commit b0a2658acb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Dec 18 09:37:54 2012 +0100
drm/i915: don't disable disconnected outputs
This was originally introduced to make encoder sharing on radone
easier for userspace, but:
- It is policy and as such belongs into userspace. E.g. personally I'm
fairly annoyed that a flaky cable results in permanent changes of
the desktop layout, so I'll kick out DEs which do this. Worse if the
kernel also tries to be clever.
- It's inconsistent: We only kill disconnected outputs on setCrtc
(which userspace might also call when just changing the
framebuffer), but not when e.g. we receive a hpd event or in the
output poll worker.
- It's unexpected behaviour for the userspace driver, at least in the
intel ddx we've had tons of bugs where the driver fell over and
killed the X session becuase pageflips/vblanks suddenly stopped
working. We've had to fix this by wrapping every single setCrtc int
a big "recover kms state from the kernel again" operation.
- It's suprising for the kernel, too: It took a few mails between Rob,
Matt and me for them to notice that little dragon wreaking havoc
with the universal plane framebuffer refcounting.
- Userspace can cope with it and e.g. Gnome already kills disconnected
outputs and reconfigures the desktop automatically. And since there
have been no regression reports for the i915 change from over 1 year
ago I think all other DEs are also ready.
Note that the lines removed in this patch go back to
commit a3a0544b2c
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Aug 31 15:16:30 2009 +1000
drm/kms: add explicit encoder disable function and detach harder.
Unfortunately the patch itself doesn't explain a hole lot about why it
was added ...
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was introduced in
commit 25f397a429
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 19 18:57:11 2013 +0200
drm/crtc-helper: explicit DPMS on after modeset
but due to a bit of rebase fail on my side the patch actually merged
put one hunk on the wrong side of a break statement. Fix this up.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC. Replace all references to the CRTC fb with the
primary plane's fb.
This patch was generated by the Coccinelle semantic patching tool using
the following rules:
@@ struct drm_crtc C; @@
- (C).fb
+ C.primary->fb
@@ struct drm_crtc *C; @@
- (C)->fb
+ C->primary->fb
v3: Generate patch via coccinelle. Actual removal of crtc->fb has been
moved to a subsequent patch.
v2: Fixup several lingering crtc->fb instances that were missed in the
first patch iteration. [Rob Clark]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Since Daniel documented things with a sledge hammer, we got lots of
nice backtraces in suspend/resume operations, I've check the callers
of this and they all seems safe to me,
This fixes one set of warns I reported.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have two calling contexts for thise function:
- In the crtc helper code itself as part of the ->set_config
implementation. In this calling context all modeset locks are
already held, as they should.
- In drivers not implementing fastboot before the fbdev/fbcon setup
and initialization. This has been added for all drivers in
commit 76a39dbfb2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jan 20 23:12:54 2013 +0100
drm/fb-helper: don't disable everything in initial_config
In this calling context we do not hold any modeset locks since the
immediately following call to initialize the fbev emulation grabs
all these locks themselves.
- There are two exceptions to the above rule: shmob doesn't have fbdev
emulation support. I've manually checked the callchain up to the
driver load function and no kms locks are held.
The right fix therefore is to split this helper into an internal and
external version and add the required locking to the function exported
to drivers.
This remedies locking inconsistencies exposed by me adding locking
WARNs as part of the recent kerneldoc abi polishing done in
commit 62ff94a549
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
and
commit 6395138505
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jan 23 15:14:15 2014 +0100
drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
v2: It helps when I actually git add the entire thing.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Most of this is newly added kerneldoc for the hotplug and output
polling code. But I've also thrown in a bit lesser polish, most of it
is tuning down the shouting RETURN: headers.
Overview documentation for the output probing and mode setting support
code will be added in later patches.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No driver cares, and it should generally work. Add a big comment
when drivers can't use this for recompense.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- It yells.
- WARNing about incorrect locking is harder to ignore, so better
than kerneldoc.
- Since those have been written per-crtc locks were added ...
So remove them and replace them by appropriate WARNs.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rightfully no driver ever checked this - it can't fail.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Totally unused and actually redundant with maxX for display mode
validation. The fb helper otoh needs to check pitch limits,
but that is delegated into drivers instead.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Stumbled over while reviewing all occurences in the DRM doc talking
about suspend/resume.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fix spelling typo in Documentation/DocBook.
It is because .html and .xml files are generated by make htmldocs,
I have to fix a typo within the source files.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJS4TK6AAoJEN0jrNd/PrOhwXoP/i09xa9CKOnpy8Ewdmgi5gBt
vnjzqjwmHzZRpNeWw2xvcqzv5kKgXkpPdMhNUjErlJTUC1S6uCf/Uj+ExppYYysW
7uxNjPQQc6jgX+0342MabKITeZyTk9iEWPqTDtHDP5O2vXi4XSaQTMm9HpWGe1qZ
1CTb0yJc1epXGJPutlqhJSZgKwzrs6Pm2Q/nsTdxpGPAoTQj9J0NebDaZwJmmFGi
qNyfI4DVBp1sj8AgtUkQQn9x5oLDpdvHKLPHsAWgHnNTKqRxY8C0EL+S2TYGa812
sx8jvZgjvBoPuwaOr4hcOx91OFdfOoKVap9D/corU+UjstF9lTd+PvAHzZMO5qte
yQhWmYFn1gGr/I9b9K/mAB98s83W7lMmSs/7HtiawvLtogZ/t8xvSp94R7X8SGd1
wYcw3NqzgDxrcpJjDOsLIw1Pa4PxXoChtV0SfiaEoVlGn5WSONS/8cKeNwbO6e9D
gKkd/zvCMsYqHt7p8zDizcQKi4W+8zYiZySOfLohZzhf0qaoQnnD5yirfiIpljqA
Ql40F4XP3OF3CliikcSwFhvrTUCLb08Ol0MV6FX1H1iMae0dgiFqtz7AihFTbKHZ
PQeskMgEemxhIqKEsH0JcpV3+YxLRlWy/3I+OO7QczsL0xKD30FQ9Xhsu9EFx8gu
jXVvMDldeefaVBuTdqCb
=NfNj
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.14-rc1 (update)
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
* tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Obtain head number from DT
drm/panel: update EDID BLOB in panel_simple_get_modes()
gpu: host1x: Remove unnecessary include
drm/tegra: Use proper data type
drm/tegra: Clarify how panel modes override others
drm/tegra: Fix possible CRTC mask for RGB outputs
drm/i915: Use drm_encoder_crtc_ok()
drm: Move drm_encoder_crtc_ok() to core
drm: provide a helper for the encoder possible_crtcs mask
drm/tegra: Don't check resource with devm_ioremap_resource()
drm/panel: Add support for Chunghwa CLAA101WA01A panel
drm/panel: Add support for Samsung LTN101NT05 panel
We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Using the new drm_crtc_mask() function, drm_encoder_crtc_ok() can now be
written in a significantly shorter way, so it can be moved to a header
file and be made static inline.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The encoder possible_crtcs mask identifies which CRTCs can be bound to
a particular encoder. Each bit from bit 0 defines an index in the list
of CRTCs held in the DRM mode_config crtc_list. Rather than having
drivers trying to track the position of their CRTCs in the list, expose
the code which already exists for calculating the appropriate mask bit
for a CRTC.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[treding@nvidia.com: add drm_crtc_index(), move to core]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Bit-copying restoration of CRTC structure in failure-recovery
path of drm_crtc_helper_set_config function evokes a
subtle and rare, but very dangerous, corruption of
CRTC mutex structure.
Namely, if drm_crtc_helper_set_config takes the path under
'fail:' label *and* some other process has attempted to
grab the crtc mutex (and got blocked), restoring the CRTC
structure by bit-copying it will overwrite the CRTC mutex
state and the waiters list pointer within the mutex structure.
Consequently the blocked process will never be scheduled.
This patch fixes the issue by eliminating the bit-copy
restoration. The elimination is possible because previous
patches have cleaned up the resoration path so that only
the fields touched by the drm_crtc_helper_set_config function
are saved and restored if necessary.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is no need to set crtc->enabled field in
drm_crtc_helper_set_config. This is already done (and
properly restored in case of failure) in
drm_crtc_helper_set_mode that is called by
drm_crtc_helper_set_config. Doing it at only one
place makes restoration in case of failure easier.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is no need to save or restore hwmode field, because by
the time this function sets this field, it cannot fail any more.
However, we should save old enabled field because if
the function fails, we want to return with unchanged CRTC.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Old framebuffer is stored in save_set.fb and it is
the same value that is later stored in old_fb.
This makes old_fb redundant so we can replace
it with save_set.fb.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The biggest part of the changes is the decoupling of the host1x and DRM
drivers followed by the move of Tegra DRM back to drivers/gpu/drm/tegra
from whence it came. There is a lot of cleanup as well, and the drivers
can now be properly unloaded and reloaded.
HDMI support for the Tegra114 SoC was contributed by Mikko Perttunen.
gr2d support was extended to Tegra114 and the gr3d driver that has been
in the works for quite some time finally made it in. All pieces to run
an OpenGL driver on top of an upstream kernel are now available.
Support for syncpoint bases was added by Arto Merilainen. This is useful
for synchronizing between command streams from different engines such as
gr2d and gr3d.
Erik Faye-Lund and Wei Yongjun contributed various small fixes. Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSch6LAAoJEN0jrNd/PrOhvYwP/ir8/pK0kWLdowfArmZqs1T7
YhFy3zOCDkf2FKwNshsU8gwc8qeaCkP07LUBtjg+BvPdaHBQShLmwkNLKeV6tfLn
A6gtCMkJG3l52PxoM9NtRIyq9Xot8Sv1H+PNSYjKgUDrIYNYkMhgG90+Aj409Qkw
bbons3/CH58ufxY47wpGTFxhsiHX/9CSOlWl2RVfyzeyi5sVG+e+it3jsCl3ma9X
lmCBJuZlaZsB1xy9kQaYobpL0BiNwhTOVeh0YmUQDBxFtIcY9j2h1dOCsh4o1sPp
Aht/r8OaBxCu4ykAoGByaO/Bz6PQEaX1nW776edR1dusUBOupRjmyHcz1unq1Qpo
PUI0zs823WrWX863FQcG+i71wdZDmRReGPduv+94H0IT6NtQEC2fT1eJdn2DtI0L
GD3d8NR92hGdYVH01tEILlrT4Rrlemb0CWr+Vf6T3LwU44Jns/9X3UnG+GVE7IwT
GreK0FjCTKeNZeMKGCJ0aKwjwEd7VMiFRiuEZfoemik8X3ib8f8oCeXIX1gD1ksz
vGSaSjhx//X7/hco+1DSqdPOJnXd/ZUC0AkFQ0lIJ2mQvZfwHx55uE/AFjD1WE4/
BNsTP+8C97IA/zAK241Ow+f1cLhRp1ZlgOVbFZp+EttKZ2vxRik/jV8MsBfhWJBX
gIAXabh1MvhxagGaiFmb
=qc03
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.13-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.13-rc1
The biggest part of the changes is the decoupling of the host1x and DRM
drivers followed by the move of Tegra DRM back to drivers/gpu/drm/tegra
from whence it came. There is a lot of cleanup as well, and the drivers
can now be properly unloaded and reloaded.
HDMI support for the Tegra114 SoC was contributed by Mikko Perttunen.
gr2d support was extended to Tegra114 and the gr3d driver that has been
in the works for quite some time finally made it in. All pieces to run
an OpenGL driver on top of an upstream kernel are now available.
Support for syncpoint bases was added by Arto Merilainen. This is useful
for synchronizing between command streams from different engines such as
gr2d and gr3d.
Erik Faye-Lund and Wei Yongjun contributed various small fixes. Thanks!
* tag 'drm/for-3.13-rc1' of git://anongit.freedesktop.org/tegra/linux: (45 commits)
drm/tegra: Reserve syncpoint base for gr3d
drm/tegra: Reserve base for gr2d
drm/tegra: Deliver syncpoint base to user space
gpu: host1x: Add syncpoint base support
gpu: host1x: Add 'flags' field to syncpt request
drm/tegra: Disable clock on probe failure
gpu: host1x: Disable clock on probe failure
drm/tegra: Support bottom-up buffer objects
drm/tegra: Add support for tiled buffer objects
drm/tegra: Add 3D support
drm/tegra: Introduce tegra_drm_submit()
drm/tegra: Use symbolic names for gr2d registers
drm/tegra: Start connectors with correct DPMS mode
drm/tegra: hdmi: Enable VDD earlier for hotplug/DDC
drm/tegra: hdmi: Fix build warnings
drm/tegra: hdmi: Detect DVI-only displays
drm/tegra: Add Tegra114 HDMI support
drm/tegra: hdmi: Parameterize based on compatible property
drm/tegra: hdmi: Rename tegra{2,3} to tegra{20,30}
gpu: host1x: Add support for Tegra114
...
When userspace removes the active framebuffer using DRM_IOCTL_MODE_RMFB,
or explicitly disables the CRTC (by calling drmModeSetCrtc(..., NULL)
for example), a NULL framebuffer will be passed to the .set_config()
implementation of a CRTC. The drm_crtc_helper_set_config() helper will
decide to disable a CRTC when that happens.
To do so, it calls drm_crtc_helper_disable(), which in turn will iterate
over all encoders and decouple them from their connectors and finally
call drm_helper_disable_unused_functions() to clean up and call the
.disable() or .dpms() implementation for each encoder. However, at no
point during this sequence does it track the DPMS mode of a connector,
so it will usually remain on after this.
When a connector is enabled again, drm_helper_connector_dpms() will not
notice that the DPMS mode actually changed and won't do anything, which
causes the connector to stay disabled indefinitely.
To prevent this from happening, explicitly set the connector's DPMS mode
to off when the CRTC is disabled. That way it reflects the correct state
and can be enabled again.
This solves an issue observed when terminating an X server running on
the xf86-video-modesetting driver. Without this patch, the connector
would not be enabled properly and the screen would stay dark.
Acked-by: David Airlie <airlied@linux.ie>
Signed-off-by: Thierry Reding <treding@nvidia.com>
- CRC support from Damien and He Shuang. Long term this should allow us to
test an awful lot modesetting corner cases automatically. So for me as
the maintainer this is really big.
- HDMI audio fix from Jani.
- VLV dpll computation code refactoring from Ville.
- Fixups for the gpu booster from last time around (Chris).
- Some cleanups in the context code from Ben.
- More watermark work from Ville (we'll be getting there ...).
- vblank timestamp improvements from Ville.
- CONFIG_FB=n support, including drm core changes to make the fbdev
helpers optional.
- DP link training improvements (Jani).
- mmio vtable from Ben, prep work for future hw.
* tag 'drm-intel-next-2013-10-18' of git://people.freedesktop.org/~danvet/drm-intel: (132 commits)
drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp
drm/i915: remove dead code in ironlake_crtc_mode_set
drm/i915: crc support for hsw
drm/i915: fix CRC debugfs setup
drm/i915: wait one vblank when disabling CRCs
drm/i915: use ->get_vblank_counter for the crc frame counter
drm/i915: wire up CRC interrupt for ilk/snb
drm/i915: add CRC #defines for ilk/snb
drm/i915: extract display_pipe_crc_update
drm/i915: don't Oops in debugfs for I915_FBDEV=n
drm/i915: set HDMI pixel clock in audio configuration
drm/i915: pass mode to ELD write vfuncs
cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n
drm/i915: check gem bo size when creating framebuffers
drm/i915: Use unsigned long for obj->user_pin_count
drm/i915: prevent tiling changes on framebuffer backing storage
drm/i915: grab dev->struct_mutex around framebuffer_init
drm/i915: vlv: fix VGA hotplug after modeset
drm: add support for additional stereo 3D modes
drm/i915: preserve dispaly init order on ByT
...
The caller may want to know whether the configuration was changed, and
if an hotplug event was sent.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For drivers which might want to disable fbdev legacy support.
Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.
v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!
v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The conflict in intel_drv.h tripped me up a bit since a patch in dinq
moves all the functions around, but another one in drm-next removes a
single function. So I'ev figured backing this into a backmerge would
be good.
i915_dma.c is just adjacent lines changed, nothing nefarious there.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_drv.h
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_helper_probe_single_connector_modes() can be used to implement
->fill_modes(), not ->probe().
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just like with interlaced or double scan modes, make stereo modes a
per-connector opt-in to give a chance to driver authors to make it work
before enabling it.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, and dpms (via the enable/disable hooks).
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b684
Author: Imre Deak <imre.deak@intel.com>
Date: Fri May 3 19:44:07 2013 +0200
drm/i915: force full modeset if the connector is in DPMS OFF mode
which according to Greg KH seems to aim for a new record in most
Bugzilla: links in a commit message.
The history of this dpms forcing is pretty interesting. This patch
here is an almost-revert of
commit 811aaa55ba
Author: Keith Packard <keithp@keithp.com>
Date: Thu Feb 3 16:57:28 2011 -0800
drm: Only set DPMS ON when actually configuring a mode
which fixed the bug of trying to dpms on disabled outputs, but
introduced the new discrepancy between an fb update only and full
modesets. The actual introduction of this goes back to
commit bf9dc102e2
Author: Keith Packard <keithp@keithp.com>
Date: Fri Nov 26 10:45:58 2010 -0800
drm: Set connector DPMS status to ON in drm_crtc_helper_set_config
And if you'd dig around in the i915 driver code there's even more fun
around forcing dpms on and losing our heads and temper of the
resulting inconsistencies. Especially the DP re-training code had tons
of funny stuff in it.
v2: So v1 totally blew up on resume on my radeon system here. After
much head-scraching I've figured out that the radeon resume functions
resumes the console system _before_ it actually restores all the
modeset state. And resuming the console systems means that fbdev doeas
an immediate ->set_par call.
Now up to this patch that ->set_par did absolutely nothing: All the
old sw state from pre-suspend was still around (since the modeset
reset wasn't done yet), which means that the set_config calls done as
a result of the ->set_par where all treated as no-ops (despite that
the real hw state was obviously something completely different).
Since v1 of this patch just added a bunch of ->dpms calls if the crtc
was enabled, those set_config calls suddenly stopped being no-ops. But
because the hw state wasn't restored the ->dpms callbacks resulted in
decent amounts of hilarity and eventual full hangs.
Since I can't review all kms drivers for such tricky ordering
constraints v2 opts for a different approach and forces a full modeset
if the connector dpms state isnt' DPMS_ON. Since the ->dpms callbacks
implemented by the modeset helpers update the connector->dpms property
we have the same effect of ensuring that the pipe is ultimately turned
on, even if we just end up updating the fb. This is the same approac
we ended up using in the intel driver.
Note that besides i915.ko only all other drivers eventually call
drm_helper_connector_dpms with the exception of vmwgfx, which does not
support dmps at all.
v3: Dave Airlie merged the broken first version of this patch, so
squash in the revert of
commit 372835a852
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jun 15 00:13:13 2013 +0200
drm/crtc-helper: explicit DPMS on after modeset
Also fix up the spelling fail a bit in the commit message while at it.
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67043
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter