Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 10月, 2019 1 次提交
  3. 15 10月, 2019 1 次提交
  5. 10 10月, 2019 2 次提交
  7. 03 10月, 2019 1 次提交
    • M
      drm/i915/dp: Fix dsc bpp calculations, v5. · cffb4c3e
      由 Maarten Lankhorst 提交于 
      There was a integer wraparound when mode_clock became too high,
and we didn't correct for the FEC overhead factor when dividing,
with the calculations breaking at HBR3.

As a result our calculated bpp was way too high, and the link width
limitation never came into effect.

Print out the resulting bpp calcululations as a sanity check, just
in case we ever have to debug it later on again.

We also used the wrong factor for FEC. While bspec mentions 2.4%,
all the calculations use 1/0.972261, and the same ratio should be
applied to data M/N as well, so use it there when FEC is enabled.

This fixes the FIFO underrun we are seeing with FEC enabled.

Changes since v2:
- Handle fec_enable in intel_link_compute_m_n, so only data M/N is adjusted. (Ville)
- Fix initial hardware readout for FEC. (Ville)
Changes since v3:
- Remove bogus fec_to_mode_clock. (Ville)
Changes since v4:
- Use the correct register for icl. (Ville)
- Split hw readout to a separate patch.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: d9218c8f ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
Cc: <stable@vger.kernel.org> # v5.0+
Cc: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190925082110.17439-1-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit ed06efb8)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      cffb4c3e
  9. 02 10月, 2019 1 次提交
  11. 25 9月, 2019 1 次提交
    • M
      drm/i915/dp: Fix dsc bpp calculations, v5. · ed06efb8
      由 Maarten Lankhorst 提交于 
      There was a integer wraparound when mode_clock became too high,
and we didn't correct for the FEC overhead factor when dividing,
with the calculations breaking at HBR3.

As a result our calculated bpp was way too high, and the link width
limitation never came into effect.

Print out the resulting bpp calcululations as a sanity check, just
in case we ever have to debug it later on again.

We also used the wrong factor for FEC. While bspec mentions 2.4%,
all the calculations use 1/0.972261, and the same ratio should be
applied to data M/N as well, so use it there when FEC is enabled.

This fixes the FIFO underrun we are seeing with FEC enabled.

Changes since v2:
- Handle fec_enable in intel_link_compute_m_n, so only data M/N is adjusted. (Ville)
- Fix initial hardware readout for FEC. (Ville)
Changes since v3:
- Remove bogus fec_to_mode_clock. (Ville)
Changes since v4:
- Use the correct register for icl. (Ville)
- Split hw readout to a separate patch.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: d9218c8f ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
Cc: <stable@vger.kernel.org> # v5.0+
Cc: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190925082110.17439-1-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      ed06efb8
  13. 23 9月, 2019 2 次提交
  15. 20 9月, 2019 1 次提交
    • V
      drm/i915: Don't advertise modes that exceed the max plane size · 2d20411e
      由 Ville Syrjälä 提交于 
      Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
planes' max resolution. This has the nasty implication that modes on the
connectors' mode list may not be usable when the user asks for a
fullscreen plane. Seeing as that is the most common use case it seems
prudent to filter out modes that don't allow for fullscreen planes to
be enabled.

Let's do that in the connetor .mode_valid() hook so that normally
such modes are kept hidden but the user is still able to forcibly
specify such a mode if they know they don't need fullscreen planes.

This is in line with ealier policies regarding certain clock limits.
The idea is to prevent the casual user from encountering a mode that
would fail under typical conditions, but allow the expert user to
force things if they so wish.

Maybe in the future we should consider automagically using two
planes when one can't cover the entire screen? Wouldn't be a
great match for the current uapi with explicit planes though,
but I guess no worse than using two pipes (which we apparently
have to in the future anyway). Either that or we'd have to
teach userspace to do it for us.

v2: Fix icl+ max plane heigth (Manasi)

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Leho Kraav <leho@kraav.com>
Cc: Sean Paul <sean@poorly.run>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190918150707.32420-1-ville.syrjala@linux.intel.com
      2d20411e
  17. 16 9月, 2019 1 次提交
  19. 12 9月, 2019 1 次提交
  21. 30 8月, 2019 1 次提交
  23. 27 8月, 2019 1 次提交
  25. 09 8月, 2019 1 次提交
  27. 07 8月, 2019 1 次提交
  29. 13 7月, 2019 1 次提交
    • A
      drm/i915: Add modular FIA · 0caf6257
      由 Anusha Srivatsa 提交于 
      Some platforms may have Modular FIA. If Modular FIA is used in the SOC,
then Display Driver will access the additional instances of
FIA based on pre-assigned offset in GTTMADDR space.

