I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.
Shipping userspace seems to have never relied on this, and the kernel
also never put any blob thing onto that property. And nowadays it
would blow up, e.g. in drm_property_destroy. Also it makes no sense to
return values in an ioctl that only returns metadata about everything.
So let's ditch all the internal code for the blob list, rename the
list to be unambiguous and sprinkle comments all over the place to
explain this peculiar piece of api.
v2: Squash in fixup from Rob to remove now unused variables.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar issues.
So store the sizes of the arrays in struct drm_atomic_state and double
check them. We don't really care about races except that we want to
use a consistent value, so ACCESS_ONCE is all we need. And if we
indeed notice that we'd overrun the array then just give up and
restart the entire ioctl.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input
Some drivers erroneously treat the .pitch and .size fields of struct
drm_mode_create_dumb as inputs. While the include/uapi/drm/drm_mode.h
header has a comment denoting them as outputs, that seemingly wasn't
enough to make drivers use them properly.
The result is that some userspace doesn't explicitly zero out those
fields, assuming that the kernel won't use them. That causes problems
since the data within the structure might be uninitialized, so bogus
data may end up confusing drivers (ridiculously large values for the
pitch, ...).
This series attempts to improve the situation by fixing all drivers to
not use the output fields. Furthermore to spare new drivers this bad
surprise, the DRM core now zeros out these fields prior to handing the
data structure to the driver.
Lessons learned from this are that future IOCTLs should be properly
documented (in the DRM DocBook for example) and should be rigorously
defined. To prevent misuse like this, userspace should be required to
zero out all output fields. The kernel should check for this and fail
if that's not the case.
* tag 'drm/gem-cma/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux:
drm/cma: Remove call to drm_gem_free_mmap_offset()
drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input
drm/rcar: gem: dumb: pitch is an output
drm/omap: gem: dumb: pitch is an output
drm/cma: Introduce drm_gem_cma_dumb_create_internal()
drm/doc: Add GEM/CMA helpers to kerneldoc
drm/doc: mm: Fix indentation
drm/gem: Fix a few kerneldoc typos
Virtual GPUs would like to give the guest some indication where on the screen
the outputs are layed out. So far we only provide modes, these
properties could be exposed to userspace so the desktop environment
could use them as hints to set the correct offsets.
v2: rename properties to be more consistent.
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/tegra: Changes for v3.19-rc1
The highlights in this pull request are:
* IOMMU support: The Tegra DRM driver can now deal with discontiguous
buffers if an IOMMU exists in the system. That means it can allocate
using drm_gem_get_pages() and will map them into IOVA space via the
IOMMU API. Similarly, non-contiguous PRIME buffers can be imported
from a different driver, which allows better integration with gk20a
(nouveau) and less hacks.
* Universal planes: This is precursory work for atomic modesetting and
will allow hardware cursor support to be implemented on pre-Tegra114
where RGB cursors were not supported.
* DSI ganged-mode support: The DSI controller can now gang up with a
second DSI controller to drive high resolution DSI panels.
Besides those bigger changes there is a slew of fixes, cleanups, plugged
memory leaks and so on.
* tag 'drm/tegra/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux: (44 commits)
drm/tegra: gem: Check before freeing CMA memory
drm/tegra: fb: Add error codes to error messages
drm/tegra: fb: Properly release GEM objects on failure
drm/tegra: Detach panel when a connector is removed
drm/tegra: Plug memory leak
drm/tegra: gem: Use more consistent data types
drm/tegra: fb: Do not destroy framebuffer
drm/tegra: gem: dumb: pitch and size are outputs
drm/tegra: Enable the hotplug interrupt only when necessary
drm/tegra: dc: Universal plane support
drm/tegra: dc: Registers are 32 bits wide
drm/tegra: dc: Factor out DC, window and cursor commit
drm/tegra: Add IOMMU support
drm/tegra: Fix error handling cleanup
drm/tegra: gem: Use dma_mmap_writecombine()
drm/tegra: gem: Remove redundant drm_gem_free_mmap_offset()
drm/tegra: gem: Cleanup tegra_bo_create_with_handle()
drm/tegra: gem: Extract tegra_bo_alloc_object()
drm/tegra: dsi: Set up PHY_TIMING & BTA_TIMING registers earlier
drm/tegra: dsi: Replace 1000000 by USEC_PER_SEC
...
drm: Miscellaneous fixes for v3.19-rc1
This is a small collection of fixes that I've been carrying around for a
while now. Many of these have been posted and reviewed or acked. The few
that haven't I deemed too trivial to bother.
* tag 'drm/fixes/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux:
video/hdmi: Relicense header under MIT license
drm/gma500: mdfld: Reuse video/mipi_display.h
drm: Make drm_mode_create_tv_properties() signature consistent
drm: Implement drm_get_pci_dev() dummy for !PCI
drm/prime: Use unsigned type for number of pages
drm/gem: Fix typo in kerneldoc
drm: Use const data when creating blob properties
drm: Use size_t for blob property sizes
drm/panel: Changes for v3.19-rc1
This contains support for a couple of new panels, updates for some GPIO
API changes and a bunch of updates to the MIPI DSI support that should
make it easier to write panel drivers in the future.
* tag 'drm/panel/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux: (31 commits)
drm/panel: Add Sharp LQ101R1SX01 support
drm/dsi: Do not require .owner field to be set
drm/dsi: Resolve MIPI DSI device from phandle
drm/dsi: Implement DCS set_{column,page}_address commands
drm/dsi: Implement DCS {get,set}_pixel_format commands
drm/dsi: Implement DCS get_power_mode command
drm/dsi: Implement DCS soft_reset command
drm/dsi: Implement DCS nop command
drm/dsi: Add to DocBook documentation
drm/dsi: Implement some standard DCS commands
drm/dsi: Implement generic read and write commands
drm/panel: s6e8aa0: Use standard MIPI DSI function
drm/dsi: Add mipi_dsi_set_maximum_return_packet_size() helper
drm/dsi: Constify mipi_dsi_msg
drm/dsi: Make mipi_dsi_dcs_{read,write}() symmetrical
drm/dsi: Add DSI transfer helper
drm/dsi: Add message to packet translator
drm/dsi: Introduce packet format helpers
drm/panel: s6e8aa0: Fix build warnings on 64-bit
drm/panel: ld9040: Fix build warnings on 64-bit
...
- skl watermarks code (Damien, Vandana, Pradeep)
- reworked audio codec /eld handling code (Jani)
- rework the mmio_flip code to use the vblank evade logic and wait for rendering
using the standard wait_seqno interface (Ander)
- skl forcewake support (Zhe Wang)
- refactor the chv interrupt code to use functions shared with vlv (Ville)
- prep work for different global gtt views (Tvrtko Ursulin)
- precompute the display PLL config before touching hw state (Ander)
- completely reworked panel power sequencer code for chv/vlv (Ville)
- pre work to split the plane update code into a prepare and commit phase
(Gustavo Padovan)
- golden context for skl (Armin Reese)
- as usual tons of fixes and improvements all over
* tag 'drm-intel-next-2014-11-07-fixups' of git://anongit.freedesktop.org/drm-intel: (135 commits)
drm/i915: Use correct pipe config to update pll dividers. V2
drm/i915: Plug memory leak in intel_shared_dpll_start_config()
drm/i915: Update DRIVER_DATE to 20141107
drm/i915: Add gen to the gpu hang ecode
drm/i915: Cache HPLL frequency on VLV/CHV
Revert "drm/i915/vlv: Remove check for Old Ack during forcewake"
drm/i915: Make mmio flip wait for seqno in the work function
drm/i915: Make __wait_seqno non-static and rename to __i915_wait_seqno
drm/i915: Move the .global_resources() hook call into modeset_update_crtc_power_domains()
drm/i915/audio: add DOC comment describing HDA over HDMI/DP
drm/i915: make pipe/port based audio valid accessors easier to use
drm/i915/audio: add audio codec enable debug log for g4x
drm/i915/audio: add audio codec disable on g4x
drm/i915: enable audio codec after port
drm/i915/audio: add vlv/chv/gen5-7 audio codec disable sequence
drm/i915/audio: rewrite vlv/chv and gen 5-7 audio codec enable sequence
drm/i915/skl: Enable Gen9 RC6
drm/i915/skl: Gen9 Forcewake
drm/i915/skl: Log the order in which we flush the pipes in the WM code
drm/i915/skl: Flush the WM configuration
...
Now that we're using lists instead of kfifo to store drm flip-work tasks
we do not need the size parameter passed to drm_flip_work_init function
anymore.
Moreover this function cannot fail anymore, we can thus remove the return
code.
Modify drm_flip_work_init users to take account of these changes.
[airlied: fixed two unused variable warnings]
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make use of lists instead of kfifo in order to dynamically allocate
task entry when someone require some delayed work, and thus preventing
drm_flip_work_queue from directly calling func instead of queuing this
call.
This allow drm_flip_work_queue to be safely called even within irq
handlers.
Add new helper functions to allocate a flip work task and queue it when
needed. This prevents allocating data within irq context (which might
impact the time spent in the irq handler).
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Rather than cast to a u32 use the struct host1x_bo pointers directly.
This avoid annoying warnings for 64-bit builds.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Drivers now no longer need to set the .owner field. It will be
automatically set at registration time.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a function, of_find_mipi_dsi_device_by_node(), that can be used to
resolve a phandle to a MIPI DSI device.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide small convenience wrappers to set the column and page extents of
the frame memory accessed by the host processors.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide small convenience wrappers to query or set the pixel format used
by the interface.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide a small convenience wrapper that transmits a DCS get_power_mode
command. A set of bitmasks for the mode bits is also provided.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide a small convenience wrapper that transmits a DCS soft_reset
command.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Provide a small convenience wrapper that transmits a DCS nop command.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Integrate the MIPI DSI helpers into DocBook and clean up various
kerneldoc warnings. Also add a brief DOC section and clarify some
aspects of the mipi_dsi_host struct's .transfer() operation.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add helpers for the {enter,exit}_sleep_mode, set_display_{on,off} and
set_tear_{on,off} DCS commands.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
[treding: kerneldoc and other minor cleanup]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Implement generic read and write commands. Selection of the proper data
type for packets is done automatically based on the number of parameters
or payload length.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function can be used to set the maximum return packet size for a
MIPI DSI peripheral.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
[treding: endianess, kerneldoc, return value]
Signed-off-by: Thierry Reding <treding@nvidia.com>
struct mipi_dsi_msg is a read-only structure, drivers should never need
to modify it. Make this explicit by making all references to the struct
const.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Currently the mipi_dsi_dcs_write() function requires the DCS command
byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
has a separate parameter. Make them more symmetrical by adding an extra
command parameter to mipi_dsi_dcs_write().
The S6E8AA0 driver relies on the old asymmetric API and there's concern
that moving to the new API may be less efficient. Provide a new function
with the old semantics for those cases and make the S6E8AA0 driver use
it instead.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This commit introduces a new function, mipi_dsi_create_packet(), which
converts from a MIPI DSI message to a MIPI DSI packet. The MIPI DSI
packet is as close to the protocol described in the DSI specification as
possible and useful in drivers that need to write a DSI packet into a
FIFO to send a message off to the peripheral.
Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add two helpers, mipi_dsi_packet_format_is_{short,long}(), that help in
determining the format of a packet.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function is similar to drm_gem_cma_dumb_create() but targetted at
kernel internal users so that they can override the pitch and size
requirements of the dumb buffer.
It is important to make this difference because the IOCTL says that the
pitch and size fields are to be considered outputs and therefore should
not be used in computations of the framebuffer size. Internal users may
still want to use this code to avoid duplication and at the same time
pass on additional, driver-specific restrictions on the pitch and size.
While at it, convert the R-Car DU driver, the single user that overrides
the pitch, to use the new internal helper.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Most of the functions already have the beginnings of kerneldoc comments
but are using the wrong opening marker. Use the correct opening marker
and flesh out the comments so that they can be integrated with the DRM
DocBook document.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The prototype and the function implementation differ in their signature.
Make them consistent and use an unsigned integer for the number of modes
while at it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Implementing a dummy of this function allows drivers that use it to be
built on platforms that don't have PCI. This can happen for example if
the nouveau driver is built on Tegra without PCI enabled (or on 64-bit
ARM where PCI is not yet implemented).
Signed-off-by: Thierry Reding <treding@nvidia.com>
The number of pages can never be negative, so an unsigned type is
enough. This also matches the type of the n_pages argument of the
sg_alloc_table_from_pages() function.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Creating a blob property will always copy the input data so the data
that is passed in can be const.
Signed-off-by: Thierry Reding <treding@nvidia.com>
size_t is the standard type when dealing with sizes of all kinds. Use it
consistently when instantiating DRM blob properties.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:
- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
justification as for the equivalent change in drm_crtc_init done in
commit d0fa1af40e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Sep 8 09:02:49 2014 +0200
drm: Drop modeset locking from crtc init function
Without these the drm_modeset_lock_init would fall over the exact
same way.
- Since the atomic core code wraps the locking switching it to
per-plane locks was a one-line change.
- For the legacy ioctls add a plane argument to the locking helper so
that we can grab the right plane lock (cursor or primary). Since the
universal cursor plane might not be there, or someone really crazy
might forgoe the primary plane even accept NULL.
- Add some locking WARN_ON to the atomic helpers for good paranoid
measure and to check that it all works out.
Tested on my exynos atomic hackfest with full lockdep checks and ww
backoff injection.
v2: I've forgotten about the load-detect code in i915.
v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
more due to
commit 21e88620aa
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Oct 30 13:39:04 2014 -0400
drm/vmwgfx: fix lock breakage
Rebased and fix this up.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Backmerge drm-next so that I can keep merging patches. Specifically I
want:
- atomic stuff, yay!
- eld parsing patch from Jani.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
So here's my atomic series, finally all debugged&reviewed. Sean Paul has
done a full detailed pass over it all, and a lot of other people have
commented and provided feedback on some parts. Rob Clark also converted
msm over the w/e and seems happy. The only small thing is that Rob wants
to export the wait_for_vblank, which imo makes sense. Since there's other
stuff still to do I think we should apply Rob's patch (once it has grown
appropriate kerneldoc) later on top of this.
This is just the core<->driver interface plus a big pile of helpers. Short
recap of the main ideas:
- There are essentially three helper libraries in this patch set:
* Transitional helpers to use the new plane callbacks for legacy plane
updates and in the crtc helper's ->mode_set callback. These helpers are
only temporarily used to convert drivers to atomic, but they allow a
nice separation between changing the driver backend and switching to
the atomic commit logic.
* Legacy helpers to implement all the legacy driver entry points
(page_flip, set_config, plane vfuncs) on top of the new atomic driver
interface. These are completely driver agnostic. The reason for having
the legacy support as helpers is that drivers can switch step-by-step.
And they could e.g. even keep the legacy page_flip code around for some
old platforms where converting to full-blown atomic isn't worth it.
* Atomic helpers which implement the various new ->atomic_* driver
interfaces in terms of the revised crtc helper and new plane helper
hooks.
- The revised crtc helper implemenation essentially implements all the
lessons learned in the i915 modeset rework (when using the atomic helpers
only):
* Enable/disable sequence for a given config are always the same and
callbacks are always called in the same order. This contrast starkly
with the crtc helpers, where the sequence of operations is heavily
dependent on the previous config.
One corollary of this is that if the configuration of a crtc only
partially changes (e.g. a connector moves in a cloned config) the
helper code will still disable/enable the full display pipeline. This
is the only way to ensure that the enable/disable sequence is always
the same.
* It won't call disable or enable hooks more than once any more because
it lost track of state, thanks to the atomic state tracking. And if
drivers implement the ->reset hook properly (by either resetting the hw
or reading out the hw state into the atomic structures) this even
extends to the hardware state. So no more disable-me-harder kind of
nonsense.
* The only thing missing is the hw state readout/cross-check support, but
if drivers have hw state readout support in their ->reset handlers it's
simple to extend that to cross-check the hw state.
* The crtc->mode_set callback is gone and its replacement only sets crtc
timings and no longer updates the primary plane state. This way we can
finally implement primary planes properly.
- The new plane helpers should be suitable enough for pretty much
everything, and a perfect fit for hardware with GO bits. Even if they
don't fit the atomic helper library is rather flexible and exports all
the functions for the individual steps to drivers. So drivers can pick
what matches and implement their own magic for everything else.
- A big difference compared to all previous atomic series is that this one
doesn't implement async commit in a generic way. Imo driver requirements
for that are too diverse to create anything reasonable sane which would
actually work on a reasonable amount of different drivers. Also, we've
never had a helper library for page_flips even, so it's really hard to
know what might work and what's stupid without a bit of experience in the form
of a few driver implementations.
I think with the current flexibility for drivers to pick individual
stages and existing helpers like drm_flip_queue it's rather easy though
to implement proper async commit.
- There's a few other differences of minor importance to earlier atomic
series:
* Common/generic properties are parsed in the callers/core and not in
drivers, and passed to drivers by directly setting the right members in
atomic state structures. That greatly simplifies all the transitional
and legacy helpers an removes a lot of boilerplate code.
* There's no crazy trylock mode used for the async commit since these
helpers don't do async commit. A simple ordered flip queue of atomic
state updates should be sufficient for preventing concurrent hw access
anyway, as long as synchronous updates stall correctly with e.g.
flush_work_queue or similar function. Abusing locks to enforce ordering
isn't a good idea imo anyway.
* These helpers reuse the existing ->mode_fixup hooks in the atomic_check
callback. Which means that drivers need to adapat and move a lot less code
into their atomic_check callbacks.
Now this isn't everything needed in the drm core and helpers for full
atomic support. But it's enough to start with converting drivers, and
except for actually testing multiplane and multicrtc updates also enough to
implement full atomic updates. Still missing are:
- Per-plane locking. Since these helpers here encapsulate the locking
completely this should be fairly easy to implement.
- fbdev support for atomic_check/commit, so that multi-pipe finally works
sanely in fbcon.
- Adding and decoding shared/core properties. That just needs to be rebased
from Rob's latest patch series, with minor adjustments so that the
decoding happens in the core instead of in drivers.
- Actually adding the atomic ioctl. Again just rebasing Rob's latest patch
should be all that's needed.
- Resolving how to deal with DPMS in atomic. Atomic is a good excuse to fix up
the crazy semantics dpms currently has. I'm floating an RFC about this topic
already.
- Finally I couldn't test connector/encoder stealing properly since my test
vehicle here doesn't allow a connector on different crtcs. So drivers
which support this might see some surprises in that area. There is no semantic
change though in how encoder stealing and assignment works (or at least no
intended one), so I think the risk is minimal.
As just mentioned I've done a fake conversion of an existing driver using
crtc helpers to debug the helper code and validate the smooth transition
approach. And that smooth transition was the really big motivation for
this. It seems to actually work and consists of 3 phases:
Phase 1: Rework driver backend for crtc/plane helpers
The requirement here is that universal plane support is already implement. If
universal plane support isn't implement yet it might be better though to just do
it as part of this phase, directly using the new plane helpers. There are two
big things to do:
- Split up the existing ->update/disable_plane hooks into check/commit
hooks and extract the crtc-wide prep/flush parts (like setting/clearing
GO bits).
- The other big change is to split the crtc->mode_set hook into the plane
update (done using the plane helpers) and the crtc setup in a new
->mode_set_nofb hook.
When phase 1 is complete the driver implements all the new callbacks which
push the software state into hardware, but still using all the legacy entry
points and crtc helpers. The transitional helpers serve as impendance
mismatch here.
Phase 2: Rework state handling
This consists of rolling out the state handling helpers for planes, crtcs
and connectors and reviewing all ->mode_fixup and similar hooks to make
sure they don't depend upon implicit global state which might change in the
atomic world. Any such code must be moved into ->atomic_check functions which
just rely on the free-standing atomic state update structures.
This phase also adds a few small pieces of fixup code to make sure the
atomic state doesn't get out of sync in the legacy driver callbacks.
Phase 3: Roll out atomic support
Now it's just about replacing vfuncs with the ones provided by the helper
and filling out the small missing pieces (like atomic_check logic or async
commit support needed for page_flips). Due to the prep work in phase 1 no
changes to the driver backend functions should be required, and because of
the prep work in phase 2 atomic implementations can be rolled out
step-by-step. So if async commit ins't implemented yet page_flip can be
implemented with the legacy functions without wreaking havoc in the other
operations.
* tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: Refcounting for plane_state->fb
drm: Docbook integration and over sections for all the new helpers
drm/atomic-helpers: functions for state duplicate/destroy/reset
drm/atomic-helper: implement ->page_flip
drm/atomic-helpers: document how to implement async commit
drm/atomic: Integrate fence support
drm/atomic-helper: implementatations for legacy interfaces
drm: Atomic crtc/connector updates using crtc/plane helper interfaces
drm/crtc-helper: Transitional functions using atomic plane helpers
drm/plane-helper: transitional atomic plane helpers
drm: Add atomic/plane helpers
drm: Global atomic state handling
drm: Add atomic driver interface definitions for objects
drm/modeset_lock: document trylock_only in kerneldoc
drm: fixup kerneldoc in drm_crtc.h
drm: Pull drm_crtc.h into the kerneldoc template
drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h
Pull ARM SoC fixes from Olof Johansson:
"Another quiet week:
- a fix to silence edma probe error on non-supported platforms from
Arnd
- a fix to enable the PL clock for Parallella, to make mainline
usable with the SDK.
- a somewhat verbose fix for the PLL clock tree on VF610
- enabling of SD/MMC on one of the VF610-based boards (for testing)
- a fix for i.MX where CONFIG_SPI used to be implicitly enabled and
now needs to be added to the defconfig instead
- another maintainer added for bcm2835: Lee Jones"
* tag 'armsoc-for-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: dts: zynq: Enable PL clocks for Parallella
dma: edma: move device registration to platform code
ARM: dts: vf610: add SD node to cosmic dts
MAINTAINERS: update bcm2835 entry
ARM: imx: Fix the removal of CONFIG_SPI option
ARM: imx: clk-vf610: define PLL's clock tree
Pull devicetree bugfix from Grant Likely:
"One buffer overflow bug that shouldn't be left around"
* 'devicetree/merge' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux:
of: Fix overflow bug in string property parsing functions
Userspace cares about whether or not swizzling depends on the page
address for its direct access into bound objects. Extend the get_tiling
ioctl to report the physical swizzling value in addition to the logical
swizzling value so that userspace can accurately determine when it is
possible for manual detiling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Testcase: igt/gem_tiled_wc
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just various stuff all over from a bunch of people. Shortlog gives a beter
overview, it's really all misc drm patches.
* tag 'topic/core-stuff-2014-11-05' of git://anongit.freedesktop.org/drm-intel:
drm/edid: add #defines and helpers for ELD
drm/dp: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs
drm: Remove compiler BUG_ON() test
drm: Fix DRM_FORCE_ON_DIGITAL use
drm/gma500: Don't destroy DRM properties in the driver
drm/i915: Don't destroy DRM properties in the driver
drm: Add a note to drm_property_create() about property lifetime
gpu: drm: Fix warning caused by a parameter description in drm_crtc.c
drm/dp-helper: Move the legacy helpers to gma500
drm/crtc: Remove duplicated ioctl code
drm/crtc: Fix two typos
gpu:drm: Fix typo in Documentation/DocBook/drm.xml
gpu: drm: drm_dp_mst_topology.c: Fix improper use of strncat
drm: drm_err: Remove unnecessary __func__ argument
drm: Implement O_NONBLOCK support on /dev/dri/cardN
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>
The atomic users and helpers assume that there is always a obj->state
structure around. Which means drivers need to somehow create that at
driver load time. Also it should obviously reset hardware state, so
needs to be reset upon resume.
Finally the destroy/duplicate_state functions are an awful lot of
boilerplate if the driver doesn't need anything beyond the default
state objects.
So add helper functions for all of this.
v2: Somehow the plane/connector versions got lost in the first
version.
v3: Add kerneldoc.
v4: Make duplicate_state functions a bit more robust, which is useful
for debugging state tracking issues when transitioning to atomic.
v5: Clear temporary variables in the crtc state when duplicating it,
like ->mode_changed or ->planes_changed. If we don't do this stale
values for these might pollute the next atomic modeset.
v6: Also clear crtc_state->event in case the driver didn't (yet) clear
this out.
v7: Split out wrong squashed commit. Also improve the kerneldoc to
mention that obj->state can be NULL and when. Both suggested by
Daniel Thompson.
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently there is no way to implement async flips using atomic, that
essentially requires us to be able to cancel pending requests
mid-flight.
To be able to do that (and I guess we want this since vblank synced
updates which opportunistically cancel still pending updates seem to be
wanted) we'd need to add a mandatory cancellation mode. Depending upon
the exact semantics we decide upon that could mean that userspace will
not get completion events, or will get them all stacked up.
So reject async updates for now. Also async updates usually means not
vblank synced at all, and I guess for drivers which want to support
this they should simply add a special pageflip handler (since usually
you need a special flip cmd to achieve this). That kind of async flip
is pretty much exclusively just used for games and benchmarks where
dropping just one frame means you'll get a headshot or something bad
like that ... And so slight amounts of tearing is acceptable.
v2: Fixup kerneldoc, reported by Paulo.
v3: Use the set_crtc_for_plane function to assign the crtc, since
otherwise the book-keeping is off.
v4: Update crtc->primary->fb since ->page_flip is the only driver
callback where the core won't do this itself. We might want to fix
this inconsistency eventually.
v5: Use set_crtc_for_connector as suggested by Sean.
v6: Daniel Thompson noticed that my error handling is inconsistent
and that in a few cases I didn't handle fatal errors (i.e. not
-EDEADLK). Fix this by consolidate the ww mutex backoff handling
into one check in the fail: block and flatten the error control
flow everywhere else.
v7: Fix spelling mistake in the commit message (Sean).
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch is for enabling async commits. It replaces an earlier
approach which added an async boolean paramter to the ->prepare_fb
callbacks. The idea is that prepare_fb picks up the right fence to
synchronize against, which is then used by the synchronous commit
helper. For async commits drivers can either register a callback to
the fence or simply do the synchronous wait in their async work queue.
v2: Remove unused variable.
v3: Only wait for fences after the point of no return in the part
of the commit function which can be run asynchronously. This is after
the atomic state has been swapped in, hence now check
plane->state->fence.
Also add a WARN_ON to make sure we don't try to wait on a fence when
there's no fb, just as a sanity check.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Well, except page_flip since that requires async commit, which isn't
there yet.
For the functions which changes planes there's a bit of trickery
involved to keep the fb refcounting working. But otherwise fairly
straight-forward atomic updates.
The property setting functions are still a bit incomplete. Once we
have generic properties (e.g. rotation, but also all the properties
needed by the atomic ioctl) we need to filter those out and parse them
in the helper. Preferrably with the same function as used by the real
atomic ioctl implementation.
v2: Fixup kerneldoc, reported by Paulo.
v3: Add missing EXPORT_SYMBOL.
v4: We need to look at the crtc of the modeset, not some random
leftover one from a previous loop when udpating the connector->crtc
routing. Also push some local variables into inner loops to avoid
these kinds of bugs.
v5: Adjust semantics - drivers now own the atomic state upon
successfully synchronous commit.
v6: Use the set_crtc_for_plane function to assign the crtc, since
otherwise the book-keeping is off.
v7:
- Improve comments.
- Filter out the crtc of the ->set_config call when recomputing
crtc_state->enabled: We should compute the same state, but not doing
so will give us a good chance to catch bugs and inconsistencies -
the atomic helper's atomic_check function re-validates this again.
- Fix the set_config implementation logic when disabling the crtc: We
still need to update the output routing to disable all the
connectors properly in the state. Caught by the atomic_check
functions, so at least that part worked ;-) Also add some WARN_ONs
to ensure ->set_config preconditions all apply.
v8: Fixup an embarrassing h/vdisplay mixup.
v9: Shuffled bad squash to the right patch, spotted by Daniel
v10: Use set_crtc_for_connector as suggested by Sean.
v11: Daniel Thompson noticed that my error handling is inconsistent
and that in a few cases I didn't handle fatal errors (i.e. not
-EDEADLK). Fix this by consolidate the ww mutex backoff handling
into one check in the fail: block and flatten the error control
flow everywhere else.
v12: Review and discussion with Sean:
- One spelling fix.
- Correctly skip the crtc from the set_config set when recomputing
->enable state. That should allow us to catch any bugs in higher
levels in computing that state (which is supplied to the
->set_config implementation). I've screwed this up and Sean spotted
that the current code is pointless.
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
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>
