Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 02 11月, 2018 1 次提交
    • J
      drm/i915: remove palette_offsets from device info in favor of _PICK() · 74c1e826
      由 Jani Nikula 提交于 
      The device info offset arrays for unevenly spaced register offsets is
great for widely used registers. However, the palette registers are only
used in one function, i9xx_load_luts_internal(), and only for GMCH
platforms, wasting device info. Replace palette_offsets with _PICK() in
palette register definition.

While the use of _PICK() does not check for pipe C existence, neither
does the current offset array usage, and leads to bogus address when
pipe C is passed to PALETTE() on non-CHV. Using _PICK() at least leads
to a sensible register offset, just non-existing on non-CHV. Either way,
this shouldn't happen anyway.

Remove unused old palette macros while at it.

Bloat-o-meter results below for completeness.

add/remove: 0/0 grow/shrink: 3/6 up/down: 94/-278 (-184)
Function                                     old     new   delta
i9xx_load_luts_internal                      394     483     +89
i915_driver_load                            5103    5107      +4
g4x_pre_enable_dp                            378     379      +1
intel_engines_init_mmio                     1117    1116      -1
intel_engine_lookup_user                      47      46      -1
hdmi_port_clock_valid                        310     309      -1
gen11_irq_handler                            707     706      -1
intel_device_info_dump_runtime               329     311     -18
intel_device_info_runtime_init              5166    4910    -256
Total: Before=918650, After=918466, chg -0.02%

add/remove: 0/0 grow/shrink: 0/48 up/down: 0/-576 (-576)
Data                                         old     new   delta
intel_valleyview_info                        200     188     -12
intel_skylake_gt4_info                       200     188     -12
intel_skylake_gt3_info                       200     188     -12
intel_skylake_gt2_info                       200     188     -12
intel_skylake_gt1_info                       200     188     -12
intel_sandybridge_m_gt2_info                 200     188     -12
intel_sandybridge_m_gt1_info                 200     188     -12
intel_sandybridge_d_gt2_info                 200     188     -12
intel_sandybridge_d_gt1_info                 200     188     -12
intel_pineview_info                          200     188     -12
intel_kabylake_gt3_info                      200     188     -12
intel_kabylake_gt2_info                      200     188     -12
intel_kabylake_gt1_info                      200     188     -12
intel_ivybridge_q_info                       200     188     -12
intel_ivybridge_m_gt2_info                   200     188     -12
intel_ivybridge_m_gt1_info                   200     188     -12
intel_ivybridge_d_gt2_info                   200     188     -12
intel_ivybridge_d_gt1_info                   200     188     -12
intel_ironlake_m_info                        200     188     -12
intel_ironlake_d_info                        200     188     -12
intel_icelake_11_info                        200     188     -12
intel_i965gm_info                            200     188     -12
intel_i965g_info                             200     188     -12
intel_i945gm_info                            200     188     -12
intel_i945g_info                             200     188     -12
intel_i915gm_info                            200     188     -12
intel_i915g_info                             200     188     -12
intel_i865g_info                             200     188     -12
intel_i85x_info                              200     188     -12
intel_i845g_info                             200     188     -12
intel_i830_info                              200     188     -12
intel_haswell_gt3_info                       200     188     -12
intel_haswell_gt2_info                       200     188     -12
intel_haswell_gt1_info                       200     188     -12
intel_gm45_info                              200     188     -12
intel_geminilake_info                        200     188     -12
intel_g45_info                               200     188     -12
intel_g33_info                               200     188     -12
intel_coffeelake_gt3_info                    200     188     -12
intel_coffeelake_gt2_info                    200     188     -12
intel_coffeelake_gt1_info                    200     188     -12
intel_cherryview_info                        200     188     -12
intel_cannonlake_info                        200     188     -12
intel_broxton_info                           200     188     -12
intel_broadwell_rsvd_info                    200     188     -12
intel_broadwell_gt3_info                     200     188     -12
intel_broadwell_gt2_info                     200     188     -12
intel_broadwell_gt1_info                     200     188     -12
Total: Before=195529, After=194953, chg -0.29%

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031110453.12722-1-jani.nikula@intel.com
      74c1e826
  3. 22 10月, 2018 2 次提交
  5. 12 10月, 2018 1 次提交
  7. 27 9月, 2018 2 次提交
  9. 18 8月, 2018 1 次提交
  11. 07 8月, 2018 2 次提交
  13. 01 8月, 2018 1 次提交
  15. 20 7月, 2018 1 次提交
  17. 16 7月, 2018 1 次提交
  19. 19 6月, 2018 2 次提交
  21. 24 5月, 2018 1 次提交
  23. 20 3月, 2018 1 次提交
  25. 07 3月, 2018 1 次提交
  27. 22 2月, 2018 1 次提交
  29. 16 2月, 2018 3 次提交
  31. 15 2月, 2018 1 次提交
    • R
      drm/i915/cnl: Remove alpha_support protection · ccf74400
      由 Rodrigo Vivi 提交于 
      We now have a stable cnl on our CI and it seems mostly
