On 2020-11-30 at 17:28:32 +0200, Imre Deak wrote:
> On Mon, Nov 30, 2020 at 02:46:46PM +0530, Anshuman Gupta wrote:
> > At usual case DC3CO exit happen automatically by DMC f/w whenever
> > PSR2 clears idle. This happens smoothly by DMC f/w to work with flips.
> > But there are certain scenario whe
TGL chrome-OS platform has observed display glitches while
display brightness is being changed rapidly.
It creates a scenario where brightness is being changed simultaneously
with display flips updates in different threads.
Brightness update requires pps_lock, current pps_lock implementation
requi
Reading backlight status from PPS register doesn't require
AUX power on the platform which has South Display Engine on PCH.
It invokes a unnecessary power well enable/disable noise.
optimize it wherever is possible.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp.c | 47 +
On 2020-11-26 at 13:07:08 +0530, Anshuman Gupta wrote:
> There can be situation when DP MST connector is created without
> mst modeset being done, in those cases connector->encoder will be
> NULL. MST connector->encoder initializes after modeset.
This patch is to reject the HDCP request on MST con
== Series Details ==
Series: Display glitches fixes (rev2)
URL : https://patchwork.freedesktop.org/series/84394/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9441 -> Patchwork_19056
Summary
---
**SUCCESS**
No reg
On 2020-12-04 at 14:32:16 +0530, Ramalingam C wrote:
> On 2020-11-26 at 13:07:08 +0530, Anshuman Gupta wrote:
> > There can be situation when DP MST connector is created without
> > mst modeset being done, in those cases connector->encoder will be
> > NULL. MST connector->encoder initializes after
Hi Tejas,
As per your request triggered resume run on RKL CI machine, the testcases which
chris mentioned were passing with this run, Please find the below logs for your
reference
Git ID : https://gitlab.freedesktop.org/drm/intel/-/issues/2743
igt@gem_exec_schedule@pi-ringfull@vcs0 :
https:/
Quoting Kattamanchi, JaswanthX (2020-12-04 09:41:17)
> Hi Tejas,
>
> As per your request triggered resume run on RKL CI machine, the testcases
> which chris mentioned were passing with this run, Please find the below logs
> for your reference
It is not particular to a testcase. HW failure rare
On Thu, 2020-12-03 at 15:53 -0800, Manasi Navare wrote:
> Even though our HW supports PSR + VRR, the available panels
> do not work reliably with PSR and VRR together. So if user
> requested VRR and is supported by HW enable that and do not
> enable PSR in that case.
>
> Cc: Ville Syrjälä
> Cc: G
== Series Details ==
Series: Display glitches fixes (rev2)
URL : https://patchwork.freedesktop.org/series/84394/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9441_full -> Patchwork_19056_full
Summary
---
**SUCCESS**
On 03/12/2020 09:59, Chris Wilson wrote:
Race the execution and interrupt handlers along a context, while
closing it at a random time.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_ctx_exec.c | 60 +++
1 file changed, 60 insertions(+
On 03/12/2020 22:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-26 16:47:03)
From: Tvrtko Ursulin
Adding any kinds of "last" abi markers is usually a mistake which I
repeated when implementing the PMU because it felt convenient at the time.
This patch marks I915_PMU_LAST as depreca
Quoting Tvrtko Ursulin (2020-12-04 10:57:52)
>
> On 03/12/2020 22:33, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-11-26 16:47:03)
> >> From: Tvrtko Ursulin
> >>
> >> Adding any kinds of "last" abi markers is usually a mistake which I
> >> repeated when implementing the PMU because it fel
On 03/12/2020 10:34, Chris Wilson wrote:
In the course of discovering and closing many races with context closure
and execbuf submission, since commit 61231f6bd056 ("drm/i915/gem: Check
that the context wasn't closed during setup") we started checking that
the context was not closed by another
Quoting Tvrtko Ursulin (2020-12-04 10:52:23)
>
> On 03/12/2020 09:59, Chris Wilson wrote:
> > Race the execution and interrupt handlers along a context, while
> > closing it at a random time.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > tests/i915/gem_ctx_exec.c | 60
On 24/11/2020 15:03, Paul Gardiner wrote:
On 23/11/2020 16:19, Jani Nikula wrote:
On Sat, 21 Nov 2020, Paul Gardiner wrote:
On 17/11/2020 14:52, Jani Nikula wrote:
On Thu, 29 Oct 2020, Paul Gardiner wrote:
I use an open source DVR called MythTV. I've just swapped from using
nvidia graphics
Race the execution and interrupt handlers along a context, while
closing it at a random time.
v2: Some comments to handwave away the knowledge of internal
implementation details.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_ctx_exec.c | 84 +
Quoting Shankar, Uma (2020-12-02 13:09:34)
>
>
> > -Original Message-
> > From: Souza, Jose
> > Sent: Wednesday, December 2, 2020 12:01 AM
> > To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> > Cc: ville.syrj...@linux.intel.com
> > Subject: Re: [v6 0/2] Re-enable FBC on TGL
> >
> >
Submitted with incorrect address of i915 list out of top of my head in
Cc:, sorry.
Janusz
On Fri, 2020-12-04 at 12:51 +0100, Janusz Krzysztofik wrote:
> We may still be interested in results of a test even if it has tainted
> the kernel. On the other hand, we need to kill the test on taint if
On Fri, 2020-12-04 at 12:06 +, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-12-04 11:51:38)
> > We may still be interested in results of a test even if it has tainted
> > the kernel. On the other hand, we need to kill the test on taint if no
> > other means of killing it on a jam is
We expose engine properties under sysfs so that the sysadmin can
configure the driver according to their requirements. We can also use
udev rules to then apply that configuration anytime a device is
reloaded. Include a udev snippet provided by Joonas as an example.
Signed-off-by: Chris Wilson
Cc:
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Chris
> Wilson
> Sent: perjantai 4. joulukuuta 2020 13.55
> To: Shankar, Uma ; Souza, Jose ;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [v6 0/2] Re-enable FBC on TGL
>
> Quoting Shankar, Uma (2020-12-02 13:09:34)
On 04/12/2020 11:27, Chris Wilson wrote:
Race the execution and interrupt handlers along a context, while
closing it at a random time.
v2: Some comments to handwave away the knowledge of internal
implementation details.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_ctx
Chris Wilson writes:
> Across a reset, we stop the engine but not the timers. This leaves a
> window where the timers have inconsistent state with the engine, but
> should only result in a spurious timeout. As we cancel the outstanding
> events, also cancel their timers.
>
> Signed-off-by: Chris
Chris Wilson writes:
> The GT and engine reset failures are completely invisible when looking at
> a trace for a bug, but are vital to understanding the incomplete flow.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c | 22 ++--
The GT and engine reset failures are completely invisible when looking at
a trace for a bug, but are vital to understanding the incomplete flow.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
d
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the con
In preparation for removing the has_initial_breadcrumb field, add a
helper function for the existing callers.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 4 ++--
drivers/gpu/
Switch off the scanout during driver unregister, so we can shutdown the
HW immediately for unbind.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 320856b66
We assume that the contents of the HWSP are lost across suspend, and so
upon resume we must restore critical values such as the timeline seqno.
Keep track of every timeline allocated that uses the HWSP as its storage
and so we can then reset all seqno values by walking that list.
Signed-off-by: Ch
Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations along fence chains, and for propagating
errors) rather than trying to detect ordinary waiters by their
functions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 25 +
When we are not using semaphores with a context/engine, we can simply
reuse the same seqno location across wraps, but we still require each
timeline to have its own address. For LRC submission, each context is
prefixed by a per-process HWSP, which provides us with a unique location
for each context
Currently we know that the timeline status page is at most a page in
size, and so we can preserve the lower 12bits of the offset when
relocating the status page in the GGTT. If we want to use a larger
object, such as the context state, we may not necessarily use a position
within the first page and
The free_list and worker was introduced in commit 5f09a9c8ab6b ("drm/i915:
Allow contexts to be unreferenced locklessly"), but subsequently made
redundant by the removal of the last sleeping lock in commit 2935ed5339c4
("drm/i915: Remove logical HW ID"). As we can now free the GEM context
immediate
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it bac
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fas
The issue with stale virtual breadcrumbs remain. Now we have the problem
that if the irq-signaler is still referencing the stale breadcrumb as we
transfer it to a new sibling, the list becomes spaghetti. This is a very
small window, but that doesn't stop it being hit infrequently. To
prevent the li
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
This improves our resilence in virtual engine scheduling, and should
eliminate the r
Relative timelines are relative to either the global or per-process
HWSP, and so we can replace the absolute addressing with store-index
variants for position invariance.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 114 ---
drivers/gpu/drm/i915/
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
This notably eliminates the race observed with intel_context_inflight in
__engine_unpark().
Closes: https://gitlab.freedesktop.or
Explicitly differentiate between the absolute and relative timelines,
and the global HWSP and ppHWSP relative offsets. When using a timeline
that is relative to a known status page, we can replace the absolute
addressing in the commands with indexed variants.
Signed-off-by: Chris Wilson
---
driv
Let's only wait for the list iterator when decoupling the virtual
breadcrumb, as the signaling of all the requests may take a long time,
during which we do not want to keep the tasklet spinning.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 ++
drivers/gpu
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtua
A quick test to verify that the backend accepts each type of timeline
and can use them to track and control request emission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 93 +
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i91
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue u
Since we wake the GT up before executing a request, and go to sleep as
soon as it is retired, the GT wake time not only represents how long the
device is powered up, but also provides a summary, albeit an overestimate,
of the device runtime (i.e. the rc0 time to compare against rc6 time).
v2: s/bu
Across a reset, we stop the engine but not the timers. This leaves a
window where the timers have inconsistent state with the engine, but
should only result in a spurious timeout. As we cancel the outstanding
events, also cancel their timers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
We currently presume that the engine reset is successful, cancelling the
expired preemption timer in the process. However, engine resets can
fail, leaving the timeout still pending and we will then respond to the
timeout again next time the tasklet fires. What we want is for the
failed engine reset
Before reseting the engine, we suspend the execution of the guilty
request, so that we can continue execution with a new context while we
slowly compress the captured error state for the guilty context. However,
if the reset fails, we will promptly attempt to reset the same request
again, and disco
The gvt component of this driver has ~120 pr_debugs, in 9 "classes".
Following model of drm.debug, add a parameter to map bits to these
classes.
In Makefile, add DYNAMIC_DEBUG_MODULE. This converts gvt's pr_debugs,
even if the rest of drm is not using CONFIG_DRM_USE_DYNAMIC_DEBUG.
Signed-off-by:
On 02/12/2020 06:03, Huang, Sean Z wrote:
From: Bommu Krishnaiah
This api allow user mode to create Protected buffer and context creation.
Signed-off-by: Bommu Krishnaiah
Cc: Telukuntla Sreedhar
Cc: Kondapally Kalyan
Cc: Gupta Anshuman
Cc: Huang Sean Z
---
drivers/gpu/drm/i915/gem/i915_
Chris Wilson writes:
> Before reseting the engine, we suspend the execution of the guilty
> request, so that we can continue execution with a new context while we
> slowly compress the captured error state for the guilty context. However,
> if the reset fails, we will promptly attempt to reset th
Chris Wilson writes:
> We currently presume that the engine reset is successful, cancelling the
> expired preemption timer in the process. However, engine resets can
> fail, leaving the timeout still pending and we will then respond to the
> timeout again next time the tasklet fires. What we want
Before reseting the engine, we suspend the execution of the guilty
request, so that we can continue execution with a new context while we
slowly compress the captured error state for the guilty context. However,
if the reset fails, we will promptly attempt to reset the same request
again, and disco
Across a reset, we stop the engine but not the timers. This leaves a
window where the timers have inconsistent state with the engine, but
should only result in a spurious timeout. As we cancel the outstanding
events, also cancel their timers.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
We currently presume that the engine reset is successful, cancelling the
expired preemption timer in the process. However, engine resets can
fail, leaving the timeout still pending and we will then respond to the
timeout again next time the tasklet fires. What we want is for the
failed engine reset
The GT and engine reset failures are completely invisible when looking at
a trace for a bug, but are vital to understanding the incomplete flow.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_reset.c | 22 ++
1 file changed, 10 inser
== Series Details ==
Series: drm/i915/gt: Add a comment about how to use udev for configuring engines
URL : https://patchwork.freedesktop.org/series/84578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9442 -> Patchwork_19057
===
On Fri, Dec 04, 2020 at 01:40:03PM +0530, Anshuman Gupta wrote:
> On 2020-11-30 at 17:28:32 +0200, Imre Deak wrote:
> > On Mon, Nov 30, 2020 at 02:46:46PM +0530, Anshuman Gupta wrote:
> > > At usual case DC3CO exit happen automatically by DMC f/w whenever
> > > PSR2 clears idle. This happens smooth
== Series Details ==
Series: series starting with [01/24] drm/i915: Disable outputs during unregister
URL : https://patchwork.freedesktop.org/series/84579/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2bae8f3c30a7 drm/i915: Disable outputs during unregister
363bb75548d1 drm/i9
== Series Details ==
Series: series starting with [01/24] drm/i915: Disable outputs during unregister
URL : https://patchwork.freedesktop.org/series/84579/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separ
On Tue, Dec 01, 2020 at 10:38:57PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2020-12-01 16:05:17)
> > On Fri, Nov 27, 2020 at 10:05:48PM +, Chris Wilson wrote:
> > > Switch off the scanout during driver unregister, so we can shutdown the
> > > HW immediately for unbind.
> > >
> > > S
On Fri, Nov 27, 2020 at 03:01:56PM +0200, Joonas Lahtinen wrote:
> + intel-gfx mailing list
>
> Quoting ira.we...@intel.com (2020-11-24 08:07:41)
> > From: Ira Weiny
> >
> > The pattern of kmap/mem*/kunmap is repeated. Use the new mem*_page()
> > calls instead.
> >
> > Cc: Patrik Jakobsson
>
Quoting Ville Syrjälä (2020-12-04 16:01:11)
> On Tue, Dec 01, 2020 at 10:38:57PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2020-12-01 16:05:17)
> > > On Fri, Nov 27, 2020 at 10:05:48PM +, Chris Wilson wrote:
> > > > Switch off the scanout during driver unregister, so we can shutdown
Switch off the scanout during driver unregister, so we can shutdown the
HW immediately for unbind.
v2: Remove the old shutdown from remove, it should now be redundant.
Signed-off-by: Chris Wilson
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 3 +--
1 file changed, 1 insertio
On 2020-11-18 at 16:42:29 +0530, Jani Nikula wrote:
> On Fri, 06 Nov 2020, Gwan-gyeong Mun wrote:
> > In order to support the PSR state of each transcoder, it adds
> > i915_psr_status to sub-directory of each transcoder.
> >
> > v2: Change using of Symbolic permissions 'S_IRUGO' to using of octal
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gt: Ignore repeated attempts to
suspend request flow across reset
URL : https://patchwork.freedesktop.org/series/84582/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6784cc924e25 drm/i915/gt: Ignore repeated a
== Series Details ==
Series: series starting with [01/24] drm/i915: Disable outputs during unregister
URL : https://patchwork.freedesktop.org/series/84579/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9442 -> Patchwork_19058
===
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gt: Ignore repeated attempts to
suspend request flow across reset
URL : https://patchwork.freedesktop.org/series/84582/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, e
I wanted to look up something and noticed the hyperlink doesn't work.
While fixing that also noticed a trivial kerneldoc comment typo in the
same section, fix that too.
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/dma-buf.rst | 2 +-
include/linux/dma-buf-map.h | 2 +-
2 fi
On 2020-11-06 at 15:44:42 +0530, Gwan-gyeong Mun wrote:
> It is a preliminary work for supporting multiple EDP PSR and
> DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> supportable PSR.
> And this moves and renames the i915_psr structure of drm_i915_private's to
> intel_dp's in
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gt: Ignore repeated attempts to
suspend request flow across reset
URL : https://patchwork.freedesktop.org/series/84582/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9442 -> Patchwork_19059
==
Experiment with how fault tolerant we are if the initial modeset fails
and we need to abort the driver load.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
dif
Experiment with how fault tolerant we are if the initial modeset fails
and we need to abort the driver load.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
dif
== Series Details ==
Series: drm/i915/gt: Add a comment about how to use udev for configuring engines
URL : https://patchwork.freedesktop.org/series/84578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9442_full -> Patchwork_19057_full
=
From: Ville Syrjälä
With GEN11_HOTPLUG_CTL_LONG_DETECT(), SHOTPLUG_CTL_DDI_HPD_LONG_DETECT()
and ICP_TC_HPD_LONG_DETECT() taking the hpd_pin as their argument
we can remove some duplication in the long_detect() switch statements.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c
Hi Landwerlin,
Thanks for your feedback, Let me check with the commit owner. And I will upload
another reversion once it's done.
Hi Krishnaiah,
May I have your comment for this? Please let me know if there is new revision
path thanks.
Best regards,
Sean
-Original Message-
From: Lio
== Series Details ==
Series: drm/i915: Disable outputs during unregister (rev2)
URL : https://patchwork.freedesktop.org/series/84371/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9444 -> Patchwork_19060
Summary
---
== Series Details ==
Series: dma-buf: Fix kerneldoc formatting
URL : https://patchwork.freedesktop.org/series/84585/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f9918c0f7808 dma-buf: Fix kerneldoc formatting
-:37: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email add
We may still be interested in results of a test even if it has tainted
the kernel. On the other hand, we need to kill the test on taint if no
other means of killing it on a jam is active.
If abort on both kernel taint or a timeout is requested, decrease all
potential timeouts significantly while
== Series Details ==
Series: dma-buf: Fix kerneldoc formatting
URL : https://patchwork.freedesktop.org/series/84585/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9444 -> Patchwork_19061
Summary
---
**FAILURE**
Se
== Series Details ==
Series: drm/i915/display: Inject a failure into the initial modeset (rev2)
URL : https://patchwork.freedesktop.org/series/84592/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9444 -> Patchwork_19062
Sum
This patch fixes the slice count computation algorithm
for calculating the slice count based on Peak pixel rate
and the max slice width allowed on the DSC engines.
We need to ensure slice count > min slice count req
as per DP spec based on peak pixel rate and that it is
greater than min slice count
== Series Details ==
Series: drm/i915: Reduce duplicated switch cases in hpd code
URL : https://patchwork.freedesktop.org/series/84593/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9444 -> Patchwork_19063
Summary
---
Closed vma are protected by the GT wakeref held as we lookup the vma, so
we know that the vma will not be freed as we process it for the execbuf.
Instead we expect to catch the closed status of the context, and simply
allow the close-race on an individual vma to be washed away.
Longer term, the GT
== Series Details ==
Series: drm/i915/display/dp: Compute the correct slice count for VDSC on DP
URL : https://patchwork.freedesktop.org/series/84599/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9444 -> Patchwork_19064
Su
On Fri, Dec 04 2020 at 08:05, Ira Weiny wrote:
> So I think I'm going to submit the base patch to Andrew today (with some
> cleanups per the comments in this thread).
Could you please base that on tip core/mm where the kmap_local() muck is
and use kmap_local() right away?
Thanks,
tglx
__
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-sp
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.
We also take care not to reprogram the source OUI i
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight fu
No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c
Reviewed-by: Rodrigo Vivi
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.
v3
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simp
Instead of using intel_panel->backlight.level, have the caller provide us
with the current panel backlight value. We'll need this for when we
separate PWM-related backlight callbacks from other means of backlight
control (like DPCD backlight controls), as the caller of each PWM callback
will be res
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting sup
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that w
== Series Details ==
Series: drm/i915/gem: Drop false !i915_vma_is_closed assertion
URL : https://patchwork.freedesktop.org/series/84602/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9444 -> Patchwork_19065
Summary
---
== Series Details ==
Series: drm/i915: Add support for Intel's eDP backlight controls (rev3)
URL : https://patchwork.freedesktop.org/series/81702/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f28a72ff60f8 drm/i915/dp: Program source OUI on eDP panels
9233620226ff drm/i915: Ren
== Series Details ==
Series: drm/i915: Disable outputs during unregister (rev2)
URL : https://patchwork.freedesktop.org/series/84371/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9444_full -> Patchwork_19060_full
Summary
-
1 - 100 of 141 matches
Mail list logo
