Quoting Fernando Pacheco (2019-04-20 00:00:15)
> GPU reset is now available with GuC enabled,
> so re-enable our check that this reset is usable
> from atomic context.
>
> Signed-off-by: Fernando Pacheco
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx m
Quoting Fernando Pacheco (2019-04-20 00:00:14)
> This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8.
>
> Signed-off-by: Fernando Pacheco
Many thanks,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Quoting Fernando Pacheco (2019-04-20 00:00:13)
> Currently we pin the GuC or HuC firmware image just
> before uploading. Perma-pin during uC initialization
> instead and use the range reserved at the top of the
> address space.
>
> Moving the firmware resulted in needing to:
> - use an additional
Quoting Fernando Pacheco (2019-04-20 00:00:12)
> GuC and HuC depend on struct_mutex for device
> reinitialization. Moving away from this dependency
> requires perma-pinning the firmware images in GGTT.
> The upper portion of the GuC address space has
> a sizeable hole (several MB) that is inaccessi
Quoting Fernando Pacheco (2019-04-20 00:00:11)
> The uC firmware init function is called during
> GuC/HuC init early phases. Rename to include "_early"
> and properly reflect which phase we are at.
>
> The uC firmware fini function is cleaning up the
> state set/created on firmware fetch. Replace
== Series Details ==
Series: Perma-pin uC firmware and re-enable global reset (rev3)
URL : https://patchwork.freedesktop.org/series/59255/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5961_full -> Patchwork_12849_full
Summ
== Series Details ==
Series: drm/i915/gtt: Skip clearing the GGTT under gen6+ full-ppgtt
URL : https://patchwork.freedesktop.org/series/59773/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5960_full -> Patchwork_12848_full
== Series Details ==
Series: Perma-pin uC firmware and re-enable global reset (rev3)
URL : https://patchwork.freedesktop.org/series/59255/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5961 -> Patchwork_12849
Summary
--
== Series Details ==
Series: Perma-pin uC firmware and re-enable global reset (rev3)
URL : https://patchwork.freedesktop.org/series/59255/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/uc: Rename uC firmware init/fini functions
Okay!
Commit:
This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/i915_reset.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 677d59304e78..1092d16c289c 100644
GuC and HuC depend on struct_mutex for device
reinitialization. Moving away from this dependency
requires perma-pinning the firmware images in GGTT.
The upper portion of the GuC address space has
a sizeable hole (several MB) that is inaccessible
by GuC. Reserve this range within GGTT as it can
comf
The intent is to move the GuC and HuC firmware images to the
top of the address space. This portion is inaccessible during
normal GuC operations and should be relatively safe to house
both firmware images. By making the move we can re-enable the
full gpu reset with GuC enabled.
Placing the firmwar
Currently we pin the GuC or HuC firmware image just
before uploading. Perma-pin during uC initialization
instead and use the range reserved at the top of the
address space.
Moving the firmware resulted in needing to:
- use an additional pinning for the rsa signature which will
be used during HuC
GPU reset is now available with GuC enabled,
so re-enable our check that this reset is usable
from atomic context.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/s
The uC firmware init function is called during
GuC/HuC init early phases. Rename to include "_early"
and properly reflect which phase we are at.
The uC firmware fini function is cleaning up the
state set/created on firmware fetch. Replace
"_fini" with "_cleanup_fetch".
v2: also rename uC fw fini
== Series Details ==
Series: drm/i915: Expose the busyspin durations for i915_wait_request (rev2)
URL : https://patchwork.freedesktop.org/series/34364/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5958_full -> Patchwork_12847_full
=
On Fri, Apr 19, 2019 at 10:12:02PM +0100, Chris Wilson wrote:
> Quoting Matt Roper (2019-04-19 22:06:05)
> > On Mon, Apr 15, 2019 at 08:12:50PM -0700, clinton.a.tay...@intel.com wrote:
> > > From: Clint Taylor
> > >
> > > Add protections to prevent NULL de-reference for a couple variables used
>
Quoting Matt Roper (2019-04-19 22:06:05)
> On Mon, Apr 15, 2019 at 08:12:50PM -0700, clinton.a.tay...@intel.com wrote:
> > From: Clint Taylor
> >
> > Add protections to prevent NULL de-reference for a couple variables used
> > in skl_check_pipe_max_pixel_clock to prevent GP exception from occurri
On Mon, Apr 15, 2019 at 08:12:50PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Add protections to prevent NULL de-reference for a couple variables used
> in skl_check_pipe_max_pixel_clock to prevent GP exception from occurring
> during some IGT tests.
>
> References: https:
== Series Details ==
Series: drm/i915/gtt: Skip clearing the GGTT under gen6+ full-ppgtt
URL : https://patchwork.freedesktop.org/series/59773/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5960 -> Patchwork_12848
Summary
--
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context (rev2)
URL : https://patchwork.freedesktop.org/series/59752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5958_full -> Patchwork_12845_full
==
If we know that the user cannot access the GGTT, by virtue of having a
segregated memory area, we can skip clearing the unused entries as they
cannot be accessed.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/
On Thu, 18 Apr 2019 10:41:42 +0200
Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
> Cc: Steven Rostedt
Reviewed-by: Steven Rostedt (VMware)
-- Steve
___
On Thu, 18 Apr 2019 10:41:43 +0200
Thomas Gleixner wrote:
> Simplify the stack retrieval code by using the storage array based
> interface.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Steven Rostedt (VMware)
-- Steve
___
Intel-gfx mailing list
Quoting Michal Wajdeczko (2019-04-17 06:39:45)
> New GuC firmwares (for SKL, BXT, KBL, ICL) with updated ABI interface.
>
> Note: For correct bisecting, patches 3-8 can be squashed, as Gen9 GuC
> support will be broken during update of GuC firmware definitions.
>
> v2: only HuC authentication is
== Series Details ==
Series: series starting with [01/10] drm/i915: Disable preemption and sleeping
while using the punit sideband
URL : https://patchwork.freedesktop.org/series/59761/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5958_full -> Patchwork_12844_full
===
== Series Details ==
Series: drm/i915: Expose the busyspin durations for i915_wait_request (rev2)
URL : https://patchwork.freedesktop.org/series/34364/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5958 -> Patchwork_12847
S
On Thu, 2019-04-18 at 22:59 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The spec has changed since skl_max_plane_width() was written.
> Now the SKL limits are lower than what they were initially, and
> GLK and ICL have different limits. Update the code to match the
> spec.
Reviewed-by:
== Series Details ==
Series: drm/i915: Expose the busyspin durations for i915_wait_request (rev2)
URL : https://patchwork.freedesktop.org/series/34364/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d77eb390e6fb drm/i915: Expose the busyspin durations for i915_wait_request
-:36:
== Series Details ==
Series: dma-buf: Remove unused sync_dump()
URL : https://patchwork.freedesktop.org/series/59765/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5958 -> Patchwork_12846
Summary
---
**FAILURE**
S
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context (rev2)
URL : https://patchwork.freedesktop.org/series/59752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5958 -> Patchwork_12845
An interesting discussion regarding "hybrid interrupt polling" for NVMe
came to the conclusion that the ideal busyspin before sleeping was half
of the expected request latency (and better if it was already halfway
through that request). This suggested that we too should look again at
our tradeoff b
sync_dump() is an unused, unexported, function that adds 64k to the
kernel image and doesn't even provide locking around the global array it
uses.
add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
Function old new delta
sync_dump
== Series Details ==
Series: series starting with [01/10] drm/i915: Disable preemption and sleeping
while using the punit sideband
URL : https://patchwork.freedesktop.org/series/59761/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5958 -> Patchwork_12844
=
== Series Details ==
Series: series starting with [01/10] drm/i915: Disable preemption and sleeping
while using the punit sideband
URL : https://patchwork.freedesktop.org/series/59761/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Disable p
== Series Details ==
Series: series starting with [01/10] drm/i915: Disable preemption and sleeping
while using the punit sideband
URL : https://patchwork.freedesktop.org/series/59761/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9a0358d2f0eb drm/i915: Disable preemption and
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimis
Quoting Fernando Pacheco (2019-04-19 18:14:21)
>
> On 4/19/19 12:14 AM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-19 00:31:48)
> >> - /* Trim the GGTT to fit the GuC mappable upper range (when
> >> enabled).
> >> -* This is easier than doing range restriction on the
On 4/19/19 12:14 AM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-19 00:31:48)
>> GuC and HuC depend on struct_mutex for device
>> reinitialization. Moving away from this dependency
>> requires perma-pinning the firmware images in GGTT.
>> The upper portion of the GuC address space has
We now have two locks for sideband access. The general one covering
sideband access across all generation, sb_lock, and a specific one
covering sideband access via the punit on vlv/chv. After lifting the
sb_lock around the punit into the callers, the pcu_lock is now redudant
and can be separated fr
With the vlv sideband fixed to avoid sleeping while we talk to the
punit, the system should be much more stable and be able to utilise the
punit without risk.
This reverts commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation
thresholds on Baytrail v3")
References: 6067a27d1f01 ("drm/i915: Av
This allows my byt-j1900 to run gem_concurrent_blit without a hard
lockup, ymmv.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Split the sideback declarations out of the ginormous i915_drv.h
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile.header-test | 1 +
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 120
drivers/gpu/drm/i915/i915_sy
While we talk to the punit over its sideband, we need to prevent the cpu
from sleeping in order to prevent a potential machine hang.
Note that by itself, it appears that pm_qos_update_request (via
intel_idle) doesn't provide a sufficient barrier to ensure that all core
are indeed awake (out of Cst
Lift the sideband acquisition for vlv_punit_read and vlv_punit_write
into their callers, so that we can lock the sideband once for a sequence
of operations, rather than perform the heavyweight acquisition on each
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c |
These routines are identical except in the nature of the value parameter.
For writes it is a pure in-param, but for a read, we need an out-param.
Since they differ in a single line, merge the two routines into one.
Signed-off-by: Chris Wilson
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/inte
As we now employ a very heavy pm_qos around the punit access, we want to
minimise the number of synchronous requests by performing one for the
whole punit sequence rather than around individual accesses. The
sideband lock is used for this, so push the pm_qos into the sideband
lock acquisition and r
Valleyview and Cherryview update the GPU frequency via the punit, which
is very expensive as we have to ensure the cores do not sleep during the
comms. If we perform frequent RPS evaluations, the frequent punit
requests cause measurable system overhead for little benefit, so
increase the evaluation
Since intel_sideband_read and intel_sideband_write differ by only a
couple of lines (depending on whether we feed the value in or out),
merge the two into a single common accessor.
v2: Restore vlv_flisdsi_read() lost during rebasing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_si
sandybride_pcode is another sideband, so move it to their new home.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/intel_hdcp.c | 1 +
drivers/gpu/drm/i915/intel_pm.c | 195 -
drivers/gpu/drm/i915/intel_sid
On Thursday, April 18, 2019 8:20 AM, Simon Ser wrote:
> On Wednesday, April 17, 2019 11:35 PM, Simon Ser cont...@emersion.fr wrote:
>
> > In terms of graphs, if a plane is a node and a two-plane overlap is an
> > edge, it means we want a complete graph (each node has an edge to all
> > other nodes
On Friday, April 19, 2019 4:16:01 AM PDT Chris Wilson wrote:
> Broadwater and the rest of gen4 do support being able to saving and
> reloading context specific registers between contexts, providing isolation
> of the basic GPU state (as programmable by userspace). This allows
> userspace to assume
On Fri, Apr 19, 2019 at 07:29:05PM +0300, Souza, Jose wrote:
> On Fri, 2019-04-19 at 19:04 +0300, Imre Deak wrote:
> > On Fri, Apr 19, 2019 at 07:02:10PM +0300, Souza, Jose wrote:
> > > On Fri, 2019-04-19 at 10:10 +0300, Imre Deak wrote:
> > > > Fix the order of lane, port parameters passed to the
On Fri, 2019-04-19 at 19:04 +0300, Imre Deak wrote:
> On Fri, Apr 19, 2019 at 07:02:10PM +0300, Souza, Jose wrote:
> > On Fri, 2019-04-19 at 10:10 +0300, Imre Deak wrote:
> > > Fix the order of lane, port parameters passed to the register
> > > macro.
> > >
> > > Note that this was already partly
On Fri, Apr 19, 2019 at 11:07:17AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 19, 2019 at 10:32:30AM +0200, Thomas Gleixner wrote:
> > On Fri, 19 Apr 2019, Peter Zijlstra wrote:
> > > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> > >
> > > > +typedef bool (*stack_trace_consume
On Fri, Apr 19, 2019 at 07:02:10PM +0300, Souza, Jose wrote:
> On Fri, 2019-04-19 at 10:10 +0300, Imre Deak wrote:
> > Fix the order of lane, port parameters passed to the register macro.
> >
> > Note that this was already partly fixed by commit
> > 37fc7845df7b6 ("drm/i915: Call MG_DP_MODE() macr
On Fri, 2019-04-19 at 10:10 +0300, Imre Deak wrote:
> Fix the order of lane, port parameters passed to the register macro.
>
> Note that this was already partly fixed by commit
> 37fc7845df7b6 ("drm/i915: Call MG_DP_MODE() macro with the right
> parameters order")
>
> Fixes: 58106b7d816e1 ("drm/i
On Fri, Apr 19, 2019 at 09:02:11AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 18, 2019 at 05:42:55PM +0200, Thomas Gleixner wrote:
> > On Thu, 18 Apr 2019, Josh Poimboeuf wrote:
>
> > > Another idea I had (but never got a chance to work on) was to extend the
> > > x86 unwind interface to all arche
== Series Details ==
Series: drm/i915: Track HAS_RPS alongside HAS_RC6 in the device info
URL : https://patchwork.freedesktop.org/series/59753/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5956_full -> Patchwork_12843_full
== Series Details ==
Series: drm/i915: Track HAS_RPS alongside HAS_RC6 in the device info
URL : https://patchwork.freedesktop.org/series/59753/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5956 -> Patchwork_12843
Summary
-
== Series Details ==
Series: drm/i915: Track HAS_RPS alongside HAS_RC6 in the device info
URL : https://patchwork.freedesktop.org/series/59753/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Track HAS_RPS alongside HAS_RC6 in the device info
For consistency (and elegance!), add intel_device_info.has_rps.
The immediate boon is that RPS support is now emitted along the other
capabilities in the debug log and after errors.
Signed-off-by: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
d
On Thu, 18 Apr 2019 10:41:41 +0200
Thomas Gleixner wrote:
> It's only used in trace.c and there is absolutely no point in compiling it
> in when user space stack traces are not supported.
>
> Signed-off-by: Thomas Gleixner
> Cc: Steven Rostedt
Funny, these were moved out to global functions a
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/59752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5956_full -> Patchwork_12842_full
=
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/59752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5956 -> Patchwork_12842
===
== Series Details ==
Series: series starting with [1/4] drm-tip: 2019y-04m-18d-17h-03m-51s UTC
integration manifest
URL : https://patchwork.freedesktop.org/series/59751/
State : failure
== Summary ==
Applying: drm-tip: 2019y-04m-18d-17h-03m-51s UTC integration manifest
Using index info to rec
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimis
Quoting Chris Wilson (2019-04-19 12:15:58)
> From: Eric Anholt
Hmm, wrong base. Apologies for the noise.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Despite what I think the prm recommends, commit f2253bd9859b
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active
Ironlake does support being able to saving and reloading context specific
registers between contexts, providing isolation of the basic GPU state
(as programmable by userspace). This allows userspace to assume that the
GPU retains their state from one batch to the next, minimising the
amount of stat
From: Eric Anholt
---
integration-manifest | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 integration-manifest
diff --git a/integration-manifest b/integration-manifest
new file mode 100644
index ..09ab7d222dde
--- /dev/null
+++ b/integratio
Despite what I think the prm recommends, commit f2253bd9859b
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimis
Ironlake does support being able to saving and reloading context specific
registers between contexts, providing isolation of the basic GPU state
(as programmable by userspace). This allows userspace to assume that the
GPU retains their state from one batch to the next, minimising the
amount of stat
On Fri, Apr 19, 2019 at 10:32:30AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Apr 2019, Peter Zijlstra wrote:
> > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> >
> > > +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr,
> > > +
== Series Details ==
Series: drm/i915/icl: Fix MG_DP_MODE() register programming
URL : https://patchwork.freedesktop.org/series/59744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5954_full -> Patchwork_12840_full
Summary
On Fri, 19 Apr 2019, Peter Zijlstra wrote:
> On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
>
> > +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr,
> > + bool reliable);
>
> > +void arch_stack_walk(stack_trace_consume_
== Series Details ==
Series: drm/i915/icl: Fix MG_DP_MODE() register programming
URL : https://patchwork.freedesktop.org/series/59744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5954 -> Patchwork_12840
Summary
---
== Series Details ==
Series: drm/i915/icl: Fix MG_DP_MODE() register programming
URL : https://patchwork.freedesktop.org/series/59744/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d26cc79d0b12 drm/i915/icl: Fix MG_DP_MODE() register programming
-:12: WARNING:COMMIT_LOG_LONG_LI
On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr,
> + bool reliable);
> +void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
> + st
Quoting Fernando Pacheco (2019-04-19 00:31:49)
> Currently we pin the GuC or HuC firmware image just
> before uploading. Perma-pin during uC initialization
> instead and use the range reserved at the top of the
> address space.
>
> Moving the firmware resulted in needing to:
> - restore the ggtt m
Please fix up the > 80 char line. Otherwise:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Fernando Pacheco (2019-04-19 00:31:48)
> GuC and HuC depend on struct_mutex for device
> reinitialization. Moving away from this dependency
> requires perma-pinning the firmware images in GGTT.
> The upper portion of the GuC address space has
> a sizeable hole (several MB) that is inaccessi
Fix the order of lane, port parameters passed to the register macro.
Note that this was already partly fixed by commit
37fc7845df7b6 ("drm/i915: Call MG_DP_MODE() macro with the right parameters
order")
Fixes: 58106b7d816e1 ("drm/i915: Make MG PHY macros semantically consistent")
Cc: José Robert
On Thu, Apr 18, 2019 at 05:42:55PM +0200, Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Josh Poimboeuf wrote:
> > Another idea I had (but never got a chance to work on) was to extend the
> > x86 unwind interface to all arches. So instead of the callbacks, each
> > arch would implement something l
85 matches
Mail list logo
