summaryrefslogtreecommitdiffstats
path: root/include/uapi/drm
Commit message (Collapse)AuthorAgeFilesLines
...
* | | Merge drm/drm-next into drm-intel-next-queuedJoonas Lahtinen2019-03-271-7/+29
|\| | | | | | | | | | | | | | | | | This is needed to get the fourcc code merged without conflicts. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| * | drm/fourcc: Fix conflicting Y41x definitionsMaarten Lankhorst2019-03-211-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There has unfortunately been a conflict with the following 3 commits: commit e9961ab95af81b8d29054361cd5f0c575102cf87 Author: Ayan Kumar Halder <ayan.halder@arm.com> Date: Fri Nov 9 17:21:12 2018 +0000 drm: Added a new format DRM_FORMAT_XVYU2101010 commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3 Author: Brian Starkey <brian.starkey@arm.com> Date: Fri Oct 5 10:27:00 2018 +0100 drm/fourcc: Add AFBC yuv fourccs for Mali and commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b Author: Swati Sharma <swati2.sharma@intel.com> Date: Mon Mar 4 17:26:33 2019 +0530 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc Unfortunately gcc didn't warn about the redefinitions, because the double defines were the set to same value, and gcc apparently no longer warns about that. Fix this by using new XYVU for i915, without alpha, and making the Y41x definitions match msdn, with alpha. Fortunately we caught it early, and the conflict hasn't even landed in drm-next yet. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: malidp@foss.arm.com Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Dave Airlie <airlied@linux.ie> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190319121702.6814-1-maarten.lankhorst@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc Acked-by: Sean Paul <sean@poorly.run> Reviewed-by: Ayan Kumar halder <ayan.halder@arm.com>
| * | Merge tag 'topic/hdr-formats-2019-03-13' of ↵Sean Paul2019-03-131-0/+11
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-misc-next Add support for floating point half-width formats. Signed-off-by: Sean Paul <seanpaul@chromium.org> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/00b96cd5-91c7-5677-9620-b138c7a92303@linux.intel.com
| * | | drm: Added a new format DRM_FORMAT_XVYU2101010Ayan Kumar Halder2019-03-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This new format is supported by DP550 and DP650 Changes since v3 (series): - Added the ack - Rebased on the latest drm-misc-next Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Link: https://patchwork.freedesktop.org/patch/291758/?series=57895&rev=1
| * | | drm/fourcc: Add AFBC yuv fourccs for MaliBrian Starkey2019-03-121-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR8888 and RGBA8888 can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA8888 + MODIFIER_AFBC) is a different format from (RGBA8888 + MODIFIER_AFBC). Possibly more controversial is that (XBGR8888 + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane ---------------------- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane ----------------------- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane ---------------------- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by V). We can use YUYV for AFBC YUV 422 8-bit. YUV 422 10-bit, 1-plane ----------------------- There is no currently-defined YUV 422 10-bit format in drm_fourcc.h DRM_FORMAT_Y210 is analogous to YUYV, but with 10-bits per sample packed into the upper 10-bits of 16-bit samples. This format is supported in both linear and AFBC by Mali GPUs. YUV 422 10-bit, 2-plane ----------------------- The recently defined DRM_FORMAT_P010 format is a 10-bit semi-planar YUV 420 format, which has the correct component ordering for an AFBC 2-plane YUV 420 buffer. The linear layout contains meaningless padding bits, which will not be encoded in an AFBC stream. YUV 420 8-bit, 1-plane ---------------------- There is no currently defined single-planar YUV 420, 8-bit format in drm_fourcc.h. There's differing opinions on whether using the existing fourcc-implied n_planes where possible is a good idea or not when using modifiers. For me, it's much more "obvious" to use NV12 for 2-plane AFBC and YUV420 for 3-plane AFBC. This keeps the aforementioned separation between the AFBC codec settings (in the modifier) and the pixel data format (in the fourcc). With different vendors using AFBC, this helps to ensure that there is no confusion in interoperation. It also ensures that the AFBC modifiers describe AFBC itself (which is a licensable component), and not implementation details which are not defined by AFBC. The proposed[1] X0L0 format which Mali-DP supports with Linear layout is unsuitable, as it contains a 4th 'X' component, and our AFBC decoder expects only 3 components. To that end, we propose a new YUV 420 8-bit format. There is no "obvious" linear encoding for a 3-component 8:8:8, 420, packed format, and so DRM_FORMAT_YUV420_8BIT defines a component order, but not a bit encoding. I'm happy to hear different naming suggestions. YUV 420 8-bit, 2-, 3-plane -------------------------- These already exist, we can use NV12 and YUV420. YUV 420 10-bit, 1-plane ----------------------- As above, no current definition exists, and X0L2 encodes a 4th 'X' channel. Analogous to DRM_FORMAT_YUV420_8BIT, we define DRM_FORMAT_YUV420_10BIT. [1] https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html [2] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats Changes since RFC v1: - Fix confusing subsampling vs bit-depth X:X:X notation in descriptions (danvet) - Rename DRM_FORMAT_AVYU1101010 to DRM_FORMAT_Y410 (Lisa Wu) - Add drm_format_info structures for the new formats, using the new 'bpp' field for those with non-integer bytes-per-pixel - Rebase, including Juha-Pekka Heikkila's format definitions Changes since RFC v2: - Rebase on top of latest changes in drm-misc-next - Change the description of DRM_FORMAT_P210 in __drm_format_info and drm_fourcc.h so as to make it consistent with other DRM_FORMAT_PXXX formats. Changes since v3: - Added the ack - Rebased on the latest drm-misc-next Signed-off-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Link: https://patchwork.freedesktop.org/patch/291759/?series=57895&rev=1
* | | | drm/i915: Drop new chunks of context creation ABI (for now)Chris Wilson2019-03-271-17/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The intent was to expose these as part of the means to perform full context recovery (though not the SINGLE_TIMELINE, that is for later and just sucked as collateral damage). As that requires a couple more patches to complete the series, roll back the earlier chunks of ABI for an intervening PR. We keep all the internals intact and under selftests. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190327105814.14694-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
* | | | drm/i915: Allow contexts to share a single timeline across all enginesChris Wilson2019-03-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, our view has been always to run the engines independently within a context. (Multiple engines happened before we had contexts and timelines, so they always operated independently and that behaviour persisted into contexts.) However, at the user level the context often represents a single timeline (e.g. GL contexts) and userspace must ensure that the individual engines are serialised to present that ordering to the client (or forgot about this detail entirely and hope no one notices - a fair ploy if the client can only directly control one engine themselves ;) In the next patch, we will want to construct a set of engines that operate as one, that have a single timeline interwoven between them, to present a single virtual engine to the user. (They submit to the virtual engine, then we decide which engine to execute on based.) To that end, we want to be able to create contexts which have a single timeline (fence context) shared between all engines, rather than multiple timelines. v2: Move the specialised timeline ordering to its own function. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322092325.5883-4-chris@chris-wilson.co.uk
* | | | drm/i915: Extend CONTEXT_CREATE to set parameters upon constructionChris Wilson2019-03-221-82/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It can be useful to have a single ioctl to create a context with all the initial parameters instead of a series of create + setparam + setparam ioctls. This extension to create context allows any of the parameters to be passed in as a linked list to be applied to the newly constructed context. v2: Make a local copy of user setparam (Tvrtko) v3: Use flags to detect availability of extension interface Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322092325.5883-3-chris@chris-wilson.co.uk
* | | | drm/i915: Create/destroy VM (ppGTT) for use with contextsChris Wilson2019-03-221-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation to making the ppGTT binding for a context explicit (to facilitate reusing the same ppGTT between different contexts), allow the user to create and destroy named ppGTT. v2: Replace global barrier for swapping over the ppgtt and tlbs with a local context barrier (Tvrtko) v3: serialise with struct_mutex; it's lazy but required dammit v4: Rewrite igt_ctx_shared_exec to be more different (aimed to be more similarly, turned out different!) v5: Fix up test unwind for aliasing-ppgtt (snb) v6: Tighten language for uapi struct drm_i915_gem_vm_control. v7: Patch the context image for runtime ppgtt switching! Testcase: igt/gem_vm_create Testcase: igt/gem_ctx_param/vm Testcase: igt/gem_ctx_clone/vm Testcase: igt/gem_ctx_shared Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322092325.5883-2-chris@chris-wilson.co.uk
* | | | drm/i915: Introduce the i915_user_extension_methodChris Wilson2019-03-221-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An idea for extending uABI inspired by Vulkan's extension chains. Instead of expanding the data struct for each ioctl every time we need to add a new feature, define an extension chain instead. As we add optional interfaces to control the ioctl, we define a new extension struct that can be linked into the ioctl data only when required by the user. The key advantage being able to ignore large control structs for optional interfaces/extensions, while being able to process them in a consistent manner. In comparison to other extensible ioctls, the key difference is the use of a linked chain of extension structs vs an array of tagged pointers. For example, struct drm_amdgpu_cs_chunk { __u32 chunk_id; __u32 length_dw; __u64 chunk_data; }; struct drm_amdgpu_cs_in { __u32 ctx_id; __u32 bo_list_handle; __u32 num_chunks; __u32 _pad; __u64 chunks; }; allows userspace to pass in array of pointers to extension structs, but must therefore keep constructing that array along side the command stream. In dynamic situations like that, a linked list is preferred and does not similar from extra cache line misses as the extension structs themselves must still be loaded separate to the chunks array. v2: Apply the tail call optimisation directly to nip the worry of stack overflow in the bud. v3: Defend against recursion. v4: Fixup local types to match new uabi Opens: - do we include the result as an out-field in each chain? struct i915_user_extension { __u64 next_extension; __u64 name; __s32 result; __u32 mbz; /* reserved for future use */ }; * Undecided, so provision some room for future expansion. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322092325.5883-1-chris@chris-wilson.co.uk
* | | | Merge tag 'topic/hdr-formats-2019-03-13' of ↵Joonas Lahtinen2019-03-181-0/+11
|\ \ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-intel-next-queued Add support for floating point half-width formats. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/00b96cd5-91c7-5677-9620-b138c7a92303@linux.intel.com
| * | | drm/fourcc: Add 64 bpp half float formatsKevin Strasser2019-03-131-0/+11
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is formatted in IEEE-754 half-precision float (binary16) 1:5:10 MSb-sign:exponent:fraction form. This patch attempts to address the feedback provided when 2 of these formats were previosly proposed: https://patchwork.kernel.org/patch/10072545/ v2: - Fixed cpp (Ville) - Added detail pixel formatting (Ville) - Ordered formats in header (Ville) v5: - .depth should be 0 for new formats (Maarten) Cc: Tina Zhang <tina.zhang@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kevin Strasser <kevin.strasser@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-2-git-send-email-kevin.strasser@intel.com
* | | Merge tag 'topic/hdr-formats-2019-03-07' of ↵Joonas Lahtinen2019-03-111-0/+16
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-intel-next-queued Add support for Y21x and Y41x to drm core and i915, and P01x support to i915. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2485309-d645-bed4-95f4-e66ff312aa05@linux.intel.com
| * | drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourccSwati Sharma2019-03-051-0/+16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following pixel formats are packed format that follows 4:2:2 chroma sampling. For memory represenation each component is allocated 16 bits each. Thus each pixel occupies 32bit. Y210: For each component, valid data occupies MSB 10 bits. LSB 6 bits are filled with zeroes. Y212: For each component, valid data occupies MSB 12 bits. LSB 4 bits are filled with zeroes. Y216: For each component valid data occupies 16 bits, doesn't require any padding bits. First 16 bits stores the Y value and the next 16 bits stores one of the chroma samples alternatively. The first luma sample will be accompanied by first U sample and second luma sample is accompanied by the first V sample. The following pixel formats are packed format that follows 4:4:4 chroma sampling. Channels are arranged in the order UYVA in increasing memory order. Y410: Each color component occupies 10 bits and X component takes 2 bits, thus each pixel occupies 32 bits. Y412: Each color component is 16 bits where valid data occupies MSB 12 bits. LSB 4 bits are filled with zeroes. Thus, each pixel occupies 64 bits. Y416: Each color component occupies 16 bits for valid data, doesn't require any padding bits. Thus, each pixel occupies 64 bits. v3: fixed missing tab for XYUV8888 (JP) Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1551700595-21481-5-git-send-email-swati2.sharma@intel.com
* | Merge drm/drm-next into drm-intel-next-queuedJoonas Lahtinen2019-03-111-1/+2
|\| | | | | | | | | | | To facilitate merging topic/hdr-formats from Maarten. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| * Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2019-02-221-1/+2
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Fixes for 5.1: amdgpu: - Fix missing fw declaration after dropping old CI DPM code - Fix debugfs access to registers beyond the MMIO bar size - Fix context priority handling - Add missing license on some new files - Various cleanups and bug fixes radeon: - Fix missing break in CS parser for evergreen - Various cleanups and bug fixes sched: - Fix entities with 0 run queues Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221214134.3308-1-alexander.deucher@amd.com
| | * drm/amdgpu: Add command to override the context priority.Bas Nieuwenhuizen2019-02-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given a master fd we can then override the priority of the context in another fd. Using these overrides was recommended by Christian instead of trying to submit from a master fd, and I am adding a way to override a single context instead of the entire process so we can only upgrade a single Vulkan queue and not effectively the entire process. Reused the flags field as it was checked to be 0 anyways, so nothing used it. This is source-incompatible (due to the name change), but ABI compatible. Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/i915: Remove last traces of exec-id (GEM_BUSY)Chris Wilson2019-03-051-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we allow per-context engine allows the legacy concept of I915_EXEC_RING no longer applies universally. We are still exposing the unrelated exec-id in GEM_BUSY, so transition this ioctl (once more slightly changing its ABI, but no one cares) over to only reporting the uabi-class (not instance as we can not foreseeably fit those into the small bitmask). The only user of the extended ring information from GEM_BUSY is ddx/sna, which tries to use the non-rcs business information to guide which engine to use for subsequent operations on foreign bo. All that matters for it is the decision between rcs and !rcs, so it is unaffected by the change in higher bits. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190305162643.20243-1-chris@chris-wilson.co.uk
* | | drm/i915: Fix I915_EXEC_RING_MASKChris Wilson2019-03-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was supposed to be a mask of all known rings, but it is being used by execbuffer to filter out invalid rings, and so is instead mapping high unused values onto valid rings. Instead of a mask of all known rings, we need it to be the mask of all possible rings. Fixes: 549f7365820a ("drm/i915: Enable SandyBridge blitter ring") Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI from internal implementation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v4.6+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190301140404.26690-21-chris@chris-wilson.co.uk
* | | drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+Chris Wilson2019-03-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having introduced per-context seqno, we now have a means to identity progress across the system without feel of rollback as befell the global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in advance of submission safe in the knowledge that our target seqno and address is stable. However, since we are telling the GPU to busy-spin on the target address until it matches the signaling seqno, we only want to do so when we are sure that busy-spin will be completed quickly. To achieve this we only submit the request to HW once the signaler is itself executing (modulo preemption causing us to wait longer), and we only do so for default and above priority requests (so that idle priority tasks never themselves hog the GPU waiting for others). As might be reasonably expected, HW semaphores excel in inter-engine synchronisation microbenchmarks (where the 3x reduced latency / increased throughput more than offset the power cost of spinning on a second ring) and have significant improvement (can be up to ~10%, most see no change) for single clients that utilize multiple engines (typically media players and transcoders), without regressing multiple clients that can saturate the system or changing the power envelope dramatically. v3: Drop the older NEQ branch, now we pin the signaler's HWSP anyway. v4: Tell the world and include it as part of scheduler caps. Testcase: igt/gem_exec_whisper Testcase: igt/benchmarks/gem_wsim Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190301170901.8340-3-chris@chris-wilson.co.uk
* | | Merge drm/drm-next into drm-intel-next-queuedJoonas Lahtinen2019-02-203-0/+81
|\| | | | | | | | | | | | | | | | | Doing a backmerge to be able to merge topic/mei-hdcp-2019-02-19 PR. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| * | drm/nouveau/svm: new ioctl to migrate process memory to GPU memoryJérôme Glisse2019-02-201-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This add an ioctl to migrate a range of process address space to the device memory. On platform without cache coherent bus (x86, ARM, ...) this means that CPU can not access that range directly, instead CPU will fault which will migrate the memory back to system memory. This is behind a staging flag so that we can evolve the API. Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
| * | drm/nouveau/svm: initial support for shared virtual memoryBen Skeggs2019-02-201-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses HMM to mirror a process' CPU page tables into a channel's page tables, and keep them synchronised so that both the CPU and GPU are able to access the same memory at the same virtual address. While this code also supports Volta/Turing, it's only enabled for Pascal GPUs currently due to channel recovery being unreliable right now on the later GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * | Merge drm/drm-next into drm-misc-nextMaxime Ripard2019-02-113-0/+73
| |\| | | | | | | | | | | | | | | | We need to backmerge drm-next to fix the komeda build failure. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
| | * Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2019-02-111-0/+6
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Updates for 5.1: - GDS fixes - Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES interface - GPUVM fixes - PCIE DPM switching fixes for vega20 - Vega10 uclk DPM regression fix - DC Freesync fixes - DC ABM fixes - Various DC cleanups Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190208210214.27666-1-alexander.deucher@amd.com
| | | * drm/amdgpu: add a workaround for GDS ordered append hangs with compute queuesMarek Olšák2019-02-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm not increasing the DRM version because GDS isn't totally without bugs yet. v2: update emit_ib_size Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | | * drm/amdgpu: Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIESAndrey Grodzovsky2019-02-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New chunk for dependency on start of job's execution instead on the end. This is used for GPU deadlock prevention when userspace uses mid-IB fences to wait for mid-IB work on other rings. v2: Fix typo in AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES v3: Bump KMS version v4: put old fence AFTER acquiring the scheduled fence. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Suggested-by: Christian Koenig <Christian.Koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | Merge tag 'drm-intel-next-2019-02-07' of ↵Dave Airlie2019-02-111-0/+64
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - Expose RPCS (SSEU) configuration to userspace for Ice Lake in order to allow userspace to reconfigure the subslice config per context basis. (Tvrtko, Lionel) Driver Changes: - Execbuf and preemption improvements including selftests (Chris) - Rename HAS_GMCH_DISPLAY/HAS_GMCH (Rodrigo) - Debugfs error handling fix for robustness (Greg) - Improve reg_rw traces (Ville) - Push clear_intel_crtc_state onto the heap (Chris) - Watermark fixes for Ice Lake (Ville) - Fix enable count array size and bounds checking (Tvrtko) - MST Fixes (Lyude) - Prevent race and handle error on I915_GEM_MMAP (Joonas) - Initial rework for an full atomic gamma mode (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190208165000.GA30314@intel.com
| | * \ \ Merge branch 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld into ↵Dave Airlie2019-02-011-0/+3
| | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm-next This pull includes the new Arm "komeda" DRM driver. It is currently hosted in the same repo as the other "mali-dp" driver because it is the next iteration of the IP. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190131173600.GN25147@e110455-lin.cambridge.arm.com
| | | * | | drm/afbc: Add AFBC modifier usage documentationBrian Starkey2019-01-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> [Updated MAINTAINERS entry to show that "Mali DP Maintainers" is actually a mailing list and added an SPDX-License-Identifier to the documentation] Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
| * | | | | drm/fourcc: Add new P010, P016 video formatRandy Li2019-02-081-0/+21
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. P012 is a planar 4:2:0 YUV 12 bits per channel P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per channel video format. V3: Added P012 and fixed cpp for P010. V4: format definition refined per review. V5: Format comment block for each new pixel format. V6: reversed Cb/Cr order in comments. v7: reversed Cb/Cr order in comments of header files, remove the wrong part of commit message. V8: reversed V7 changes except commit message and rebased. v9: used the new properties to describe those format and rebased. Cc: Daniel Stone <daniel@fooishbar.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Randy Li <ayaka@soulik.info> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109195710.28501-2-ayaka@soulik.info
* | | | | drm/i915: Include reminders about leaving no holes in uAPI enumsChris Wilson2019-02-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't want to pre-reserve any holes in our uAPI for that is a sign of nefarious and hidden activity. Add a reminder about our uAPI expectations to encourage good practice when adding new defines/enums. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190218094628.13522-1-chris@chris-wilson.co.uk
* | | | | drm/i915: Optionally disable automatic recovery after a GPU resetChris Wilson2019-02-181-0/+20
| |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some clients, such as mesa, may only emit minimal incremental batches that rely on the logical context state from previous batches. They know that recovery is impossible after a hang as their required GPU state is lost, and that each in flight and subsequent batch will hang (resetting the context image back to default perpetuating the problem). To avoid getting into the state in the first place, we can allow clients to opt out of automatic recovery and elect to ban any guilty context following a hang. This prevents the continual stream of hangs and allows the client to recreate their context and rebuild the state from scratch. v2: Prefer calling it recoverable rather than unrecoverable. References: https://lists.freedesktop.org/archives/mesa-dev/2019-February/215431.html Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> # for mesa Link: https://patchwork.freedesktop.org/patch/msgid/20190218105821.17293-1-chris@chris-wilson.co.uk
* | | | drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)Tvrtko Ursulin2019-02-051-0/+64
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to allow userspace to reconfigure the subslice configuration on a per context basis. This is required for the functional requirement of shutting down non-VME enabled sub-slices on Gen11 parts. To do so, we expose a context parameter to allow adjustment of the RPCS register stored within the context image (and currently not accessible via LRI). If the context is adjusted before first use or whilst idle, the adjustment is for "free"; otherwise if the context is active we queue a request to do so (using the kernel context), following all other activity by that context, which is also marked as barrier for all following submission against the same context. Since the overhead of device re-configuration during context switching can be significant, especially in multi-context workloads, we limit this new uAPI to only support the Gen11 VME use case. In this use case either the device is fully enabled, and exactly one slice and half of the subslices are enabled. Example usage: struct drm_i915_gem_context_param_sseu sseu = { }; struct drm_i915_gem_context_param arg = { .param = I915_CONTEXT_PARAM_SSEU, .ctx_id = gem_context_create(fd), .size = sizeof(sseu), .value = to_user_pointer(&sseu) }; /* Query device defaults. */ gem_context_get_param(fd, &arg); /* Set VME configuration on a 1x6x8 part. */ sseu.slice_mask = 0x1; sseu.subslice_mask = 0xe0; gem_context_set_param(fd, &arg); v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel) v3: Add ability to program this per engine (Chris) v4: Move most get_sseu() into i915_gem_context.c (Lionel) v5: Validate sseu configuration against the device's capabilities (Lionel) v6: Change context powergating settings through MI_SDM on kernel context (Chris) v7: Synchronize the requests following a powergating setting change using a global dependency (Chris) Iterate timelines through dev_priv.gt.active_rings (Tvrtko) Disable RPCS configuration setting for non capable users (Lionel/Tvrtko) v8: s/union intel_sseu/struct intel_sseu/ (Lionel) s/dev_priv/i915/ (Tvrtko) Change uapi class/instance fields to u16 (Tvrtko) Bump mask fields to 64bits (Lionel) Don't return EPERM when dynamic sseu is disabled (Tvrtko) v9: Import context image into kernel context's ppgtt only when reconfiguring powergated slice/subslices (Chris) Use aliasing ppgtt when needed (Michel) Tvrtko Ursulin: v10: * Update for upstream changes. * Request submit needs a RPM reference. * Reject on !FULL_PPGTT for simplicity. * Pull out get/set param to helpers for readability and less indent. * Use i915_request_await_dma_fence in add_global_barrier to skip waits on the same timeline and avoid GEM_BUG_ON. * No need to explicitly assign a NULL pointer to engine in legacy mode. * No need to move gen8_make_rpcs up. * Factored out global barrier as prep patch. * Allow to only CAP_SYS_ADMIN if !Gen11. v11: * Remove engine vfunc in favour of local helper. (Chris Wilson) * Stop retiring requests before updates since it is not needed (Chris Wilson) * Implement direct CPU update path for idle contexts. (Chris Wilson) * Left side dependency needs only be on the same context timeline. (Chris Wilson) * It is sufficient to order the timeline. (Chris Wilson) * Reject !RCS configuration attempts with -ENODEV for now. v12: * Rebase for make_rpcs. v13: * Centralize SSEU normalization to make_rpcs. * Type width checking (uAPI <-> implementation). * Gen11 restrictions uAPI checks. * Gen11 subslice count differences handling. Chris Wilson: * args->size handling fixes. * Update context image from GGTT. * Postpone context image update to pinning. * Use i915_gem_active_raw instead of last_request_on_engine. v14: * Add activity tracker on intel_context to fix the lifetime issues and simplify the code. (Chris Wilson) v15: * Fix context pin leak if no space in ring by simplifying the context pinning sequence. v16: * Rebase for context get/set param locking changes. * Just -ENODEV on !Gen11. (Joonas) v17: * Fix one Gen11 subslice enablement rule. * Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson) v18: * Update commit message. (Joonas) * Restrict uAPI to VME use case. (Joonas) v19: * Rebase. v20: * Rebase for ce->active_tracker. v21: * Rebase for IS_GEN changes. v22: * Reserve uAPI for flags straight away. (Chris Wilson) v23: * Rebase for RUNTIME_INFO. v24: * Added some headline docs for the uapi usage. (Joonas/Chris) v25: * Renamed class/instance to engine_class/engine_instance to avoid clash with C++ keyword. (Tony Ye) v26: * Rebased for runtime pm api changes. v27: * Rebased for intel_context_init. * Wrap commit msg to 75. v28: (Chris Wilson) * Use i915_gem_ggtt. * Use i915_request_await_dma_fence to show a better example. v29: * i915_timeline_set_barrier can now fail. (Chris Wilson) v30: * Capture some acks. v31: * Drop the WARN_ON from use controllable paths. (Chris Wilson) * Use overflows_type for all checks. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634 Issue: https://github.com/intel/media-driver/issues/267 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Zhipeng Gong <zhipeng.gong@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tony Ye <tony.ye@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com> Acked-by: Takashi Iwai <tiwai@suse.de> Acked-by: Stéphane Marchesin <marcheu@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
* | | drm/fourcc: Add definitions for Allwinner vendor and VPU tiled formatPaul Kocialkowski2019-01-181-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces specific definitions for vendor Allwinner and its associated tiled format modifier. This modifier is used for the output format of the VPU, that can be imported directly with the display engine hardware supported by the sun4i-drm driver. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190118145133.21281-12-paul.kocialkowski@bootlin.com
* | | drm/fourcc: Add modifier defininitions for AFBC 1.3Matteo Franchin2019-01-151-0/+23
| |/ |/| | | | | | | | | | | | | | | | | This commit adds definitions of format modifiers for version 1.3 of the Arm Framebuffer Compression (AFBC). Signed-off-by: Matteo Franchin <matteo.franchin@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Link: https://patchwork.freedesktop.org/patch/277333/
* | Merge tag 'drm-misc-next-2019-01-07-1' of ↵Dave Airlie2019-01-091-0/+8
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.1: UAPI Changes: Cross-subsystem Changes: - Turn dma-buf fence sequence numbers into 64 bit numbers Core Changes: - Move to a common helper for the DP MST hotplug for radeon, i915 and amdgpu - i2c improvements for drm_dp_mst - Removal of drm_syncobj_cb - Introduction of an helper to create and attach the TV margin properties Driver Changes: - Improve cache flushes for v3d - Reflection support for vc4 - HDMI overscan support for vc4 - Add implicit fencing support for rockchip and sun4i - Switch to generic fbdev emulation for virtio Signed-off-by: Dave Airlie <airlied@redhat.com> [airlied: applied amdgpu merge fixup] From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107180333.amklwycudbsub3s5@flea
| * drm/v3d: Document cache flushing ABI.Eric Anholt2018-12-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Right now, userspace doesn't do any L2T writes, but we should lay out our expectations for how it works. v2: Explicitly mention the VCD cache flushing requirements and that we'll flush the other caches before each of the CLs. Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20181203222438.25417-1-eric@anholt.net Reviewed-by: Dave Emett <david.emett@broadcom.com>
* | drm/msm: add uapi to get/set debug nameRob Clark2018-12-111-0/+2
| | | | | | | | | | | | Add UAPI to get/set GEM objects' debug name. Signed-off-by: Rob Clark <robdclark@gmail.com>
* | drm/msm: rework GEM_INFO ioctlRob Clark2018-12-111-5/+13
| | | | | | | | | | | | Prep work to add a way to get/set the GEM objects debug name. Signed-off-by: Rob Clark <robdclark@gmail.com>
* | drm/msm/gpu: add submit flag to hint which buffers should be dumpedRob Clark2018-12-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | To lower CPU overhead, future userspace will be switching to pinning iova and avoiding the use of relocs, and only include cmds table entries for IB1 level cmdstream (but not IB2 or state-groups). This leaves the kernel unsure what to dump for rd/hangrd cmdstream dumping. So add a MSM_SUBMIT_BO_DUMP flag so userspace can indicate buffers that contain cmdstream (or are otherwise important to dump). Signed-off-by: Rob Clark <robdclark@gmail.com>
* | Merge tag 'drm-misc-next-2018-12-06' of ↵Dave Airlie2018-12-071-0/+25
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next Final changes to drm-misc-next for v4.21: UAPI Changes: Core Changes: - Add dma_fence_get_stub to dma-buf, and use it in drm/syncobj. - Add and use DRM_MODESET_LOCK_BEGIN/END helpers. - Small fixes to drm_atomic_helper_resume(), drm_mode_setcrtc() and drm_atomic_helper_commit_duplicated_state() - Fix drm_atomic_state_helper.[c] extraction. Driver Changes: - Small fixes to tinydrm, vkms, meson, rcar-du, virtio, vkms, v3d, and pl111. - vc4: Allow scaling and YUV formats on cursor planes. - v3d: Enable use of the Texture Formatting Unit, and fix prime imports of buffers from other drivers. - Add support for the AUO G101EVN010 panel. - sun4i: Enable support for the H6 display engine. Signed-off-by: Dave Airlie <airlied@redhat.com> [airlied: added drm/v3d: fix broken build to the merge commit] From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/321be9d3-ab75-5f92-8193-e5113662edef@linux.intel.com
| * drm/v3d: Add support for submitting jobs to the TFU.Eric Anholt2018-11-301-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TFU can copy from raster, UIF, and SAND input images to UIF output images, with optional mipmap generation. This will certainly be useful for media EGL image input, but is also useful immediately for mipmap generation without bogging the V3D core down. For now we only run the queue 1 job deep, and don't have any hang recovery (though I don't think we should need it, with TFU). Queuing multiple jobs in the HW will require synchronizing the YUV coefficient regs updates since they don't get FIFOed with the job. v2: Change the ioctl to IOW instead of IOWR, always set COEF0, explain why TFU is AUTH, clarify the syncing docs, drop the unused TFU interrupt regs (you're expected to use the hub's), don't take &bo->base for NULL bos. v3: Fix a little whitespace alignment (noticed by checkpatch), rebase on drm_sched_job_cleanup() changes. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Dave Emett <david.emett@broadcom.com> (v2) Link: https://patchwork.freedesktop.org/patch/264607/
* | drm: Add a new plane property to send damage during plane updateLukasz Spintzyk2018-12-051-0/+19
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | FB_DAMAGE_CLIPS is an optional plane property to mark damaged regions on the plane in framebuffer coordinates of the framebuffer attached to the plane. The layout of blob data is simply an array of "struct drm_mode_rect". Unlike plane src coordinates, damage clips are not in 16.16 fixed point. As plane src in framebuffer cannot be negative so are damage clips. In damage clip, x1/y1 are inclusive and x2/y2 are exclusive. This patch also exports the kernel internal drm_rect to userspace as drm_mode_rect. This is because "struct drm_clip_rect" is not sufficient to represent damage for current plane size. Driver which are interested in enabling FB_DAMAGE_CLIPS property for a plane should enable this property using drm_plane_enable_damage_clips. v2: - Input validation on damage clips against framebuffer size. - Doc update, other minor changes. Signed-off-by: Lukasz Spintzyk <lukasz.spintzyk@displaylink.com> Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
* Merge tag 'drm-misc-next-2018-11-28' of ↵Dave Airlie2018-11-291-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v4.21: Core Changes: - Merge drm_info.c into drm_debugfs.c - Complete the fake drm_crtc_commit's hw_done/flip_done sooner. - Remove deprecated drm_obj_ref/unref functions. All drivers use get/put now. - Decrease stack use of drm_gem_prime_mmap. - Improve documentation for dumb callbacks. Driver Changes: - Add edid support to virtio. - Wait on implicit fence in meson and sun4i. - Add support for BGRX8888 to sun4i. - Preparation patches for sun4i driver to start supporting linear and tiled YUV formats. - Add support for HDMI 1.4 4k modes to meson, and support for VIC alternate timings. - Drop custom dumb_map in vkms. - Small fixes and cleanups to v3d. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/151a3270-b1be-ed75-bd58-6b29d741f592@linux.intel.com
| * drm/v3d: Fix whitespace inconsistency in the header.Eric Anholt2018-11-271-2/+2
| | | | | | | | | | | | Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20181108161654.19888-2-eric@anholt.net Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
* | Merge tag 'drm-intel-next-2018-11-22' of ↵Dave Airlie2018-11-291-0/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next Changes outside i915: - Connector property to limit max bpc (Radhakrishna) - Fix LPE audio runtime PM and deinit (Ville) - DP FEC prep work (Anusha) - Mark pinned shmemfs pages as unevictable (Kuo-Hsin) - Backmerge drm-next (Jani) Inside i915: - Revert OA UAPI change that lacks userspace (Joonas) - Register macro cleanup (Jani) - 32-bit build fixes on pin flags (Chris) - Fix MG DP mode and PHY gating for HDMI (Imre) - DP MST race, hpd and irq fixes (Lyude) - Combo PHY fixes and cleanup (Imre, Lucas) - Move display init and cleanup under modeset init and cleanup (José) - PSR fixes (José) - Subslice size fixes (Daniele) - Abstract and clean up fixed point helpers (Jani) - Plane input CSC for YUV to RGB conversion (Uma) - Break long iterations for get/put shmemfs pages (Chris) - Improve DDI encoder hw state readout sanity checks (Imre) - Fix power well leaks for MST (José) - Scaler fixes (Ville) - Watermark fixes (Ville) - Fix VLV/CHV DSI panel orientation readout (Ville) - ICL rawclock fixes (Paulo) - Workaround DMC power well request issues (Imre) - Plane allocation fix (Maarten) - Transcoder enum value/ordering robustness fixes (Imre) - UTS_RELEASE build dependency fix (Hans Holmberg) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87k1l4cesj.fsf@intel.com
| * \ Merge drm/drm-next into drm-intel-next-queuedJani Nikula2018-11-204-0/+31
| |\ \ | | | | | | | | | | | | | | | | | | | | Pull in v4.20-rc3 via drm-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | Revert "drm/i915/perf: add a parameter to control the size of OA buffer"Joonas Lahtinen2018-11-191-7/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace portion is still missing. This reverts commit cd956bfcd0f58d20485ac0a785415f7d9327a95f. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116135510.13807-1-joonas.lahtinen@linux.intel.com
| * | | Merge drm/drm-next into drm-intel-next-queuedJani Nikula2018-11-021-0/+9
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although there's nothing crucial missing, it's been a long time since the last backmerge. Catch up with drm-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-20 08:00:51 +0200