Chris Wilson writes:
> If we have no fence and desire no fence on the vma, return before we try
> and take the vm->mutex.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +++
> 1 file changed, 3 insertions(
Chris Wilson writes:
> intel_timeline_enter() has been decoupled from intel_timeline_pin() and
> both enter/exit & pin/unpin are allowed [read expected] to run
> concurrently with one another. The assertion that they had better not is
> stale.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/
Quoting Mika Kuoppala (2020-01-09 08:14:21)
> Chris Wilson writes:
>
> > intel_timeline_enter() has been decoupled from intel_timeline_pin() and
> > both enter/exit & pin/unpin are allowed [read expected] to run
> > concurrently with one another. The assertion that they had better not is
> > stal
Chris Wilson writes:
> Since we now allow the intel_context_unpin() to run unserialised, we
> risk our operations under the intel_context_lock_pinned() being run as
> the context is unpinned (and thus invalidating our state). We can
> atomically acquire the pin, testing to see if it is pinned in
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-01-09 08:14:21)
>> Chris Wilson writes:
>>
>> > intel_timeline_enter() has been decoupled from intel_timeline_pin() and
>> > both enter/exit & pin/unpin are allowed [read expected] to run
>> > concurrently with one another. The assertion that t
Chris Wilson writes:
> Quoting Tvrtko Ursulin (2020-01-08 16:19:54)
>> From: Tvrtko Ursulin
>>
>> This reverts commit 08fff7aeddc9dd72161b4c8fc27fbab12b4b9352.
>>
>> For some yet unexplained reason not having this improves stability of some
>> media workloads.
>>
>> Promise is that the media
Since we now allow the intel_context_unpin() to run unserialised, we
risk our operations under the intel_context_lock_pinned() being run as
the context is unpinned (and thus invalidating our state). We can
atomically acquire the pin, testing to see if it is pinned in the
process, thus ensuring that
Now that we have moved the runtime-pm management out of
intel_context_acctive_acquire, and that itself out of ce->ops->pin(), no
explicit runtime pm wakeref is required in intel_context_pin().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
1 file changed, 1 in
Allow for knowledgeable users to preallocate the context state, and to
separate the allocation step from the pinning step during
intel_context_pin()
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c
While this is encroaching on midlayer territory, having already made the
state allocation a previous step in pinning, we can now pull the common
intel_context_active_acquire() into intel_context_pin() itself. This is
a prelude to make the activation a separate step inside pinning, outside
of the ce
Since commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a
plain list"), we used the default embedded priotree slot for the virtual
engine request queue, which means we can also use the same solitary slot
with the scheduler. However, the priolist is expected to be guarded by
the engine->
Currently, we reset the timer after a pre-eemption event. This has the
side-effect that the timeslice runs into the second context after the
first is completed. To be more fair, we want to reset the clock after
promotion as well.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/dr
Since we now allow the intel_context_unpin() to run unserialised, we
risk our operations under the intel_context_lock_pinned() being run as
the context is unpinned (and thus invalidating our state). We can
atomically acquire the pin, testing to see if it is pinned in the
process, thus ensuring that
Now that we have moved the runtime-pm management out of
intel_context_acctive_acquire, and that itself out of ce->ops->pin(), no
explicit runtime pm wakeref is required in intel_context_pin().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
1 file changed, 1 in
While this is technically the batch as executed by the HW (in part at
least), it is confusing, and only used for a minority of gen.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/
In order to support out-of-line error capture, we need to remove the
active request from HW and put it to one side while a worker compresses
and stores all the details associated with that request. (As that
compression may take an arbitrary user-controlled amount of time, we
want to let the engine
In the near future, we will want to start a GPU error capture from a new
context, from inside the softirq region of a forced preemption. To do
so requires us to break up the monolithic error capture to provide new
entry points with finer control; in particular focusing on one
engine/gt, and being a
Currently, we skip error capture upon forced preemption. We apply forced
preemption when there is a higher priority request that should be
running but is being blocked, and we skip inline error capture so that
the preemption request is not further delayed by a user controlled
capture -- extending t
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
The list of requests from after the hang tells little about the hang
itself, only how busy userspace was after the fact. As it pertains
nothing to the HW state, drop it from the error state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 75 +++
d
While this is encroaching on midlayer territory, having already made the
state allocation a previous step in pinning, we can now pull the common
intel_context_active_acquire() into intel_context_pin() itself. This is
a prelude to make the activation a separate step inside pinning, outside
of the ce
Allow for knowledgeable users to preallocate the context state, and to
separate the allocation step from the pinning step during
intel_context_pin()
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c
We cache the user's vma for a brief period of time after they close them
so that if they are immediately reopened we avoid having to unbind and
rebind them. This happens quite frequently for display servers which
only keep a client's frame open for as long as they are copying from it,
and so they o
The shadow ring regs (ring->head, ring->tail) are meaningless in the
post-mortem dump as they do not related to anything on HW. Remove them
from the coredump.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 5 -
drivers/gpu/drm/i915/i915_gpu_error.h | 4
2 files
Chris Wilson writes:
> The shadow ring regs (ring->head, ring->tail) are meaningless in the
> post-mortem dump as they do not related to anything on HW. Remove them
> from the coredump.
We have been dumping these just to check that our bookkeepping matches?
-Mika
>
> Signed-off-by: Chris Wilson
Chris Wilson writes:
> While this is technically the batch as executed by the HW (in part at
> least), it is confusing, and only used for a minority of gen.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 --
> 1 file changed, 2 de
Quoting Mika Kuoppala (2020-01-09 09:04:31)
> Chris Wilson writes:
>
> > The shadow ring regs (ring->head, ring->tail) are meaningless in the
> > post-mortem dump as they do not related to anything on HW. Remove them
> > from the coredump.
>
> We have been dumping these just to check that our bo
On Wed, 08 Jan 2020, "Souza, Jose" wrote:
> On Wed, 2020-01-08 at 08:21 -0800, José Roberto de Souza wrote:
>> On Tue, 2020-01-07 at 07:13 +, Patchwork wrote:
>> > == Series Details ==
>> >
>> > Series: drm/i915/display: Force the state compute phase once to
>> > enable PSR (rev4)
>> > URL
On Wed, 08 Jan 2020, Manasi Navare wrote:
> Link has not been trained during connector initialization
> hence reset the variable intel_dp->link_trained. This
> avoids accidently calling link training routine before the pipe
> is set up.
>
> Issue: https://gitlab.freedesktop.org/drm/intel/issues/58
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev4)
URL : https://patchwork.freedesktop.org/series/69290/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M]
== Series Details ==
Series: series starting with [1/2] drm/i915: Early return for no-op
i915_vma_pin_fence()
URL : https://patchwork.freedesktop.org/series/71772/
State : failure
== Summary ==
Applying: drm/i915: Early return for no-op i915_vma_pin_fence()
Using index info to reconstruct a b
On Wed, 08 Jan 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2020-01-08 14:33:22)
>> On Tue, 07 Jan 2020, Chris Wilson wrote:
>> > Quoting Souza, Jose (2020-01-07 14:01:40)
>> >> On Tue, 2020-01-07 at 16:03 +0300, Dan Carpenter wrote:
>> >> > There is a cut and paste bug so we return the wrong
== Series Details ==
Series: drm/i915: Revert "drm/i915/tgl: Wa_1607138340"
URL : https://patchwork.freedesktop.org/series/71774/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7705 -> Patchwork_16031
Summary
---
**SU
== Series Details ==
Series: series starting with [1/9] drm/i915/sdvo: Reduce the size of the on
stack buffers
URL : https://patchwork.freedesktop.org/series/71775/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ac1818fd99c9 drm/i915/sdvo: Reduce the size of the on stack buffer
On Wed, Jan 08, 2020 at 02:52:02PM +0200, Jani Nikula wrote:
> On Mon, 06 Jan 2020, Pankaj Bharadiya
> wrote:
> > Device specific WARN* calls include device information in the
> > backtrace, so we know what device the warnings originate from.
> >
> > Covert all the calls of WARN* with device spec
On Wed, 2020-01-08 at 09:16 -0800, Matt Roper wrote:
> On Wed, Jan 08, 2020 at 02:26:50PM +0200, Stanislav Lisovskiy wrote:
> > There seems to be some undocumented bandwidth
> > bottleneck/dependency which scales with CDCLK,
> > causing FIFO underruns when CDCLK is too low,
> > even when it's corre
On 08.01.2020 19:07, Peter Zijlstra wrote:
> On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
>>
>> Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
>> processes. For backward compatibility reasons access to perf_events
>> subsystem remains open for CAP_SYS_ADM
This series contains basic cmd mode enablemnet patches.
This version fixes a compilation warning on patch-5 of v5.
Vandita Kulkarni (9):
drm/i915/dsi: Configure transcoder operation for command mode.
drm/i915/dsi: Add vblank calculation for command mode
drm/i915/dsi: Add cmd mode flags in di
On Wed, 08 Jan 2020, Manasi Navare wrote:
> Link has not been trained during connector initialization
> hence reset the variable intel_dp->link_trained. This
> avoids accidently calling link training routine before the pipe
> is set up.
>
> Issue: https://gitlab.freedesktop.org/drm/intel/issues/58
Transcoder timing calculation differ for command mode.
v2: Use is_vid_mode, and use same I915_WRITE (Jani)
v3: Adjust the calculations to reflect dsc compression ratio
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 52 +-
1 file changed, 35
In TE Gate mode, on every flip we need to set the
frame update request bit. After this bit is set
transcoder hardware will automatically send the
frame data to the panel when it receives the TE event.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 26
Adding TE flags and periodic command mode flags
as part of private flags to indicate what TE interrupts
we would be getting instead of vblanks in case of mipi dsi
command mode.
v2: Add TE flag description (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/
On dsi cmd mode we do not receive vblanks instead
we would get TE and these flags indicate TE is expected on
which port.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/display
If the GOP has programmed periodic command mode,
we need to disable that which would need a
deconfigure and configure sequence.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/
Clear the DSI IIR as part of interrupt configuration.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 028d4d66da8a..fabba515c274 100644
--- a/drive
Configure the transcoder to operate in TE GATE command mode
and take TE events from GPIO.
Also disable the periodic command mode, that GOP would have
programmed.
v2: Disable util pin (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 52
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
v2: Pass only relevant masked bits to the handler (Jani)
v3: Fix the check for cmd mode in TE handler function.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 64 +
We need to configure TE interrupt in two places.
Port interrupt and DSI interrupt mask registers.
v2: Hide the private flags check inside configure_te (Jani)
v3: Fix the position of masking de_port_masked for DSI_TE.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 55
== Series Details ==
Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL
URL : https://patchwork.freedesktop.org/series/71760/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7703_full -> Patchwork_16024_full
Summar
== Series Details ==
Series: series starting with [1/9] drm/i915/sdvo: Reduce the size of the on
stack buffers
URL : https://patchwork.freedesktop.org/series/71775/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7705 -> Patchwork_16032
=
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 21 -
drivers/gpu/drm/i915/selftests/i915_active.c | 46 +
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc:
== Series Details ==
Series: drm/i915/dp: Reset intel_dp->link_trained in init_connector
URL : https://patchwork.freedesktop.org/series/71801/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7705 -> Patchwork_16033
Summary
--
When port is disabled due to modeset or DPMS off actually
it disables the HDCP encryption keeping its state to
CP_ENABLED this doesn't enable HDCP again while port
gets enable again. HDCP state should set accordingly
when port is disabled.
v2: Incorporated the necessary locking and making sure
== Series Details ==
Series: drm/i915: Pin the context as we work on it (rev2)
URL : https://patchwork.freedesktop.org/series/71700/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7706 -> Patchwork_16034
Summary
---
*
On 2020-01-09 at 18:25:08 +0530, Anshuman Gupta wrote:
> When port is disabled due to modeset or DPMS off actually
> it disables the HDCP encryption keeping its state to
s/state/"content protection property as"
> CP_ENABLED.
> this doesn't enable HDCP again while port
> gets enable again.
Since the
Hi Dave & Daniel,
Happy New Year, now back from the holiday break.
A bunch of important fixes. Further fixes for the power/perf
regressions caused by the past security fixes. Then fix for
user reported GPU hang regression. Revert to avoid screen flicker
caused by HDA audio. Then missing two W/A a
Quoting Joonas Lahtinen (2020-01-09 15:34:58)
> Hi Dave & Daniel,
>
> Happy New Year, now back from the holiday break.
>
> A bunch of important fixes. Further fixes for the power/perf
> regressions caused by the past security fixes. Then fix for
> user reported GPU hang regression. Revert to avoi
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gt: Push context state
allocation earlier
URL : https://patchwork.freedesktop.org/series/71808/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7706 -> Patchwork_16035
==
From: Vanshidhar Konda
Add a method that uses the XY_SRC_COPY_BLT instruction for copying
buffers using the blitter engine.
v2: Use uint32_t for parameters; fix stride for Gen2/3
v3: Taken over from Vanshi by Janusz,
- skip upper bits of src and dst addresses on Gen < 8
Signed-off-by: Vanshid
On future hardware with missing GGTT BAR we won't be able to exercise
dma-buf access via that path. An alternative to basic-gtt subtest for
testing dma-buf access is required, as well as basic-fence-mmap and
coherency-gtt subtest alternatives for testing WC coherency.
Access to the dma sg list fe
On future hardware with missing GGTT BAR we won't be able to exercise
dma-buf access via that path. An alternative to basic-gtt subtest for
testing dma-buf access is required, as well as basic-fence-mmap and
coherency-gtt subtest alternatives for testing WC coherency.
Access to the dma sg list fe
This replaces the printk and struct device based logging macros with the
new struct drm_device style based logging macros i915/intel_device_info.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_device_info.c | 25 +---
1 file changed, 14 insertions(+), 11 deleti
Fix build error:
drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings:
drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error:
implicit declaration of function wbinvd_on_all_cpus; did you mean
wrmsr_on_cpus? [-Werror=implicit-function-declaration]
wbinvd_on_all_cpus();
Replace the use of printk based logging macros with the struct
drm_device based macros in i915/i915_vgpu.c
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/i915_vgpu.c | 41 +++-
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915
On 2020/1/8 21:44, Jani Nikula wrote:
> On Wed, 08 Jan 2020, Chen Zhou wrote:
>> Fix build error:
>> lib/crypto/chacha.c: In function chacha_permute:
>> lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger
>> than 2048 bytes [-Wframe-larger-than=]
>> }
>> ^
>
> IMO this n
This patchset continues the conversion to using the new struct
drm_device based logging macros in drm/i915.
Wambui Karuga (5):
drm/i915: conversion to new logging macros in i915/i915_vgpu.c
drm/i915: conversion to new logging macros in i915/intel_csr.c
drm/i915: conversion to new logging mac
Replace the use of printk based logging macros with the new struct
drm_device based logging macro in i915/intel_memory_region.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
This converts the use of printk based logging macros in i915/intel_gvt.c
with the new struct drm_device based logging macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_gvt.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
Replace the use of printk and struct device based logging macros with
the new struct drm_device based logging macros in i915/intel_csr.c
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_csr.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git
Hi Takashi
Is the attachment what you suspect? That merged to our kernel v4.19 already,
have any suggestions? Thanks.
-Original Message-
From: Takashi Iwai
Sent: Wednesday, January 8, 2020 2:57 AM
To: Nathan Ciobanu
Cc: Kao. Lucien (TPE) ; Cheng. AJ (TPE)
; intel-gfx@lists.freedeskto
Fix build error:
lib/crypto/chacha.c: In function chacha_permute:
lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger than
2048 bytes [-Wframe-larger-than=]
}
^
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 +
1 file chan
Quite understandably, we bug out when asked to find a page that doesn't
belong to the object. However, we should report the error back to the
user long before we attempt the out-of-bound access! In this case, it is
insufficient validation on the rotated vma, with the simplest/cheapest
point for us
== Series Details ==
Series: drm/i915: Fix MST disable sequence (rev2)
URL : https://patchwork.freedesktop.org/series/71767/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7703_full -> Patchwork_16027_full
Summary
---
Quoting Janusz Krzysztofik (2020-01-09 14:01:24)
> From: Vanshidhar Konda
>
> Add a method that uses the XY_SRC_COPY_BLT instruction for copying
> buffers using the blitter engine.
>
> v2: Use uint32_t for parameters; fix stride for Gen2/3
> v3: Taken over from Vanshi by Janusz,
> - skip upper
On Thu, Jan 09, 2020 at 02:11:52PM +, Chris Wilson wrote:
> Quite understandably, we bug out when asked to find a page that doesn't
> belong to the object. However, we should report the error back to the
> user long before we attempt the out-of-bound access! In this case, it is
> insufficient v
Quoting Janusz Krzysztofik (2020-01-09 14:01:25)
> On future hardware with missing GGTT BAR we won't be able to exercise
> dma-buf access via that path. An alternative to basic-gtt subtest for
> testing dma-buf access is required, as well as basic-fence-mmap and
> coherency-gtt subtest alternative
If the current eDP link rate, as read from hw, provides a
higher bandwidth than the standard link rates, then add the
current link rate to the link_rates array for consideration
in future mode-sets.
These initial current eDP link settings have been set up by
firmware during boot, so they should wo
On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
>
> These initial current eD
Hi Chris,
On Thu, Jan 09, 2020 at 08:58:35AM +, Chris Wilson wrote:
> In the near future, we will want to start a GPU error capture from a new
> context, from inside the softirq region of a forced preemption. To do
> so requires us to break up the monolithic error capture to provide new
> entr
On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array
On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
wrote:
>
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
>
> These initial current eDP link s
Quoting Andi Shyti (2020-01-09 15:31:15)
> Hi Chris,
>
> On Thu, Jan 09, 2020 at 08:58:35AM +, Chris Wilson wrote:
> > In the near future, we will want to start a GPU error capture from a new
> > context, from inside the softirq region of a forced preemption. To do
> > so requires us to break
== Series Details ==
Series: drm/i915: Pass cpu_transcoder to assert_pipe_disabled() always
URL : https://patchwork.freedesktop.org/series/71768/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7703_full -> Patchwork_16028_full
===
Hi Chris,
> > > In the near future, we will want to start a GPU error capture from a new
> > > context, from inside the softirq region of a forced preemption. To do
> > > so requires us to break up the monolithic error capture to provide new
> > > entry points with finer control; in particular foc
On Thu, Jan 9, 2020 at 4:27 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for cons
On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > firmware chooses link settings at boot
On Thu, Jan 09, 2020 at 05:38:15PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > If the current eDP link rate, as read from hw, provides a
> > > higher bandwidth than the standard
On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher wrote:
> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> wrote:
> >
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consider
On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä
> wrote:
>
> > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > > The panel reports 10 bpc color d
There seems to be some undocumented bandwidth
bottleneck/dependency which scales with CDCLK,
causing FIFO underruns when CDCLK is too low,
even when it's correct from BSpec point of view.
Currently for TGL platforms we calculate
min_cdclk initially based on pixel_rate divided
by 2, accounting for
On Thu, Jan 09, 2020 at 06:58:16PM +0200, Stanislav Lisovskiy wrote:
> There seems to be some undocumented bandwidth
> bottleneck/dependency which scales with CDCLK,
> causing FIFO underruns when CDCLK is too low,
> even when it's correct from BSpec point of view.
>
> Currently for TGL platforms w
On Thu, 09 Jan 2020, Stanislav Lisovskiy wrote:
> There seems to be some undocumented bandwidth
> bottleneck/dependency which scales with CDCLK,
> causing FIFO underruns when CDCLK is too low,
> even when it's correct from BSpec point of view.
>
> Currently for TGL platforms we calculate
> min_cdc
On Thu, Jan 09, 2020 at 06:58:16PM +0200, Stanislav Lisovskiy wrote:
> There seems to be some undocumented bandwidth
> bottleneck/dependency which scales with CDCLK,
> causing FIFO underruns when CDCLK is too low,
> even when it's correct from BSpec point of view.
>
> Currently for TGL platforms w
In the near future, we will want to start a GPU error capture from a new
context, from inside the softirq region of a forced preemption. To do
so requires us to break up the monolithic error capture to provide new
entry points with finer control; in particular focusing on one
engine/gt, and being a
While this is technically the batch as executed by the HW (in part at
least), it is confusing, and only used for a minority of gen.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/d
On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > > On T
== Series Details ==
Series: series starting with [01/14] drm/i915/gt: Push context state allocation
earlier
URL : https://patchwork.freedesktop.org/series/71809/
State : failure
== Summary ==
Applying: drm/i915/gt: Push context state allocation earlier
Using index info to reconstruct a base
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev5)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9ee67cfb4bda drm/i915/dsi: Configure transcoder operation for command mode.
9d1777f786fa drm/i915/dsi: Add v
1 - 100 of 134 matches
Mail list logo
