Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 12月, 2018 3 次提交
  3. 17 12月, 2018 1 次提交
    • M
      drm/i915/dsc: Add Per connector debugfs node for DSC support/enable · e845f099
      由 Manasi Navare 提交于 
      DSC can be supported per DP connector. This patch adds a per connector
debugfs node to expose DSC support capability by the kernel.
The same node can be used from userspace to force DSC enable.

force_dsc_en written through this debugfs node is used to force
DSC even for lower resolutions.

Credits to Ville Syrjala for suggesting the proper locks to be used
and to Lyude Paul for explaining how to use them in this context

v8:
* Add else if (ret) for drm_modeset_lock (Lyude)
v7:
* Get crtc, crtc_state from connector atomic state
and add proper locks and backoff (Ville, Chris Wilson, Lyude)
(Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>)
* Use %zu for printing size_t variable (Lyude)
v6:
* Read fec_capable only for non edp (Manasi)
v5:
* Name it dsc sink support and also add
fec support in the same node (Ville)
v4:
* Add missed connector_status check (Manasi)
* Create i915_dsc_support node only for Gen >=10 (manasi)
* Access intel_dp->dsc_dpcd only if its not NULL (Manasi)
v3:
* Combine Force_dsc_en with this patch (Ville)
v2:
* Use kstrtobool_from_user to avoid explicit error checking (Lyude)
* Rebase on drm-tip (Manasi)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206005407.4698-1-manasi.d.navare@intel.com
      e845f099
  5. 14 12月, 2018 1 次提交
    • C
      drm/i915: Fix Cherryview oops on boot · a4893349
      由 Chris Wilson 提交于 
      Do not dereference the LUT blob before checking whether that blob
exists. Or else,

