Because of DP MST connectors can now be hotplugged and we must hold
the right lock when walking the connector lists. Enforce this by
checking the locking in our shiny new list walking macros.
v2: Extract the locking check into a small static inline helper to
help readability. This will be more important when we make the
read list access rules more complicated in later patches. Inspired by
comments from Chris. Unfortunately, due to header loops around the
definition of struct drm_device the function interface is a bit funny.
v3: Encoders aren't hotadded/removed. For each dp mst encoder we
statically create one fake encoder per pipe so that we can support as
many mst sinks as the hw can (Dave).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.
I didn't add an iterator for props since that's only used by a
list_for_each_entry_safe in the driver teardown code.
Search&replace was done with the below cocci spatch. Note that there's
a bunch more places that didn't match and which would need some manual
changes, but I've intentially left these out for this mostly automated
patch.
iterator name drm_for_each_crtc;
struct drm_crtc *crtc;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ drm_for_each_crtc (crtc, dev) {
...
}
@@
iterator name drm_for_each_encoder;
struct drm_encoder *encoder;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ drm_for_each_encoder (encoder, dev) {
...
}
@@
iterator name drm_for_each_fb;
struct drm_framebuffer *fb;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
+ drm_for_each_fb (fb, dev) {
...
}
@@
iterator name drm_for_each_connector;
struct drm_connector *connector;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ drm_for_each_connector (connector, dev) {
...
}
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
No need to pass the planelist when everyone just uses
dev->mode_config.plane_list anyway.
I want to add a pile more of iterators with unified (obj, dev)
arguments. This is just prep.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
I've only seen this once, and I failed to capture the
lockdep backtrace, but I did some investigations.
If we are calling into the MST layer from EDID probing,
we have the mode_config mutex held, if during that EDID
probing, the MST hub goes away, then we can get a deadlock
where the connector destruction function in the driver
tries to retake the mode config mutex.
This offloads connector destruction to a workqueue,
and avoid the subsequenct lock ordering issue.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Atomic modesetting: now with modesetting support.
v2: Moved drm_atomic_set_mode_prop_for_crtc from previous patch; removed
state->active fiddling, documented return code. Changed property
type to DRM_MODE_PROP_BLOB.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a blob property tracking the current mode to the CRTC state, and
ensure it is properly updated and referenced.
v2: Continue using crtc_state->mode inside getcrtc, instead of reading
out the mode blob. Use IS_ERR and PTR_ERR from create_blob. Move
set_mode_prop_for_crtc to later patch where it actually gets used.
Enforce !!state->enable == !!state->mode_blob inside
drm_atomic_crtc_check.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add an ioctl which allows users to create blob properties from supplied
data. Currently this only supports modes, creating a drm_display_mode from
the userspace drm_mode_modeinfo.
v2: Removed size/type checks.
Rebased on new patches to allow error propagation from create_blob,
as well as avoiding double-allocation.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Scattering of random drm core patches. Bunch of atomic prep work too, but
the final bits for blob properties, atomic modesets and lifting the
experimental tag on the atomic ioctl are still blocked on Daniel Stone
finalizing and testing the weston support for it. I hope that we can get
it all ready for 4.2 though.
* tag 'topic/drm-misc-2015-05-19' of git://anongit.freedesktop.org/drm-intel: (22 commits)
drm/atomic: Allow drivers to subclass drm_atomic_state, v3
drm/atomic: remove duplicated assignment of old_plane_state
drm/dp: Fix comment in DP helper
drm/atomic: add drm_atomic_get_existing_*_state helpers
drm/core: get rid of -Iinclude/drm
drm/i915: get rid of -Iinclude/drm
drm/atomic-helpers: Export drm_atomic_helper_update_legacy_modeset_state
drm/atomic-helpers: Update vblank timestamping constants
drm/sysfs: remove unnecessary connector type checks
drm/sysfs: split DVI-I and TV-out attributes
drm/sysfs: make optional attribute groups per connector type
drm/sysfs: add a helper for extracting connector type from kobject
drm/edid: Add CEA modes before inferred modes
drm/prime: Allow internal imports without import_sg_table
drm: Add reference counting to blob properties
drm: Introduce blob_lock
drm: Introduce helper for replacing blob properties
drm: Don't leak path blob property when updating
drm/atomic: Don't open-code CRTC state destroy
drm/edid: Add DMT modes with ID > 0x50
...
Drivers may need to store the state of shared resources, such as PLLs
or FIFO space, into the atomic state. Allow this by making it possible
to subclass drm_atomic_state.
Changes since v1:
- Change member names for functions to atomic_state_(alloc,clear)
- Change __drm_atomic_state_new to drm_atomic_state_init
- Allow free function to be overridden too, in case extra memory is
allocated in alloc.
Changes since v2:
- Rename *_default_free to default_release, to make clear it doesn't
free the state object itself.
Cc: dri-devel@lists.freedesktop.org
Acked-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reference-count drm_property_blob objects, changing the API to
ref/unref.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Squash in kerneldoc fixup from Daniel Stone.]
[danvet: Squash in Oops fix from Thiery Reding.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also treat it as a proper boolean.
Cc: Todd Previte <tprevite@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Create a new global blob_lock mutex, which protects the blob property
list from insertion and/or deletion.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.
Unfortunately, the DRM EDID reading and parsing functions are actually too good
in this case; the header is fixed before the checksum is computed and thus the
test never sees the invalid checksum. This results in a failure to pass the
compliance test.
To correct this issue, when the EDID code detects that the header is invalid,
a flag is set to indicate that the EDID is corrupted. In this case, it sets
edid_corrupt flag and continues with its fix-up code. This flag is also set in
the case of a more seriously damaged header (fixup score less than the
threshold). For consistency, the edid_corrupt flag is also set when the
checksum is invalid as well.
V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
- Maintained blank lines / spacing so as to not contaminate the patch
V6:
- Removed extra debug messages
- Added documentation to for the added parameter on drm_edid_block_valid
- Fixed more whitespace issues in check_link_status
- Added a clear of the header_corrupt flag to the end of the test handler
in intel_dp.c
- Changed the usage of the new function prototype in several places to use
NULL where it is not needed by compliance testing
V7:
- Updated to account for long_pulse flag propagation
V8:
- Removed clearing of header_corrupt flag from the test handler in intel_dp.c
- Added clearing of header_corrupt flag in the drm_edid_block_valid function
V9:
- Renamed header_corrupt flag to edid_corrupt to more accurately reflect its
value and purpose
- Updated commit message
V10:
- Updated for versioning and patch swizzle
- Revised the title to more accurately reflect the nature and contents of
the patch
- Fixed formatting/whitespace problems
- Added set flag when computed checksum is invalid
Signed-off-by: Todd Previte <tprevite@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm-intel-next-2015-04-23:
- dither support for ns2501 dvo (Thomas Richter)
- some polish for the gtt code and fixes to finally enable the cmd parser on hsw
- first pile of bxt stage 1 enabling (too many different people to list ...)
- more psr fixes from Rodrigo
- skl rotation support from Chandra
- more atomic work from Ander and Matt
- pile of cleanups and micro-ops for execlist from Chris
drm-intel-next-2015-04-10:
- cdclk handling cleanup and fixes from Ville
- more prep patches for olr removal from John Harrison
- gmbus pin naming rework from Jani (prep for bxt)
- remove ->new_config from Ander (more atomic conversion work)
- rps (boost) tuning and unification with byt/bsw from Chris
- cmd parser batch bool tuning from Chris
- gen8 dynamic pte allocation (Michel Thierry, based on work from Ben Widawsky)
- execlist tuning (not yet all of it) from Chris
- add drm_plane_from_index (Chandra)
- various small things all over
* tag 'drm-intel-next-2015-04-23-fixed' of git://anongit.freedesktop.org/drm-intel: (204 commits)
drm/i915/gtt: Allocate va range only if vma is not bound
drm/i915: Enable cmd parser to do secure batch promotion for aliasing ppgtt
drm/i915: fix intel_prepare_ddi
drm/i915: factor out ddi_get_encoder_port
drm/i915/hdmi: check port in ibx_infoframe_enabled
drm/i915/hdmi: fix vlv infoframe port check
drm/i915: Silence compiler warning in dvo
drm/i915: Update DRIVER_DATE to 20150423
drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010
rm/i915: Move i915_get_ggtt_vma_pages into ggtt_bind_vma
drm/i915: Don't try to outsmart gcc in i915_gem_gtt.c
drm/i915: Unduplicate i915_ggtt_unbind/bind_vma
drm/i915: Move ppgtt_bind/unbind around
drm/i915: move i915_gem_restore_gtt_mappings around
drm/i915: Fix up the vma aliasing ppgtt binding
drm/i915: Remove misleading comment around bind_to_vm
drm/i915: Don't use atomics for pg_dirty_rings
drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt
drm/i915/skl: Support Y tiling in MMIO flips
drm/i915: Fixup kerneldoc for struct intel_context
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
One more drm-misch pull for 4.1 with mostly simple stuff and boring
refactoring. Even the cursor fix from Matt is just to make a really anal
igt happy.
* tag 'topic/drm-misc-2015-04-15' of git://anongit.freedesktop.org/drm-intel:
drm: fix trivial typo mistake
drm: Make integer overflow checking cover universal cursor updates (v2)
drm: make crtc/encoder/connector/plane helper_private a const pointer
drm/armada: constify struct drm_encoder_helper_funcs pointer
drm/radeon: constify more struct drm_*_helper funcs pointers
drm/edid: add #defines for ELD versions
drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros
drm: Use kref_put_mutex in drm_gem_object_unreference_unlocked
drm/drm: constify all struct drm_*_helper funcs pointers
drm/qxl: constify all struct drm_*_helper funcs pointers
drm/nouveau: constify all struct drm_*_helper funcs pointers
drm/radeon: constify all struct drm_*_helper funcs pointers
drm/gma500: constify all struct drm_*_helper funcs pointers
drm/mgag200: constify all struct drm_*_helper funcs pointers
drm/exynos: constify all struct drm_*_helper funcs pointers
drm: Fix some typos
Separate topic branch for bxt didn't work out since we needed to
refactor the gmbus code a bit to make it look decent. So backmerge.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
They're only used to store const pointers anyway. This helps to keep
Ville and the compiler happy.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adding drm helper function to return plane pointer from index where
index is a returned by drm_plane_index.
v2:
-avoided nested loop by adding loop count (Daniel)
v3:
-updated patch header prefix to 'drm' (Matt)
v4:
-fixed a kerneldoc issue (kbuild-internal)
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This set of changes adds support for a whole bunch of new panels, mostly
simple ones. There's now also support for panels to provide display
timings rather than fixed modes, which should allow panels to work with
a larger number of display drivers. Eventually drivers should migrate to
this new interface and the fixed modes removed from panels.
There are also a couple of sparse fixes for the PS8622 and PS8625 bridge
drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVHXdzAAoJEN0jrNd/PrOhWKgQAJGdicIa3B8CLohgAfyMI+in
1PxO2vBGgz7T02iFTOzwh5cvh8E7mog9/R5jVCyan22BHdws75FgL6RVMcqbllds
c2ejPHhHlBEzOBtbZeEmvg1twmqKY5ejk1X7rtVHNCNaXVzSlpxYJF2jfK8DmhRF
l7UmjKIpyeDSL+33t+Q0jZynU2mwLfstr/4lwMPPKU6kzz15lIo0gPAnOlagbGD3
L5GOm1+LaDXpxojDtIElzzhzDf1DhmD4nIA3KRGAmKHRxA1u/vZUsW5UNaCvJB0v
eMVFdIk/aFfw4jizlAEute4sMKcXWNBMHmEr7e8Bakr+clie7BcXN9zeZ+B99t7A
+pkRbWNN8Isr4FpGNVz0XdU2BzmJAaQ59ghmZ5ZJtOmZwMWJbJsG7vMw0p2+68w6
bxhrEoT7hQDUicoKhcM6/8jDCqLZdqN0co16NHIL+0/BiUuS9Q1qr3Y7dBFbiU6D
iNKKeniODw8lA+Jv7wxVGbS2f5RvFeLvhgi4MgF78bEj8Mxf2EpB+mJT6WtEcX37
OMcg7xN7C6q2cu4Cpj7txF3gnKwB56lkJsX7xnyajtdHLDcw8Vx4CZprZCyA5gWP
FWpDLkT7l3Fi3jRDoVBw3WRa+rIfSFvLuVf3iLyVuFE5vR0tqJKutYDeaez0cMQM
nQqS1f2MYsKmNJf2DFhx
=0aBn
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.1-rc1
This set of changes adds support for a whole bunch of new panels, mostly
simple ones. There's now also support for panels to provide display
timings rather than fixed modes, which should allow panels to work with
a larger number of display drivers. Eventually drivers should migrate to
this new interface and the fixed modes removed from panels.
There are also a couple of sparse fixes for the PS8622 and PS8625 bridge
drivers.
* tag 'drm/panel/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: Add support for Ampire AM-800480R3TMQW-A1H 800x480 7" panel
of: Add vendor prefix for Ampire Co., Ltd.
drm/panel: Add display timing for HannStar HSD070PWW1
drm/panel: simple: Add display timing support
drm/panel: Add display timing support
drm/panel: Add support for OrtusTech COM43H4M85ULC panel
of: Add vendor prefix for Ortus Technology Co., Ltd.
drm/panel: Add bus format for Giantplus GPG482739QS5 panel
drm/panel: simple: Add support for AUO b101ean01 panel
drm/panel: simple: Add support for Innolux ZJ070NA-01P
drm/panel: simple: Add support for Innolux AT043TN24
drm/panel: simple: Add support for Shelly SCA07010-BFN-LNN
drm/panel: simple: Add support for Samsung LTN140AT29 panel
drm: Remove unused DRM_MODE_OBJECT_BRIDGE
drm/bridge: ptn3460: Fix sparse warnings
drm/bridge: ps8622: Fix sparse warnings
drm/bridge: Add I2C based driver for ps8622/ps8625 bridge
With bridges now moving to a separate registry they are no longer DRM
objects, hence this define is no longer needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Drivers implementing the universal planes API report the list of
supported pixel formats for the primary plane. Make sure the fb passed
to the setcrtc ioctl is compatible.
Drivers not implementing the universal planes API will have no format
reported for the primary plane, skip the check in that case.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both the legacy and atomic helpers need to check whether a plane
supports a given pixel format. The code is currently duplicated, share
it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[danvet: Slightly extend the docbook.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- use the atomic helpers for plane_upate/disable hooks (Matt Roper)
- refactor the initial plane config code (Damien)
- ppgtt prep patches for dynamic pagetable alloc (Ben Widawsky, reworked and
rebased by a lot of other people)
- framebuffer modifier support from Tvrtko Ursulin, drm core code from Rob Clark
- piles of workaround patches for skl from Damien and Nick Hoath
- vGPU support for xengt on the client side (Yu Zhang)
- and the usual smaller things all over
* tag 'drm-intel-next-2015-02-14' of git://anongit.freedesktop.org/drm-intel: (88 commits)
drm/i915: Update DRIVER_DATE to 20150214
drm/i915: Remove references to previously removed UMS config option
drm/i915/skl: Use a LRI for WaDisableDgMirrorFixInHalfSliceChicken5
drm/i915/skl: Fix always true comparison in a revision id check
drm/i915/skl: Implement WaEnableLbsSlaRetryTimerDecrement
drm/i915/skl: Implement WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
drm/i915: Add process identifier to requests
drm/i915/skl: Implement WaBarrierPerformanceFixDisable
drm/i915/skl: Implement WaCcsTlbPrefetchDisable:skl
drm/i915/skl: Implement WaDisableChickenBitTSGBarrierAckForFFSliceCS
drm/i915/skl: Implement WaDisableHDCInvalidation
drm/i915/skl: Implement WaDisableLSQCROPERFforOCL
drm/i915/skl: Implement WaDisablePartialResolveInVc
drm/i915/skl: Introduce a SKL specific init_workarounds()
drm/i915/skl: Document that we implement WaRsClearFWBitsAtReset
drm/i915/skl: Implement WaSetGAPSunitClckGateDisable
drm/i915/skl: Make the init clock gating function skylake specific
drm/i915/skl: Provide a gen9 specific init_render_ring()
drm/i915/skl: Document the WM read latency W/A with its name
drm/i915/skl: Also detect eDRAM on SKL
...
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.
The proposal is to add a per-plane format modifier. This allows to, if
necessary, use different tiling patters for sub-sampled planes, etc.
The format modifiers are added at the end of the ioctl struct, so for
legacy userspace it will be zero padded.
v1: original
v1.5: increase modifier to 64b
v2: Incorporate review comments from the big thread, plus a few more.
- Add a getcap so that userspace doesn't have to jump through hoops.
- Allow modifiers only when a flag is set. That way drivers know when
they're dealing with old userspace and need to fish out e.g. tiling
from other information.
- After rolling out checks for ->modifier to all drivers I've decided
that this is way too fragile and needs an explicit opt-in flag. So
do that instead.
- Add a define (just for documentation really) for the "NONE"
modifier. Imo we don't need to add mask #defines since drivers
really should only do exact matches against values defined with
fourcc_mod_code.
- Drop the Samsung tiling modifier on Rob's request since he's not yet
sure whether that one is accurate.
v3:
- Also add a new ->modifier[] array to struct drm_framebuffer and fill
it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin.
- Remove TODO in comment and add code comment that modifiers should be
properly documented, requested by Rob.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Rob Clark <robdclark@gmail.com> (v1.5)
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling "drm_bridge_add".
The parent encoder driver waits till the bridge is available
in the lookup table(by calling "of_drm_find_bridge") and then
continues with its initialization.
The encoder driver should also call "drm_bridge_attach" to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls "bridge->funcs->attach" so that
bridge can continue with drm related initializations.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Assign the pointer to bridge ops structure(drm_bridge_funcs) in
the bridge driver itself, instead of passing it to drm_bridge_init.
This will allow bridge driver developer to pack bridge private
information inside the bridge object and pass only the drm-relevant
information to drm_bridge_init.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since implementing a full queue of async atomic updates is a bit
of work lets just recover the cursor specific behaviour with a hint
flag and some hacks to drop the vblank wait.
v2: Fix kerneldoc, reported by Wu Fengguang.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This is the infrastructure for DPMS ported to the atomic world.
Fundamental changes compare to legacy DPMS are:
- No more per-connector dpms state, instead there's just one per each
display pipeline. So if you clone either you have to unclone first
if you only want to switch off one screen, or you just switch of
everything (like all desktops do). This massively reduces complexity
for cloning since now there's no more half-enabled cloned configs to
consider.
- Only on/off, dpms standby/suspend are as dead as real CRTs. Again
reduces complexity a lot.
Now especially for backwards compat the really important part for dpms
support is that dpms on always succeeds (except for hw death and
unplugged cables ofc). Which means everything that could fail (like
configuration checking, resources assignments and buffer management)
must be done irrespective from ->active. ->active is really only a
toggle to change the hardware state. More precisely:
- Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
Changes to ->active MUST always suceed if nothing else changes.
- Drivers using the atomic helpers MUST NOT look at ->active anywhere,
period. The helpers will take care of calling the respective
enable/modeset/disable hooks as necessary. As before the helpers
will carefully keep track of the state and not call any hooks
unecessarily, so still no double-disables or enables like with crtc
helpers.
- ->mode_set hooks are only called when the mode or output
configuration changes, not for changes in ->active state.
- Drivers which reconstruct the state objects in their ->reset hooks
or through some other hw state readout infrastructure must ensure
that ->active reflects actual hw state.
This just implements the core bits and helper logic, a subsequent
patch will implement the helper code to implement legacy dpms with
this.
v2: Rebase on top of the drm ioctl work:
- Move crtc checks to the core check function.
- Also check for ->active_changed when deciding whether a modeset
might happen (for the ALLOW_MODESET mode).
- Expose the ->active state with an atomic prop.
v3: Review from Rob
- Spelling fix in comment.
- Extract needs_modeset helper to consolidate the ->mode_changed ||
->active_changed checks.
v4: Fixup fumble between crtc->state and crtc_state.
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Not a new type exposed to userspace, just a standard way to create
them since between range, bitmask and enum there's 3 different ways to
pull out a boolean prop.
Also add the kerneldoc for the recently added new prop types, which
Rob forgot all about.
v2: Fixup kerneldoc, spotted by Rob.
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The rotation property is shared by multiple drivers, so it makes sense
to store the rotation value (for atomic-converted drivers) in the common
plane state so that core code can eventually access it as well.
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just flushing out my drm-misc branch, nothing major. Well too old patches
I've dug out from years since a patch from Rob look eerily familiar ;-)
* tag 'topic/core-stuff-2015-01-23' of git://anongit.freedesktop.org/drm-intel:
drm/probe-helper: clamp unknown connector status in the poll work
drm/probe-helper: don't lose hotplug event
next: drm/atomic: Use copy_from_user to copy 64 bit data from user space
drm: Make drm_read() more robust against multithreaded races
drm/fb-helper: Propagate errors from initial config failure
drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).
To avoid this, check whether the connector state changes in all other
->detect calls (in the current helper code that's only probe_single)
and if that's the case, fire off a hotplug event. Note that we can't
directly call the hotplug event handler, since that expects that no
locks are held (due to reentrancy with the fb code to update the kms
console).
Also, this requires that drivers using the probe_single helper
function set up the poll work. All current drivers do that already,
and with the reworked hpd handling there'll be no downside to
unconditionally setting up the poll work any more.
v2: Review from Rob Clark
- Don't bail out of the output poll work immediately if it's disabled
to make sure we deliver the delayed hoptplug events. Instead just
jump to the tail.
- Don't scheduel the work when it's not set up. Would be a driver bug
since using probe helpers for anything dynamic without them
initialized makes them all noops.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.
This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Thierry Reding <treding@nvidia.com>
- plane handling refactoring from Matt Roper and Gustavo Padovan in prep for
atomic updates
- fixes and more patches for the seqno to request transformation from John
- docbook for fbc from Rodrigo
- prep work for dual-link dsi from Gaurav Signh
- crc fixes from Ville
- special ggtt views infrastructure from Tvrtko Ursulin
- shadow patch copying for the cmd parser from Brad Volkin
- execlist and full ppgtt by default on gen8, for testing for now
* tag 'drm-intel-next-2014-12-19' of git://anongit.freedesktop.org/drm-intel: (131 commits)
drm/i915: Update DRIVER_DATE to 20141219
drm/i915: Hold runtime PM during plane commit
drm/i915: Organize bind_vma funcs
drm/i915: Organize INSTDONE report for future.
drm/i915: Organize PDP regs report for future.
drm/i915: Organize PPGTT init
drm/i915: Organize Fence registers for future enablement.
drm/i915: tame the chattermouth (v2)
drm/i915: Warn about missing context state workarounds only once
drm/i915: Use true PPGTT in Gen8+ when execlists are enabled
drm/i915: Skip gunit save/restore for cherryview
drm/i915/chv: Use timeout mode for RC6 on chv
drm/i915: Add GPGPU_THREADS_DISPATCHED to the register whitelist
drm/i915: Tidy up execbuffer command parsing code
drm/i915: Mark shadow batch buffers as purgeable
drm/i915: Use batch length instead of object size in command parser
drm/i915: Use batch pools with the command parser
drm/i915: Implement a framework for batch buffer pools
drm/i915: fix use after free during eDP encoder destroying
drm/i915/skl: Skylake also supports DP MST
...
Next batch of atomic work. Most important is the propertification from Rob
and the nth iteration of the actual atomic ioctl originally from Ville.
Big differences compared to earlier revisions:
- Core properties are now fully handled by the core, drivers can only
handle driver-specific properties.
- Atomic props&ioctl are opt-in per file_priv, userspace needs to
explicitly ask for it (like universal plane support).
- For now all hidden behind the atomic module option until this has
settled a bit.
- Atomic modesets are currently not possible since the exact abi for how
to handle the mode property is still under discussion.
Besides this some cleanup patches from me and the addition of per-object
state to global state backpointers to simplify drivers.
* tag 'topic/atomic-core-2015-01-05' of git://anongit.freedesktop.org/drm-intel:
drm: Ensure universal_planes is set for atomic
drm/atomic: Hide drm.ko internal interfaces
drm: Atomic modeset ioctl
drm/atomic: atomic connector properties
drm/atomic: atomic plane properties
drm: small property creation cleanup
drm/atomic: atomic_check functions
drm: add atomic properties
drm: refactor getproperties/getconnector
drm: tweak getconnector locking
drm: add atomic_get_property
drm: add atomic_set_property wrappers
drm: get rid of direct property value access
drm: store property instead of id in obj attachment
drm: allow property validation for refcnted props
drm/atomic: Introduce state->obj backpointers
drm/atomic-helper: Again check modeset *before* plane states
drm/atomic-helper: Export both plane and modeset check helpers
Misc drm patches with mostly polish patches from Thierry, with a bit of
generic mode validation from Ville and a few other oddball things.
* tag 'topic/core-stuff-2014-12-19' of git://anongit.freedesktop.org/drm-intel: (25 commits)
drm: Include drm_crtc_helper.h in DocBook
drm: Make drm_crtc_helper.h standalone includible
drm: Move IRQ related fields to proper section
drm: Remove stale comment
drm: Do basic sanity checks for user modes
drm: Perform basic sanity checks on probed modes
drm: Reorganize probed mode validation
drm/doc: Remove duplicate "by"
drm/info: Remove unused code
drm/cache: Use wbinvd helpers
drm/plane-helper: Test for plane disable earlier
drm/doc: Document drm_add_modes_noedid() usage
drm: bit of spell-check / editorializing.
drm: Prefer sizeof(type) over sizeof type
drm: Remove useless else block
drm: Remove unneeded braces for single statement blocks
drm: Do not assign in if condition
drm: Prefer kmalloc_array() over kmalloc() with multiply
drm: Prefer kcalloc() over kzalloc() with multiply
drm: Miscellaneous checkpatch whitespace cleanups
...
The atomic modeset ioctl can be used to push any number of new values
for object properties. The driver can then check the full device
configuration as single unit, and try to apply the changes atomically.
The ioctl simply takes a list of object IDs and property IDs and their
values.
Originally based on a patch from Ville Syrjälä, although it has mutated
(mutilated?) enough since then that you probably shouldn't blame it on
him ;-)
The atomic support is hidden behind the DRM_CLIENT_CAP_ATOMIC cap (to
protect legacy userspace) and drm.atomic module param (for now).
v2: Check for file_priv->atomic to make sure we only allow userspace
in-the-know to use atomic.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Expose the core plane state as properties, so they can be updated via
atomic ioctl.
v2: atomic property flag
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Once a driver is using atomic helpers for modeset, the next step is to
switch over to atomic properties. To do this, make sure that any
modeset objects have their ->atomic_{get,set}_property() vfuncs suitably
populated if they have custom properties (you did already remember to
plug in atomic-helper func for the legacy ->set_property() vfuncs,
right?), and then set DRIVER_ATOMIC bit in driver_features flag.
A new cap is introduced, DRM_CLIENT_CAP_ATOMIC, for the purposes of
shielding legacy userspace from atomic properties. Mostly for the
benefit of legacy DDX drivers that do silly things like getting/setting
each property at startup (since some of the new atomic properties will
be able to trigger modeset).
Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet: Squash in fixup patch to check for DRM_MODE_PROP_ATOMIC
instaed of the CAP define when filtering properties. Reported by
Tvrtko Uruslin, acked by Rob.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we won't be using the obj->properties->values[] array to shadow
property values for atomic drivers, we are going to need a vfunc for
getting prop values. Add that along w/ mandatory wrapper fxns.
v2: more comments and copypasta comment typo fix
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we add properties for all the standard plane/crtc/connector
attributes (in preperation for the atomic ioctl), we are going to want
to handle core state in core (rather than per driver). Intercepting the
core properties will be easier if the atomic_set_property vfuncs are not
called directly, but instead have a mandatory wrapper function (which
will later serve as the point to intercept core properties).
v2: more verbose comments and copypasta comment fix
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For atomic drivers, we won't use the values array but instead shunt
things off to obj->atomic_get_property(). So to simplify things make
all read/write of properties values go through the accessors.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Keep property pointer, instead of id, in per mode-object attachments.
This will simplify things in later patches.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Useful since this way we can pass around just the state objects and
will get ther real object, too.
Specifically this allows us to again simplify the parameters for
set_crtc_for_plane.
v2: msm already has it's own specific plane_reset hook, don't forget
that one!
v3: Fixup kerneldoc, reported by 0-day builder.
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com> (v2)
Tested-by: Rob Clark <robdclark@gmail.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The default call sequence for these two parts won't fit for all
drivers. So export the two pieces and explain with a bit of kerneldoc
when each should be called.
v2: Squash in fixup from Rob to actually add the newly exported
functions to headers
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The struct drm_connector_funcs kerneldoc refers to a part of struct
drm_crtc_funcs that no longer exists.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
