commit 95c081c17f284de50eaca60d4d55643a64d39019
Author: Daniel Vetter <email address hidden>
Date: Tue Jun 21 10:54:12 2016 +0200
drm: Move master pointer from drm_minor to drm_device
Noticed by Chris Wilson.
Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
Cc: Chris Wilson <email address hidden>
Cc: Chris Wilson <email address hidden>
Cc: Daniel Vetter <email address hidden>
Cc: Emil Velikov <email address hidden>
Cc: Julia Lawall <email address hidden>
Signed-off-by: Daniel Vetter <email address hidden>
drm/color: document NULL values and default settings better
Brought up in a discussion for enabling gamma on fsl-dcu.
Cc: Ville Syrjälä <email address hidden>
Cc: Meng Yi <email address hidden>
Cc: Lionel Landwerlin <email address hidden>
Signed-off-by: Daniel Vetter <email address hidden>
fc711c9...
by
=?utf-8?b?VmlsbGUgU3lyasOkbMOk?= <email address hidden>
WIP/drm/i915: Handle CCS AUX surface on SKL for render decompression
This is a squash from Ville's patch + Vandana's + adaption to use the
fb_modifier stuff like it was intended, i.e. enable the use of the CCS
with the aux-plane+modifier, and not with a separate, intel-private
property.
Totally not tested except for it seems to compile.
drm/i915: Render decompression support for Gen9 and above
This patch includes enabling render decompression (RC) after checking
all the requirements (format, tiling, rotation etc.).
TODO:
1. Disable stereo 3D when render decomp is enabled (bit 7:6)
2. Render decompression must not be used in VTd pass-through mode
3. Program hashing select CHICKEN_MISC1 bit 15
4. For Gen10, add support for RGB 1010102
5. RC-FBC workaround
6. RC watermark calculation
The reason for using a plane property instead of fb modifier:-
In Android, OGL passes a render compressed buffer to hardware composer
(HWC), which would then request a flip on that buffer after checking if
the target can support render compressed buffer. For example, only planes
1 and 2 on pipes 1 and 2 can support RC. In case the target cannot
support it, HWC will revert back to OGL requesting for uncompressed
buffer.
Here,
if plane property is used, OGL would send back the buffer (same ID) after
decompression, marked uncompressed. If fb modifier was used, a different
version of the buffer would have to be maintained for different
combinations - in the simple case of render compressed vs uncompressed
buffer, there would be 2 fbs with 2 IDs. So, in this case, OGL would give
a reference to a fb with a different ID.
To avoid the difficulty of keeping track of multiple fbs and the subsequent
complexity in debug, the architecture forum decided to go ahead with a
plane property for RC.
[Mayuresh] Added the plane check in skl_check_compression()
v2: Ville's review comments addressed
- Removed WAs specific to SKL-C and BXT-A
- Assign capabilities according to pipe and plane during property creation
- in skl_check_compression(), check for conditions that must be satisifed
Maintaining the check for pixel format, even though compressed fb of format
other RGB8888 should not have been created, to be on the safer side.
Added checks for BGR8888 too.
Bitmask is being used for the property to accommodate 2 more options
expected to be added in future.
v3: This patch has been implemented on top of Ville's patch series on
fb->offsets.
(Ref: git://github.com/vsyrjala/linux.git fb_offsets_15)
- Userspace is expected to pass aux offset through fb->offsets[1].
Testing is in progress for v3 of the patch.
Signed-off-by: Vandana Kannan <email address hidden>
Cc: Ville Syrjälä <email address hidden>
Cc: Smith, Gary K <email address hidden>
For render compression, userspace passes aux stride and offset values as an
additional entry in the fb structure. This should not be treated as garbage
and discarded as data belonging to no plane.
This patch introduces a check related to AUX plane to support the
scenario of render compression.
v2: Based on a discussion with Siva
Move num_planes check below the increment.
v3: s/render compression/aux plane/ in all comments
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus points for implementing abstraction, and then storing the vfunc
in a global variable.
v2: Don't break the build soooo badly :(
Note that the cleanup function is a bit confused: ade_data was never
set as drvdata, and calling drm_crtc_cleanup directly is a bug - this
is called indirectly through drm_mode_config_cleanup, which calls into
crtc->destroy, which already has the call to drm_crtc_cleanup. Which
means we can just nuke it.
Note this is the 2nd attempt after the first one failed and had to be
reverted again in
commit 9cd2e854d61ccfa51686f3ed7b0c917708fc641f
Author: Daniel Vetter <email address hidden>
Date: Wed Aug 17 13:59:40 2016 +0200
Revert "drm/hisilicon: Don't set drm_device->platformdev"
Cc: Xinliang Liu <email address hidden>
Cc: Xinwei Kong <email address hidden>
Cc: Archit Taneja <email address hidden>
Cc: Sean Paul <email address hidden>
Signed-off-by: Daniel Vetter <email address hidden>
This reverts commit 29310a50752de76314f51555b72044d11f6cba49.
Even with Markus fixes to the importer I still get warnigns from
sphinx which are entirely bogus :(
/home/daniel/linux/src/Documentation/gpu/drm-kms.rst:13: WARNING: Could not lex literal_block as "C". Highlighting skipped.
/home/daniel/linux/src/Documentation/gpu/drm-kms-helpers.rst:16: WARNING: Could not lex literal_block as "C". Highlighting skipped.
/home/daniel/linux/src/Documentation/gpu/i915.rst:57: WARNING: Could not lex literal_block as "C". Highlighting skipped.
Well it's worse: Those are warnings which don't even show up with this
enabled. Just sending this out again in the hopes some has a clue
what's going on.
Cc: Jani Nikula <email address hidden>
Cc: Markus Heiser <email address hidden>
Cc: Jonathan Corbet <email address hidden>
Signed-off-by: Daniel Vetter <email address hidden>
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied from Maarten's patch, but with the slight change to
just use dev->mode_config.funcs->atomic_commit to decide whether to
use the atomic path or not.
FIXME: This seems to break audio rpm refcounting somehow! See:
drm: Don't compute obj counts expensively in get_resources
Looping when we keep track of this is silly. Only thing we have to
be careful is with sampling the connector count. To avoid inconsisten
results due to gcc re-computing this, use READ_ONCE.
And to avoid surprising userspace, make sure we don't copy more
connectors than planned, and report the actual number of connectors
copied. That way any racing hot-add/remove will be handled.
v2: Actually try to not blow up, somehow I lost the hunk that checks
we don't copy too much. Noticed by Chris.
Cc: Chris Wilson <email address hidden>
Signed-off-by: Daniel Vetter <email address hidden>
Somehow this escaped us, this is a KMS ioctl which should only be used
by the master (which is the thing that's also in control of kms
resources). Everything else is bound to result in fail.
Clients shouldn't have a trouble coping with this, since a pile of
drivers don't support vblank waits (or just randomly fall over when
using them). Note that the big motivation for abusing this like mad
seems to be that EGL doesn't have OML_sync, but somehow it didn't
cross anyone's mind that adding OML_sync to EGL would be useful. This
patch is meant to essentially start kicking that can from the back
end.
v2: Drop accidental hunk (Michel).
Cc: Michel Dänzer <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Signed-off-by: Daniel Vetter <email address hidden>
