1. 15 7月, 2017 1 次提交
    • S
      drm: handle HDMI 2.0 VICs in AVI info-frames · 0c1f528c
      Shashank Sharma 提交于
      HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
      For any other mode, the VIC filed in AVI infoframes should be 0.
      HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
      extended to (VIC 1-107).
      
      This patch adds a bool input variable, which indicates if the connected
      sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
      HDMI 2.0 VIC to a HDMI 1.4 sink.
      
      This patch touches all drm drivers, who are callers of this function
      drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
      no change in current behavior, is_hdmi2 is kept as false.
      
      In case of I915 driver, this patch:
      - checks if the connected display is HDMI 2.0.
      - HDMI infoframes carry one of this two type of information:
      	- VIC for 4K modes for HDMI 1.4 sinks
      	- S3D information for S3D modes
        As CEA-861-F has already defined VICs for 4K videomodes, this
        patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
        until the mode is 3D.
      
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Jose Abreu <jose.abreu@synopsys.com>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      
      PS: This patch touches a few lines in few files, which were
      already above 80 char, so checkpatch gives 80 char warning again.
      - gpu/drm/omapdrm/omap_encoder.c
      - gpu/drm/i915/intel_sdvo.c
      
      V2: Rebase, Added r-b from Andrzej
      V3: Addressed review comment from Ville:
      	- Do not send VICs in both AVI-IF and HDMI-IF
      	  send only one of it.
      V4: Rebase
      V5: Added r-b from Neil.
          Addressed review comments from Ville
          - Do not block HDMI vendor IF, instead check for VIC while
            handling AVI infoframes
      V6: Rebase
      V7: Rebase
      Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      0c1f528c
  2. 14 6月, 2017 1 次提交
  3. 16 5月, 2017 1 次提交
  4. 29 4月, 2017 1 次提交
  5. 08 4月, 2017 2 次提交
  6. 06 4月, 2017 1 次提交
  7. 30 3月, 2017 2 次提交
  8. 14 1月, 2017 1 次提交
  9. 15 12月, 2016 2 次提交
    • V
      drm: Nuke fb->pixel_format · 438b74a5
      Ville Syrjälä 提交于
      Replace uses of fb->pixel_format with fb->format->format.
      Less duplicated information is a good thing.
      
      Note that coccinelle failed to eliminate the
      "/* fourcc format */" comment from drm_framebuffer.h, so I had
      to do that part manually.
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       drm_helper_mode_fill_fb_struct(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       i9xx_get_initial_plane_config(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       ironlake_get_initial_plane_config(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       skylake_get_initial_plane_config(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *a;
      struct drm_framebuffer b;
      @@
      (
      - a->pixel_format
      + a->format->format
      |
      - b.pixel_format
      + b.format->format
      )
      
      @@
      struct drm_plane_state *a;
      struct drm_plane_state b;
      @@
      (
      - a->fb->pixel_format
      + a->fb->format->format
      |
      - b.fb->pixel_format
      + b.fb->format->format
      )
      
      @@
      struct drm_crtc *CRTC;
      @@
      (
      - CRTC->primary->fb->pixel_format
      + CRTC->primary->fb->format->format
      |
      - CRTC->primary->state->fb->pixel_format
      + CRTC->primary->state->fb->format->format
      )
      
      @@
      struct drm_mode_set *set;
      @@
      (
      - set->fb->pixel_format
      + set->fb->format->format
      |
      - set->crtc->primary->fb->pixel_format
      + set->crtc->primary->fb->format->format
      )
      
      @@
      @@
       struct drm_framebuffer {
      	 ...
      -	 uint32_t pixel_format;
      	 ...
       };
      
      v2: Fix commit message (Laurent)
          Rebase due to earlier removal of many fb->pixel_format uses,
          including the 'fb->format = drm_format_info(fb->format->format);'
          snafu
      v3: Adjusted the semantic patch a bit and regenerated due to code
          changes
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1481751175-18463-1-git-send-email-ville.syrjala@linux.intel.com
      438b74a5
    • V
      drm: Nuke fb->bits_per_pixel · 272725c7
      Ville Syrjälä 提交于
      Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
      Less duplicated information is a good thing.
      
      Note that I didn't put parens around the cpp*8 in the below cocci script,
      on account of not wanting spurious parens all over the place. Instead I
      did the unsafe way, and tried to look over the entire diff to spot if
      any dangerous expressions were produced. I didn't see any.
      
      There are some cases where previously the code did X*bpp/8, so the
      division happened after the multiplication. Those are now just X*cpp
      so the division effectively happens before the multiplication,
      but that is perfectly fine since bpp is always a multiple of 8.
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       drm_helper_mode_fill_fb_struct(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       i9xx_get_initial_plane_config(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       ironlake_get_initial_plane_config(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       skylake_get_initial_plane_config(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer FB;
      expression E;
      @@
      (
      - E * FB.bits_per_pixel / 8
      + E * FB.format->cpp[0]
      |
      - FB.bits_per_pixel / 8
      + FB.format->cpp[0]
      |
      - E * FB.bits_per_pixel >> 3
      + E * FB.format->cpp[0]
      |
      - FB.bits_per_pixel >> 3
      + FB.format->cpp[0]
      |
      - (FB.bits_per_pixel + 7) / 8
      + FB.format->cpp[0]
      |
      - FB.bits_per_pixel
      + FB.format->cpp[0] * 8
      |
      - FB.format->cpp[0] * 8 != 8
      + FB.format->cpp[0] != 1
      )
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
      (
      - E * FB->bits_per_pixel / 8
      + E * FB->format->cpp[0]
      |
      - FB->bits_per_pixel / 8
      + FB->format->cpp[0]
      |
      - E * FB->bits_per_pixel >> 3
      + E * FB->format->cpp[0]
      |
      - FB->bits_per_pixel >> 3
      + FB->format->cpp[0]
      |
      - (FB->bits_per_pixel + 7) / 8
      + FB->format->cpp[0]
      |
      - FB->bits_per_pixel
      + FB->format->cpp[0] * 8
      |
      - FB->format->cpp[0] * 8 != 8
      + FB->format->cpp[0] != 1
      )
      
      @@
      struct drm_plane_state *state;
      expression E;
      @@
      (
      - E * state->fb->bits_per_pixel / 8
      + E * state->fb->format->cpp[0]
      |
      - state->fb->bits_per_pixel / 8
      + state->fb->format->cpp[0]
      |
      - E * state->fb->bits_per_pixel >> 3
      + E * state->fb->format->cpp[0]
      |
      - state->fb->bits_per_pixel >> 3
      + state->fb->format->cpp[0]
      |
      - (state->fb->bits_per_pixel + 7) / 8
      + state->fb->format->cpp[0]
      |
      - state->fb->bits_per_pixel
      + state->fb->format->cpp[0] * 8
      |
      - state->fb->format->cpp[0] * 8 != 8
      + state->fb->format->cpp[0] != 1
      )
      
      @@
      @@
      - (8 * 8)
      + 8 * 8
      
      @@
      struct drm_framebuffer FB;
      @@
      - (FB.format->cpp[0])
      + FB.format->cpp[0]
      
      @@
      struct drm_framebuffer *FB;
      @@
      - (FB->format->cpp[0])
      + FB->format->cpp[0]
      
      @@
      @@
       struct drm_framebuffer {
      	 ...
      -	 int bits_per_pixel;
      	 ...
       };
      
      v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent)
      v3: Adjusted the semantic patch a bit and regenerated due to code
          changes
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
      Link: http://patchwork.freedesktop.org/patch/msgid/1481751140-18352-1-git-send-email-ville.syrjala@linux.intel.com
      272725c7
  10. 07 12月, 2016 3 次提交
  11. 24 11月, 2016 1 次提交
  12. 12 11月, 2016 1 次提交
  13. 26 10月, 2016 3 次提交
  14. 21 10月, 2016 1 次提交
  15. 14 10月, 2016 1 次提交
  16. 29 9月, 2016 2 次提交
  17. 23 9月, 2016 1 次提交
  18. 16 8月, 2016 1 次提交
  19. 15 8月, 2016 1 次提交
  20. 11 8月, 2016 2 次提交
  21. 09 8月, 2016 1 次提交
  22. 08 8月, 2016 1 次提交
  23. 14 6月, 2016 1 次提交
  24. 07 6月, 2016 2 次提交
  25. 17 5月, 2016 1 次提交
  26. 12 5月, 2016 2 次提交
  27. 05 5月, 2016 1 次提交
  28. 02 5月, 2016 1 次提交
  29. 09 3月, 2016 1 次提交