Each Modular FIA instance has its own IOSF Sideband Port ID
and it houses only 2 Type-C Port. In SOC that has more than
two Type-C Ports, there are multiple instances of Modular FIA.
Gunit will need to use different destination ID when it access
different pair of Type-C Port.

The DFLEXDPSP register has Modular FIA bit starting on Tiger Lake.  If
Modular FIA is used in the SOC, this register bit exists in all the
instances of Modular FIA. IOM FW is required to program only the MF bit
in first FIA instance that houses the Type-C Port 0 and Port 1, for
Display Driver to read from.

v2 (Lucas):
  - Move all accesses to FIA to be contained in intel_tc.c, along with
    display_fia that is now called tc_phy_fia
  - Save the fia instance number on intel_digital_port, so we don't have
    to query if modular FIA is used on every access
v3 (Lucas): Make function static
v4 (Lucas): Move enum phy_fia to the header and use it in
   intel_digital_port (suggested by Ville)
v5 (Lucas): Add comment about the mapping between FIA and TC port
   (suggested by Stuart)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NStuart Summers <stuart.summers@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712055706.12143-2-lucas.demarchi@intel.com
      0caf6257
  31. 12 7月, 2019 4 次提交
  33. 11 7月, 2019 2 次提交
    • M
      drm/i915/gen11: Convert combo PHY logic to use new 'enum phy' namespace · dc867bc7
      由 Matt Roper 提交于 
      Convert the code that operates directly on gen11 combo PHY's to use the
new namespace.  Combo PHY registers are those named "ICL_PORT_*" plus
ICL_DPHY_CHKN.

Note that a lot of the PHY programming happens in the MIPI DSI code.
For clarity I've added a for_each_dsi_phy() to loop over the phys used
by DSI.  Since DSI always uses A & B on gen11, port=phy in all cases so
it doesn't actually matter which form we use in the DSI code.  I've used
the phy iterator in code that's explicitly working with the combo PHY,
but left the rest of the DSI code using the port iterator and namespace
to minimize patch deltas.  We can switch the rest of the DSI code over
to use phy terminology later if this winds up being too confusing.

v6: Drop an include of drm/i915_drm.h; that was previously included just
    for the definition of 'enum port' which this patch removes the need
    for.  (Jose)

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190709183934.445-4-matthew.d.roper@intel.com
      dc867bc7
    • M
      drm/i915/gen11: Start distinguishing 'phy' from 'port' · 358633e7
      由 Matt Roper 提交于 
      Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping.
Because of this, both the bspec documentation and our i915 code has used
the term "port" when talking about either DDI's or PHY's; it was always
easy to tell what terms like "Port A" were referring to from the
context.

Unfortunately this is starting to break down now that EHL allows PHY-A
to be driven by either DDI-A or DDI-D.  Is a setup with DDI-D driving
PHY-A considered "Port A" or "Port D?"  The answer depends on which
register we're working with, and even the bspec doesn't do a great job
of clarifying this.

Let's try to be more explicit about whether we're talking about the DDI
or the PHY on gen11+ by using 'port' to refer to the DDI and creating a
new 'enum phy' namespace to refer to the PHY in use.

This patch just adds the new PHY namespace, new phy-based versions of
intel_port_is_*(), and a helper to convert a port to a PHY.
Transitioning various areas of the code over to using the PHY namespace
will be done in subsequent patches to make review easier.  We'll remove
the intel_port_is_*() functions at the end of the series when we
transition all callers over to using the PHY-based versions.

v2:
 - Convert a few more 'port' uses to 'phy.' (Sparse)

v3:
 - Switch DDI_CLK_SEL() back to 'port.' (Jose)
 - Add a code comment clarifying why DPCLKA_CFGCR0_ICL needs to use PHY
   for its bit definitions, even though the register description is
   given in terms of DDI.
 - To avoid confusion, switch CNL's DPCLKA_CFGCR0 defines back to using
   port and create separate ICL+ definitions that work in terms of PHY.

v4:
 - Rebase and resolve conflicts with Imre's TC series.
 - This patch now just adds the namespace and a few convenience
   functions; the important changes are now split out into separate
   patches to make review easier.
Suggested-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190709183934.445-2-matthew.d.roper@intel.com
      358633e7
  35. 01 7月, 2019 1 次提交
  37. 17 6月, 2019 1 次提交
  39. 04 6月, 2019 1 次提交
  41. 20 5月, 2019 2 次提交
    • V
      drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping · aa5ca8b7
      由 Ville Syrjälä 提交于 
      Align dumb buffer stride to 4k if the fb will be big enough to
require gtt remapping.

v2: Leave the stride alone for buffers that look to be for the cursor
v3: Make it not a hack (Daniel)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190509122159.24376-7-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      aa5ca8b7
    • V
      drm/i915: Overcome display engine stride limits via GTT remapping · 54d4d719
      由 Ville Syrjälä 提交于 
      The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller stride.