green without big risks of blank screen or anything
blowing up on linux installations in the future.

As a reminder i915.alpha_support was created to protect
future linux installation's iso images that might contain a
kernel from the enabling time of the new platform. Without this
protection most of linux installation was recommending
nomodeset option during installation that was getting stick
there after installation.

Specifically, alpha support says nothing about the development
state of the hardware, and everything about the state of the
driver in a kernel release.

This is semantically no different from the old
preliminary_hw_support flag, but the old one was all too often
interpreted as (preliminary hw) support instead of the intended
(preliminary) hw support, and it was misleading for everyone.
Hence the rename.

v2: Fix the typos and include more history about the parameter
rename on commit message. (Jani)

Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-cnl-y3.html
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214204205.4446-1-rodrigo.vivi@intel.com
      ccf74400
  33. 01 2月, 2018 1 次提交
  35. 31 1月, 2018 1 次提交
  37. 29 1月, 2018 1 次提交
  39. 20 1月, 2018 1 次提交
  41. 21 12月, 2017 1 次提交
  43. 01 12月, 2017 1 次提交
  45. 19 10月, 2017 1 次提交
  47. 18 10月, 2017 1 次提交
  49. 07 10月, 2017 3 次提交
  51. 05 10月, 2017 1 次提交
    • C
      drm/i915/execlists: Preemption! · beecec90
      由 Chris Wilson 提交于 
      When we write to ELSP, it triggers a context preemption at the earliest
arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
operations and the explicit MI_ARB_CHECK). If this is to the same
context, it triggers a LITE_RESTORE where the RING_TAIL is merely
updated (used currently to chain requests from the same context
together, avoiding bubbles). However, if it is to a different context, a
full context-switch is performed and it will start to execute the new
context saving the image of the old for later execution.

Previously we avoided preemption by only submitting a new context when
the old was idle. But now we wish embrace it, and if the new request has
a higher priority than the currently executing request, we write to the
ELSP regardless, thus triggering preemption, but we tell the GPU to
switch to our special preemption context (not the target). In the
context-switch interrupt handler, we know that the previous contexts
have finished execution and so can unwind all the incomplete requests
and compute the new highest priority request to execute.

It would be feasible to avoid the switch-to-idle intermediate by
programming the ELSP with the target context. The difficulty is in
tracking which request that should be whilst maintaining the dependency
change, the error comes in with coalesced requests. As we only track the
most recent request and its priority, we may run into the issue of being
tricked in preempting a high priority request that was followed by a
low priority request from the same context (e.g. for PI); worse still
that earlier request may be our own dependency and the order then broken
by preemption. By injecting the switch-to-idle and then recomputing the
priority queue, we avoid the issue with tracking in-flight coalesced
requests. Having tried the preempt-to-busy approach, and failed to find
a way around the coalesced priority issue, Michal's original proposal to
inject an idle context (based on handling GuC preemption) succeeds.

The current heuristic for deciding when to preempt are only if the new
request is of higher priority, and has the privileged priority of
greater than 0. Note that the scheduler remains unfair!

v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
Since, the feature is now conditional and not always available when we
have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
capability mask).
v3: Stylistic tweaks.
v4: Appease Joonas with a snippet of kerneldoc, only to fuel to fire of
the preempt vs preempting debate.
Suggested-by: NMichal Winiarski <michal.winiarski@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-8-chris@chris-wilson.co.uk
      beecec90
  53. 04 10月, 2017 3 次提交
  55. 03 10月, 2017 1 次提交
  57. 22 9月, 2017 1 次提交
  59. 20 9月, 2017 1 次提交