<1>[   13.978684] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
<6>[   13.978718] PGD 0 P4D 0
<4>[   13.978733] Oops: 0000 [#1] PREEMPT SMP PTI
<4>[   13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted 4.20.0-rc5-CI-CI_DRM_5294+ #1
<4>[   13.978773] Hardware name:  /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016
<4>[   13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915]
<4>[   13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02 00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48> 8b 50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75
<4>[   13.979001] RSP: 0018:ffffc9000026f840 EFLAGS: 00010246
<4>[   13.979018] RAX: 0000000000000000 RBX: ffff888165500000 RCX: 7885fe6200000000
<4>[   13.979039] RDX: 0000000000000020 RSI: ffff88816553a008 RDI: ffff888165464a88
<4>[   13.979060] RBP: ffff888165464a88 R08: 000000000ed0e429 R09: 0000000000000001
<4>[   13.979080] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000004000
<4>[   13.979101] R13: 0000000000004000 R14: ffff888165500000 R15: ffff888165464a88
<4>[   13.979122] FS:  00007fb69c4f3540(0000) GS:ffff88817ba00000(0000) knlGS:0000000000000000
<4>[   13.979146] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   13.979163] CR2: 0000000000000048 CR3: 000000016d7fa000 CR4: 00000000001006f0
<4>[   13.979184] Call Trace:
<4>[   13.979302]  intel_update_crtc+0x18f/0x2b0 [i915]
<4>[   13.979421]  intel_update_crtcs+0x49/0x60 [i915]
<4>[   13.979538]  intel_atomic_commit_tail+0x1ea/0xd70 [i915]
<4>[   13.979657]  ? intel_atomic_commit_ready+0x3f/0x50 [i915]
<4>[   13.979762]  ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
<4>[   13.979884]  intel_atomic_commit+0x244/0x330 [i915]
<4>[   13.980002]  intel_initial_commit+0xb6/0x140 [i915]
<4>[   13.980127]  intel_modeset_init+0x7a1/0x1880 [i915]
<4>[   13.980235]  i915_driver_load+0xcbb/0x15c0 [i915]
<4>[   13.980257]  ? __pm_runtime_resume+0x4f/0x80
<4>[   13.980277]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
<4>[   13.980296]  ? lockdep_hardirqs_on+0xe0/0x1b0
<4>[   13.980401]  i915_pci_probe+0x29/0xa0 [i915]
<4>[   13.980421]  pci_device_probe+0xa1/0x130
<4>[   13.980440]  really_probe+0xf3/0x3e0
<4>[   13.980456]  driver_probe_device+0x10a/0x120
<4>[   13.980474]  __driver_attach+0xdb/0x100
<4>[   13.980489]  ? driver_probe_device+0x120/0x120
<4>[   13.980505]  ? driver_probe_device+0x120/0x120
<4>[   13.980522]  bus_for_each_dev+0x74/0xc0
<4>[   13.980539]  bus_add_driver+0x15f/0x250
<4>[   13.980554]  ? 0xffffffffa0348000
<4>[   13.980568]  driver_register+0x56/0xe0
<4>[   13.980583]  ? 0xffffffffa0348000
<4>[   13.980597]  do_one_initcall+0x58/0x2e0
<4>[   13.980615]  ? do_init_module+0x1d/0x1ea
<4>[   13.980631]  ? rcu_read_lock_sched_held+0x6f/0x80
<4>[   13.980649]  ? kmem_cache_alloc_trace+0x264/0x290
<4>[   13.980668]  do_init_module+0x56/0x1ea
<4>[   13.980685]  load_module+0x227a/0x29c0
<4>[   13.980715]  ? __se_sys_finit_module+0xd3/0xf0
<4>[   13.980731]  __se_sys_finit_module+0xd3/0xf0
<4>[   13.980756]  do_syscall_64+0x55/0x190
<4>[   13.980772]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[   13.980789] RIP: 0033:0x7fb69c019839
<4>[   13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
<4>[   13.980851] RSP: 002b:00007ffdc112e3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
<4>[   13.980875] RAX: ffffffffffffffda RBX: 000055c689fe0b30 RCX: 00007fb69c019839
<4>[   13.980895] RDX: 0000000000000000 RSI: 000055c689a05d2e RDI: 0000000000000000
<4>[   13.980916] RBP: 000055c689a05d2e R08: 0000000000000000 R09: 0000000000000000
<4>[   13.980936] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
<4>[   13.980957] R13: 000055c689fe0c60 R14: 0000000000040000 R15: 000055c689fe0b30
<4>[   13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers
<4>[   13.981027] CR2: 0000000000000048

Fixes: 302da0cd ("drm/i915: Use intel_ types more consistently for color management code (v2)")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213161241.3461-1-chris@chris-wilson.co.uk
      a4893349
  7. 13 12月, 2018 8 次提交
  9. 12 12月, 2018 3 次提交
    • B
      drm/i915: DFSM pipe disable is valid from gen9 onwards (v2) · bea68f4a
      由 Bob Paauwe 提交于 
      It's not just GEN9 platforms that allow for pipes to be disabled via
the DFSM register, but all later platforms as well.

v2: drop pointless parentheses (Ville)
Signed-off-by: NBob Paauwe <bob.j.paauwe@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181211192545.140081-1-bob.j.paauwe@intel.com
      bea68f4a
    • M
      drm/i915: Switch to level-based DDB allocation algorithm (v5) · d8e87498
      由 Matt Roper 提交于 
      The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up.  It turns out that this proportional
allocation approach is overly-generous with the larger planes and can
leave very small planes wthout a big enough allocation to even hit their
level 0 watermark requirements (especially on APL, which has a smaller
DDB in general than other gen9 platforms).  Or there can be situations
where the smallest planes hit a lower watermark level than they should
have been able to hit with a more equitable division of DDB blocks, thus
limiting the overall system sleep state that can be achieved.

The bspec now describes an alternate algorithm that can be used to
overcome these types of issues.  With the new algorithm, we calculate
all plane watermark values for all wm levels first, then go back and
partition a pipe's DDB space second.  The DDB allocation will calculate
what the highest watermark level that can be achieved on *all* active
planes, and then grant the blocks necessary to hit that level to each
plane.  Any remaining blocks are then divided up proportionally
according to data rate, similar to the old algorithm.

There was a previous attempt to implement this algorithm a couple years
ago in bb9d85f6 ("drm/i915/skl: New ddb allocation algorithm"), but
some regressions were reported, the patch was reverted, and nobody
ever got around to figuring out exactly where the bug was in that
version.  Our watermark code has evolved significantly in the meantime,
but we're still getting bug reports caused by the unfair proportional
algorithm, so let's give this another shot.

v2:
 - Make sure cursor allocation stays constant and fixed at the end of
   the pipe allocation.
 - Fix some watermark level iterators that weren't handling the max
   level.

v3:
 - Ensure we don't leave any DDB blocks unused by using DIV_ROUND_UP+min
   to calculate the extra blocks for each plane.  (Ville)
 - Replace a while() loop with a for() loop to be more consistent with
   surrounding code.  (Ville)
 - Clean unattainable watermark levels with memset rather than directly
   clearing the member fields.  Also do the same for the transition
   watermark values if they can't be achieved.  (Ville)
 - Drop min_disp_buf_needed calculations in skl_compute_plane_wm() since
   the results are no longer needed or used.  (Ville)
 - Drop skl_latency[0] != 0 sanity check; both watermark methods already
   account for an invalid 0 latency by returning FP_16_16_MAX.  (Ville)

v4:
 - Break DDB allocation loop when total_data_rate=0 rather than
   alloc_size=0.  If total_data_rate has dropped to 0, all remaining
   planes are disabled, which isn't true for alloc_size (we might just
   have not had any remaining blocks to hand out).  Plus
   total_data_rate=0 is the case we need to avoid to a prevent a
   div-by-0.  (Ville)
 - s/DIV_ROUND_UP/DIV64_U64_ROUND_UP/ to prevent 32-bit breakage (Ville)

v5:
 - Don't forget to move 'start' pointer forward for UV surface when
   setting plane DDB boundaries.  (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458Signed-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/20181211173107.11068-2-matthew.d.roper@intel.com
      d8e87498
    • M
      drm/i915: Don't use DDB allocation when choosing gen9 watermark method · 9343bb24
      由 Matt Roper 提交于 
      The bspec gives an if/else chain for choosing whether to use "method 1"
or "method 2" for calculating the watermark "Selected Result Blocks"
value for a plane.  One of the branches of the if chain is:

        "Else If ('plane buffer allocation' is known and (plane buffer
        allocation / plane blocks per line) >=1)"

Since our driver currently calculates DDB allocations first and the
actual watermark values second, the plane buffer allocation is known at
this point in our code and we include this test in our driver's logic.
However we plan to soon move to a "watermarks first, ddb allocation
second" sequence where we won't know the DDB allocation at this point.
Let's drop this arm of the if/else statement (effectively considering
the DDB allocation unknown) as an independent patch so that any
regressions can be more accurately bisected to either the different
watermark value (in this patch) or the new DDB allocation (in the next
patch).
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/20181211173107.11068-1-matthew.d.roper@intel.com
      9343bb24
  11. 11 12月, 2018 3 次提交
  13. 08 12月, 2018 3 次提交
  15. 07 12月, 2018 9 次提交
  17. 06 12月, 2018 7 次提交
  19. 05 12月, 2018 2 次提交