The code is mostly already there as We already play tricks with
the plane surface address and x/y offsets.

A few caveats apply:
* linear buffers need the fb stride to be page aligned, as
  otherwise the remapped lines wouldn't start at the same
  spot
* compressed buffers can't be remapped due to the new
  ccs hash mode causing the virtual address of the pages
  to affect the interpretation of the compressed data. IIRC
  the old hash was limited to the low 12 bits so if we were
  using that mode we could remap. As it stands we just refuse
  to remapp with compressed fbs.
* no remapping gen2/3 as we'd need a fence for the remapped
  vma, which we currently don't have. Need to deal with the
  fence POT requirements, and do something about the gen2
  gtt page size vs tile size difference

v2: Rebase due to is_ccs_modifier()
    Fix up the skl+ stride_mult mess
    memset() the gtt_view because otherwise we could leave
    junk in plane[1] when going from 2 plane to 1 plane format
v3: intel_check_plane_stride() was split out
v4: Drop the aligned viewport stuff, it was meant for ccs which
    can't be remapped anyway
v5: Introduce intel_plane_can_remap()
    Reorder the code so that plane_state->view gets filled
    even for invisible planes, otherwise we'd keep using
    stale values and could explode during remapping. The new
    logic never remaps invisible planes since we don't have
    a viewport, and instead pins the full fb instead
v6: Fix plane src coord checks after remapping by moving
    plane_state->base.src to the final plane x/y offsets.
    Allow intel_plane_check_stride() to fail even with
    remapping (can happen at least with a linear 64bpp
    fb with a 4k plane and a suitably inconvenient src
    coordinates).
    Improve aux plane FIXME (Daniel)
    Move some code shuffling into a separate patch (Daniel)

Testcase: igt/kms_big_fb
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190509122159.24376-6-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      54d4d719
  43. 14 5月, 2019 2 次提交
  45. 06 5月, 2019 1 次提交
  47. 16 2月, 2019 1 次提交
  49. 02 1月, 2019 1 次提交
  51. 30 11月, 2018 2 次提交
    • M
      drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI · 91ba2c8b
      由 Manasi Navare 提交于 
      On Icelake, a separate power well PG2 is created for
VDSC engine used for eDP/MIPI DSI. This patch adds a new
display power domain for Power well 2.

v3:
* Call it POWER_DOMAIN_TRANSCODER_EDP_VDSC (Ville)
* Move it around TRANSCODER power domain defs (Ville)

v2:
* Fix the power well mismatch CI error (Ville)
* Rename as VDSC_PIPE_A (Imre)
* Fix a whitespace (Anusha)
* Fix Comments (Imre)

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-7-manasi.d.navare@intel.com
      91ba2c8b
    • M
      drm/i915/dp: Compute DSC pipe config in atomic check · a4a15777
      由 Manasi Navare 提交于 
      DSC params like the enable, compressed bpp, slice count and
dsc_split are added to the intel_crtc_state. These parameters
are set based on the requested mode and available link parameters
during the pipe configuration in atomic check phase.
These values are then later used to populate the remaining DSC
and RC parameters before enbaling DSC in atomic commit.

v15:
* Rebase over drm-tip
v14:
Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville)
v13:
* Compute DSC bpc only when DSC is req to be enabled (Ville)
v12:
* Override bpp with dsc dpcd color depth (Manasi)
v11:
* Const crtc_state, reject DSC on DP without FEC (Ville)
* Dont set dsc_split to false (Ville)
v10:
* Add a helper for dp_dsc support (Ville)
* Set pipe_config to max bpp, link params for DSC for now (Ville)
* Compute bpp - use dp dsc support helper (Ville)
v9:
* Rebase on top of drm-tip that now uses fast_narrow config
for edp (Manasi)
v8:
* Check for DSC bpc not 0 (manasi)

v7:
* Fix indentation in compute_m_n (Manasi)

v6 (From Gaurav):
* Remove function call of intel_dp_compute_dsc_params() and
invoke intel_dp_compute_dsc_params() in the patch where
it is defined to fix compilation warning (Gaurav)

v5:
Add drm_dsc_cfg in intel_crtc_state (Manasi)

v4:
* Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
* Add a comment why we need to check PSR while enabling DSC (Gaurav)

v3:
* Check PPR > max_cdclock to use 2 VDSC instances (Ville)

v2:
* Add if-else for eDP/DP (Gaurav)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
      a4a15777
  53. 29 11月, 2018 2 次提交
  55. 21 11月, 2018 1 次提交
  57. 16 11月, 2018 1 次提交
  59. 24 10月, 2018 1 次提交