Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 11月, 2017 1 次提交
  3. 14 11月, 2017 1 次提交
  5. 13 11月, 2017 2 次提交
  7. 11 11月, 2017 1 次提交
  9. 10 11月, 2017 1 次提交
    • V
      drm/i915: Nuke intel_digital_port->port · 8f4f2797
      由 Ville Syrjälä 提交于 
      Remove intel_digital_port->port and replace its users with
intel_encoder->port. intel_encoder->port is a superset of
intel_digital_port->port, and it works correctly even for
MST encoders.

v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK)

Performed with cocci:
@@
@@
struct intel_digital_port {
       ...
-       enum port port;
       ...
}

@@
struct intel_digital_port *D;
expression E;
@@
- D->port = E;

@@
struct intel_digital_port *D;
@@
- D->port
+ D->base.port

@
expression E;
@@
(
- dp_to_dig_port(E)->port
+ dp_to_dig_port(E)->base.port
|
- enc_to_dig_port(E)->port
+ to_intel_encoder(E)->port
)

@@
expression E;
@@
- to_intel_encoder(&E->base)
+ E

@@
struct intel_digital_port *D;
identifier I, M;
@@
  I = &D->base
<...
(
- D->base.M
+ I->M
|
- &D->base
+ I
)
...>

@@
identifier D;
expression E;
identifier M;
@@
 D = enc_to_dig_port(&E->base)
<...
(
- D->base.M
+ E->M
|
- &D->base
+ E
)
...>

@@
identifier D, DP;
expression E;
identifier M;
@@
 DP = enc_to_intel_dp(&E->base)
<...
(
- dp_to_dig_port(DP)->base.M
+ E->M
|
- &dp_to_dig_port(DP)->base
+ E
)
...>

@@
expression E;
identifier M;
@@
(
- enc_to_dig_port(&E->base)->base.M
+ E->M
|
- enc_to_dig_port(&E->base)->base
+ E
|
- enc_to_mst(&E->base)->primary->base.port
+ E->port
)

@@
expression E;
identifier D;
@@
- struct intel_digital_port *D = E;
... when != D

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com
      8f4f2797
  11. 31 10月, 2017 1 次提交
    • V
      drm/i915: Stop frobbing with DDI encoder->type · 7e732cac
      由 Ville Syrjälä 提交于 
      Currently the DDI encoder->type will change at runtime depending on
what kind of hotplugs we've processed. That's quite bad since we can't
really trust that that current value of encoder->type actually matches
the type of signal we're trying to drive through it.

Let's eliminate that problem by declaring that non-eDP DDI port will
always have the encoder type as INTEL_OUTPUT_DDI. This means the code
can no longer try to distinguish DP vs. HDMI based on encoder->type.
We'll leave eDP as INTEL_OUTPUT_EDP, since it'll never change and
there's a bunch of code that relies on that value to identify eDP
encoders.

We'll introduce a new encoder .compute_output_type() hook. This allows
us to compute the full output_types before any encoder .compute_config()
hooks get called, thus those hooks can rely on output_types being
correct, which is useful for cloning on oldr platforms. For now we'll
just look at the connector type and pick the correct mode based on that.
In the future the new hook could be used to implement dynamic switching
between LS and PCON modes for LSPCON.

v2: Fix BXT/GLK PPS explosion with DSI/MST encoders
v3: Avoid the PPS warn on pure HDMI/DVI DDI encoders by checking dp.output_reg
v4: Rebase
v5: Populate output_types in .get_config() rather than in the caller
v5: Split out populating output_types in .get_config() (Maarten)

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-3-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      7e732cac
  13. 27 10月, 2017 2 次提交
    • D
      drm/i915/guc: Add a second client, to be used for preemption · e12ab169
      由 Dave Gordon 提交于 
      This second client is created with priority KMD_HIGH, and marked
as preemptive. This will allow us to request preemption using GuC actions.

v2: Extract clients creation into a helper, debugfs fixups. (Michał)
Recreate doorbell on init. (Daniele)
Move clients into an array.

v3: And move clients back from an array, to get rid of the enum (Michał)

v4: Use is_high_priority, move DRM_ERROR into __create_doorbell, move
GEM_BUG_ON inside guc_clients_create (Michał)

v5: Split the BUG_ON (Michał)

v6: Cleanup after error during doorbell reinit (Michał)
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171026141737.31656-1-michal.winiarski@intel.com
      e12ab169
    • R
      drm/i915/cnl: Fix SSEU Device Status. · f8c3dcf9
      由 Rodrigo Vivi 提交于 
      CNL adds an extra register for slice/subslice information.
Although no SKU is planed with an extra slice let's already
handle this extra piece of information so we don't have the
risk in future of getting a part that might have chosen this
part of the die instead of other slices or anything like that.

