1. 21 Mar, 2019 1 commit
    • Maarten Lankhorst's avatar
      drm/fourcc: Fix conflicting Y41x definitions · ff01e697
      Maarten Lankhorst authored
      There has unfortunately been a conflict with the following 3 commits:
      
      commit e9961ab9
      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 7ba0fee2
      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 50bf5d7d
      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: default avatarMaarten 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: default avatarSean Paul <sean@poorly.run>
      Reviewed-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      ff01e697
  2. 20 Mar, 2019 5 commits
  3. 15 Mar, 2019 3 commits
  4. 14 Mar, 2019 7 commits
  5. 13 Mar, 2019 5 commits
  6. 12 Mar, 2019 10 commits
    • Ayan Kumar Halder's avatar
      drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART · 25570b5e
      Ayan Kumar Halder authored
      The list of modifiers to be supported for each plane has been dynamically generated
      from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
      
      Changes from v1:-
      1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
      to report unsupported modifiers.
      
      Changes from v2:-
      1. Removed malidp_format_mod_supported() from the current patch. This has been added
      in "PATCH 7/12"
      2. Dynamically generate the list of modifiers (to be supported for each plane) from
      'malidp_format_modifiers' and features.
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291767/?series=57895&rev=1
      25570b5e
    • Ayan Kumar Halder's avatar
      drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer. · 0f6c18de
      Ayan Kumar Halder authored
      Considering the fact that some of the AFBC specific pixel formats are expressed
      in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
      is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
      For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
      width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
      (ie 16 bytes) for DP650.
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Acked-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291764/?series=57895&rev=1
      0f6c18de
    • Ayan Kumar Halder's avatar
      drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of... · 7834c577
      Ayan Kumar Halder authored
      drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
      
      Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
      DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
      integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
      the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291766/?series=57895&rev=1
      7834c577
    • Ayan Kumar Halder's avatar
      drm/arm/malidp:- Writeback framebuffer does not support any modifiers · da773658
      Ayan Kumar Halder authored
      In malidp, the writeback pipeline does not support writing crtc output
      to a framebuffer with modifiers ie the memory writeback content is
      devoid of any compression or tiling, etc.
      So we have added a commit check in memory writeback encoder helper function
      to validate if the framebuffer has any modifier and if so, return EINVAL.
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Acked-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291765/?series=57895&rev=1
      da773658
    • Ayan Kumar Halder's avatar
      drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats · b8207562
      Ayan Kumar Halder authored
      The newly supported AFBC YUV formats have the following rotation memory
      constraints (in DP550/DP650).
      1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
      horizontal lines in the AFBC output buffer.
      2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
      in the AFBC output buffer.
      
      Also some of the pixel formats are specified in bits per pixel (rather
      than bytes per pixel), so the calculation needs to take note of this.
      
      Besides there are some difference between DP550 and DP650 and these are
      as follows:-
      1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
      DP550. For DP650, it can rotate upto 16 horizontal lines in the AFBC
      output buffer, whereas in DP550 (with AFBC), it can rotate upto 8
      horizontal lines.
      2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
      dp550 and 16 horizontal lines in DP650.
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291763/?series=57895&rev=1
      b8207562
    • Ayan Kumar Halder's avatar
      drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650 · 5e290226
      Ayan Kumar Halder authored
      We need to define a common list of format modifiers supported by each of
      the Mali display processors.
      
      The following are the constraints with AFBC:-
      
      1. AFBC is not supported for the formats defined in
      malidp_hw_format_is_linear_only()
      
      2. Some of the formats are supported only with AFBC modifiers. Thus we have
      introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
      the same.
      
      3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
      
      4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
      
      5. CBR should not be set for non-subsampled formats.
      
      6. SMART layer does not support framebuffer with AFBC modifiers.
      Return -EINVAL for such a scenario.
      
      7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
      
      8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
      However in DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT.
      This feature has been identified with
      MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
      
      9. In DP550 and DP650, for YUYV, the hardware supports different
      format-ids to be used with and without AFBC modifier. We have used the
      feature 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this
      characteristic.
      
      10. DP500 does not support split mode (ie AFBC_FORMAT_MOD_SPLIT). We have
      used the feature 'MALIDP_DEVICE_AFBC_SUPPORT_SPLIT' to identify the DPs
      which support SPLIT mode.
      
      11. DP550 supports YUV420 with split mode. We have defined the feature
      'AFBC_SUPPORT_SPLIT_WITH_YUV_420_10' to identify this characteristic.
      
      Changes since v1:-
      - Merged https://patchwork.freedesktop.org/patch/265215/ into this patch
      - As Liviu pointed out in the last patch, we can pull the checks outside
      of the 'while (*modifiers != DRM_FORMAT_MOD_INVALID)' loop
      - Rebased
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291762/?series=57895&rev=1
      5e290226
    • Ayan Kumar Halder's avatar
      drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650 · ed893860
      Ayan Kumar Halder authored
      We have added support for some AFBC only pixel formats like :-
      DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
      DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
      DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
      DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)
      
      Generally, these formats are supported by our hardware using the same
      hw-ids as the equivalent multi plane pixel formats.
      
      Also we have added support for XYUV 444 8 and 10 bit formats
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar Halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291761/?series=57895&rev=1
      ed893860
    • Ayan Kumar Halder's avatar
      drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier · 54b4260a
      Ayan Kumar Halder authored
      Added the AFBC decoder registers for DP500 , DP550 and DP650.
      These registers control the processing of AFBC buffers. It controls various
      features like AFBC decoder enable, lossless transformation and block split
      as well as setting of the left, right, top and bottom cropping of AFBC
      buffers (in number of pixels).
      All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
      One needs to set the pixel values of the top, left, bottom and right
      cropping for the AFBC framebuffer.
      Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
      In that case, the layer input size registers should be configured with
      framebuffer's dimensions and not with drm_plane_state source width/height
      values (which is used for non AFBC framebuffer to denote cropping).
      
      Changes from v1:
       - Removed the "if (fb->modifier)" check from malidp_de_plane_update()
      and added it in malidp_de_set_plane_afbc(). This will consolidate all the
      AFBC specific register configurations in a single function ie
      malidp_de_set_plane_afbc().
      
      Changes from v2:
       - For AFBC framebuffer, layer input size register should be set to
      framebuffer's width and height.
      
      Changes from v3:
      - Rebased on top of latest drm-misc-next
      - Some cleanups/sanity changes based on Liviu's comments
      
      Changes from v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar Halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291760/?series=57895&rev=1
      54b4260a
    • Ayan Kumar Halder's avatar
      drm: Added a new format DRM_FORMAT_XVYU2101010 · e9961ab9
      Ayan Kumar Halder authored
      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: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291758/?series=57895&rev=1
      e9961ab9
    • Brian Starkey's avatar
      drm/fourcc: Add AFBC yuv fourccs for Mali · 7ba0fee2
      Brian Starkey authored
      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: default avatarBrian Starkey <brian.starkey@arm.com>
      Signed-off-by: default avatarAyan Kumar Halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291759/?series=57895&rev=1
      7ba0fee2
  7. 11 Mar, 2019 6 commits
  8. 08 Mar, 2019 3 commits