Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 29 10月, 2018 1 次提交
  3. 24 10月, 2018 3 次提交
  5. 23 10月, 2018 1 次提交
  7. 22 10月, 2018 6 次提交
  9. 17 10月, 2018 3 次提交
  11. 16 10月, 2018 1 次提交
  13. 15 10月, 2018 1 次提交
    • S
      drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON · 668b6c17
      由 Shashank Sharma 提交于 
      LSPCON chips can generate YCBCR outputs, if asked nicely :).

In order to generate YCBCR 4:2:0 outputs, a source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:2:0 in AVI infoframes

Whereas for YCBCR 4:4:4 outputs, the source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:4:4 in AVI infoframes

So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
information indicates LSPCON FW to start scaling down from YCBCR
4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.

V2: rebase
V3: Addressed review comments from Ville
    - add enum crtc_output_format instead of bool ycbcr420
    - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
      cases in this way we will have YCBCR 4:4:4 framework ready (except
      the ABI part)
V4: Added r-b from Maarten (for v3)
    Addressed review comments from Ville:
    - Do not add a non-atomic state variable to determine lspcon output.
      Instead add bool in CRTC state to indicate lspcon based scaling.
V5: Addressed review comments from Ville:
    - Change the state bool name from external scaling to something more
      relavent.
    - Keep the info and adjusted_mode structures const.
    - use crtc_state instead of pipe_config.
    - Push all the config change into lspcon_ycbcr420_config function.
V6: Rebase, small changes to accommodate changes in patch 2.
V7: Fixed checkpatch warnings for alignment
V8: Rebase

    PS: Ignored following warnings to match the current formatting:
    drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
     -:53: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
    #53: FILE: drivers/gpu/drm/i915/i915_reg.h:8721:
    +#define  TRANS_MSA_SAMPLING_444        (2<<1)
                                          ^
    -:54: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
    #54: FILE: drivers/gpu/drm/i915/i915_reg.h:8722:
    +#define  TRANS_MSA_CLRSP_YCBCR         (2<<3)
V9: Rebase
V10: Rebase
V11: Rebase

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1539325394-20788-8-git-send-email-shashank.sharma@intel.com
      668b6c17
  15. 09 10月, 2018 2 次提交
  17. 06 10月, 2018 1 次提交
  19. 02 10月, 2018 1 次提交
  21. 26 9月, 2018 2 次提交
  23. 22 9月, 2018 1 次提交
  25. 14 9月, 2018 2 次提交
  27. 12 9月, 2018 1 次提交
  29. 04 9月, 2018 1 次提交
    • T
      drm/i915/icl: Fix context RPCS programming · b212f0a4
      由 Tvrtko Ursulin 提交于 
      There are two issues with the current RPCS programming for Icelake:

Expansion of the slice count bitfield has been missed, as well as the
required programming workaround for the subslice count bitfield size
limitation.

1)

Bitfield width for configuring the active slice count has grown so we need
to program the GEN8_R_PWR_CLK_STATE accordingly.

Current code was always requesting eight times the number of slices (due
writing to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.

Due both of the above there was no impact from this incorrect programming
but we should still fix it.

2)

Due subslice count bitfield being only three bits wide and furthermore
capped to a maximum documented value of four, special programming
workaround is needed to enable more than four subslices.

With this programming driver has to consider the GT configuration as
2x4x8, while the hardware internally translates this to 1x8x8.

A limitation stemming from this is that either a subslice count between
one and four can be selected, or a subslice count equaling the total
number of subslices in all selected slices. In other words, odd subslice
counts greater than four are impossible, as are odd subslice counts
greater than a single slice subslice count.

This also had no impact in the current code base due breakage from 1)
always reqesting more than one slice.

While fixing this we also add some asserts to flag up any future bitfield
overflows.

v2:
 * Use a local in all branches for clarity. (Lionel)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Bspec: 12247
Reported-by: tony.ye@intel.com
Suggested-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: tony.ye@intel.com
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180903113007.2643-1-tvrtko.ursulin@linux.intel.com
      b212f0a4
  31. 29 8月, 2018 1 次提交
  33. 25 8月, 2018 1 次提交
    • P
      drm/i915/icl: implement the tc/legacy HPD {dis,}connect flows · 39d1e234
      由 Paulo Zanoni 提交于 
      Unlike the other ports, TC ports are not available to use as soon as
we get a hotplug. The TC PHYs can be shared between multiple
controllers: display, USB, etc. As a result, handshaking through FIA
is required around connect and disconnect to cleanly transfer
ownership with the controller and set the type-C power state.

This patch implements the flow sequences described by our
specification. We opt to grab ownership of the ports as soon as we get
the hotplugs in order to simplify the interactions and avoid surprises
in the user space side. We may consider changing this in the future,
once we improve our testing capabilities on this area.

v2:
 * This unifies the DP and HDMI patches so we can discuss everything
   at once so people looking at random single patches can actually
   understand the direction.
 * I found out the spec was updated a while ago. There's a small
   difference in the connect flow and the patch was updated for that.
 * Our spec also now gives a good explanation on what is really
   happening. As a result, comments were added.
 * Add some more comments as requested by Rodrigo (Rodrigo).
v3:
 * Downgrade a DRM_ERROR that shouldn't ever happen but we can't act
   on in case it does (Chris).

BSpec: 21750, 4250.
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180801173441.9789-1-paulo.r.zanoni@intel.com
      39d1e234
  35. 23 8月, 2018 1 次提交
  37. 21 8月, 2018 2 次提交
  39. 17 8月, 2018 2 次提交
  41. 16 8月, 2018 1 次提交
  43. 14 8月, 2018 1 次提交
  45. 08 8月, 2018 4 次提交