Also if subslice is disabled the information of eu ack for that
is garbage, so let's skip checks for eu if subslice is disabled
as we skip the subslice if slice is disabled.

The rest is pretty much like gen9.

v2: Remove IS_CANNONLAKE from gen9 status function.

v3: Consider s_max = 6 and ss_max=4 to run over all possible
    slices and subslices possible by spec. Although no real
    hardware will have that many slices/subslices.
    To match with sseu info init.
v4: Fix offset calculation for slices 4 and 5.
    Removed Oscar's rv-b since this change also needs review.
v5: Let's consider only valid bits for SLICE*_PGCTL_ACK.
    This looks like wrong in Spec, but seems to be enough
    for now. Whenever Spec gets updated and fixed we come
    back and properly update the masks. Also add a FIXME,
    so we can revisit this later when we find some strange
    info on debugfs or when we noitce spec got updated.

Cc: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171026001546.28203-1-rodrigo.vivi@intel.com
      f8c3dcf9
  15. 18 10月, 2017 1 次提交
  17. 17 10月, 2017 6 次提交
  19. 11 10月, 2017 4 次提交
  21. 10 10月, 2017 2 次提交
  23. 07 10月, 2017 2 次提交
  25. 06 10月, 2017 1 次提交
  27. 26 9月, 2017 1 次提交
  29. 25 9月, 2017 2 次提交
  31. 22 9月, 2017 1 次提交
  33. 18 9月, 2017 3 次提交
  35. 14 9月, 2017 2 次提交
    • C
      drm/i915/execlists: Read the context-status HEAD from the HWSP · 767a983a
      由 Chris Wilson 提交于 
      The engine also provides a mirror of the CSB write pointer in the HWSP,
but not of our read pointer. To take advantage of this we need to
remember where we read up to on the last interrupt and continue off from
there. This poses a problem following a reset, as we don't know where
the hw will start writing from, and due to the use of power contexts we
cannot perform that query during the reset itself. So we continue the
current modus operandi of delaying the first read of the context-status
read/write pointers until after the first interrupt. With this we should
now have eliminated all uncached mmio reads in handling the
context-status interrupt, though we still have the uncached mmio writes
for submitting new work, and many uncached mmio reads in the global
interrupt handler itself. Still a step in the right direction towards
reducing our resubmit latency, although it appears lost in the noise!

v2: Cannonlake moved the CSB write index
v3: Include the sw/hwsp state in debugfs/i915_engine_info
v4: Also revert to using CSB mmio for GVT-g
v5: Prevent the compiler reloading tail (Mika)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Acked-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-6-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      767a983a
    • C
      drm/i915/execlists: Read the context-status buffer from the HWSP · 6d2cb5aa
      由 Chris Wilson 提交于 
      The engine provides a mirror of the CSB in the HWSP. If we use the
cacheable reads from the HWSP, we can shave off a few mmio reads per
context-switch interrupt (which are quite frequent!). Just removing a
couple of mmio is not enough to actually reduce any latency, but a small
reduction in overall cpu usage.

Much appreciation for Ben dropping the bombshell that the CSB was in the
HWSP and for Michel in digging out the details.

v2: Don't be lazy, add the defines for the indices.
v3: Include the HWSP in debugfs/i915_engine_info
v4: Check for GVT-g, it currently depends on intercepting CSB mmio
v5: Fixup GVT-g mmio path
v6: Disable HWSP if VT-d is active as the iommu adds unpredictable
memory latency. (Mika)
v7: Also markup the CSB read with READ_ONCE() as it may still be an mmio
read and we want to stop the compiler from issuing a later (v.slow) reload.
Suggested-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Acked-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913133534.26927-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      6d2cb5aa
  37. 08 9月, 2017 1 次提交
  39. 07 9月, 2017 2 次提交
  41. 18 8月, 2017 1 次提交
    • C
      drm/i915: Replace execbuf vma ht with an idr · d1b48c1e
      由 Chris Wilson 提交于 
      This was the competing idea long ago, but it was only with the rewrite
of the idr as an radixtree and using the radixtree directly ourselves,
along with the realisation that we can store the vma directly in the
radixtree and only need a list for the reverse mapping, that made the
patch performant enough to displace using a hashtable. Though the vma ht
is fast and doesn't require any extra allocation (as we can embed the node
inside the vma), it does require a thread for resizing and serialization
and will have the occasional slow lookup. That is hairy enough to
investigate alternatives and favour them if equivalent in peak performance.
One advantage of allocating an indirection entry is that we can support a
single shared bo between many clients, something that was done on a
first-come first-serve basis for shared GGTT vma previously. To offset
the extra allocations, we create yet another kmem_cache for them.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-5-chris@chris-wilson.co.uk
      d1b48c1e
  43. 15 8月, 2017 1 次提交
  45. 11 8月, 2017 1 次提交