The Bspec does not mention polling the FEC Enable
Live status bit. That is only there for debug purposes.
So remove the polling from driver.
Cc: Ankit Nautiyal
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/driv
== Series Details ==
Series: drm/i915: fix error return code in check_partial_mapping()
URL : https://patchwork.freedesktop.org/series/84242/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9387 -> Patchwork_18973
Summary
---
On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge. I
Fix to return a negative error code from the error handling case
instead of 0 in function check_partial_mapping(), as done elsewhere
in this function.
Fixes: 07e98eb0a174 ("drm/i915/selftests: Tighten the timeout testing for
partial mmaps")
Reported-by: Hulk Robot
Signed-off-by: Luo Meng
---
d
On Wed, 25 Nov 2020, Miguel Ojeda wrote:
>
> The C standard has nothing to do with this. We use compiler extensions
> of several kinds, for many years. Even discounting those extensions, the
> kernel is not even conforming to C due to e.g. strict aliasing. I am not
> sure what you are trying
On Tue, 24 Nov 2020, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at
> > all ... we really shouldn't be wasting maintainer time with it because
> > it has a cost to merge. I'm not sure
On Wed, Nov 25, 2020 at 12:53 AM Finn Thain wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)
Making the kernel strictly conforming is a ship that s
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.
No, I have not said that. Please don't put words in my mouth (again).
I have said *authoring* lines of *this* kind tak
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.
There is no "language spec" the kernel adheres to. Even if it did,
kernel co
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote:
>
> What I meant was that you've used pessimism as if it was fact.
"future mistakes that it might prevent" is neither pessimism nor states a fact.
> For example, "There is no way to guess what the effect would be if the
> compiler trained program
== Series Details ==
Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
URL : https://patchwork.freedesktop.org/series/84238/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18972_full
=
Hi Aditya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.10-rc5 next-20201124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
== Series Details ==
Series: series starting with [1/4] drm/i915: Track logically enabled planes for
hw state
URL : https://patchwork.freedesktop.org/series/84230/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18970_full
Hi Aditya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.10-rc5 next-20201124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
== Series Details ==
Series: Move display initialization
URL : https://patchwork.freedesktop.org/series/84225/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18969_full
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915/gt: Limit frequency drop to RPe on parking
URL : https://patchwork.freedesktop.org/series/84223/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18967_full
Summary
Hi Josh, Kyle, Ben,
Kindly add the below i915 changes to linux-firmware.git:
The following changes since commit b362fd4cb8963ad75517dbcf424974f65a29a60e:
Mellanox: Add new mlxsw_spectrum firmware xx.2008.2018 (2020-11-24 09:55:03
-0500)
are available in the Git repository at:
git://anong
== Series Details ==
Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
URL : https://patchwork.freedesktop.org/series/84238/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
H
== Series Details ==
Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
URL : https://patchwork.freedesktop.org/series/84238/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18972
Summa
== Series Details ==
Series: drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
URL : https://patchwork.freedesktop.org/series/84238/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3f30d254dfce drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
-:60:
On 11/24/20 12:11 PM, Lucas De Marchi wrote:
> +Matt Roper, see question in item (3) below
>
> On Tue, Nov 24, 2020 at 04:20:40PM +0200, Jani Nikula wrote:
>> On Tue, 24 Nov 2020, Lucas De Marchi wrote:
>>> On Mon, Nov 23, 2020 at 05:32:22PM -0800, Aditya Swarup wrote:
On 11/18/20 1:18 AM, J
Fix TGL REVID macros to fetch correct display/gt stepping based
on SOC rev id from INTEL_REVID() macro. Previously, we were just
returning the first element of the revid array instead of using
the correct index based on SOC rev id.
Also, add array bound checks for TGL REV ID array. Since, there
mi
On Tue, Nov 17, 2020 at 10:50:24AM -0800, Aditya Swarup wrote:
From: Caz Yokoyama
The crwebview indicates on ADL-S that some of our MCHBAR
registers have moved from their traditional 0x50XX offsets to
new locations. The meaning and bit layout of the registers
remain same.
Cc: Lucas De Marchi
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work
With integrated graphics the TDP is shared between the gpu and the cpu,
knowing the total energy consumed by the package is relevant to
understanding throttling.
v2: Tidy integration by eliminating struct rapl and improve output
formatting.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
to
Follow the same pattern as rapl for imc, and consolidate everything to
work on struct pmu_counter.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 249 ++
1 file changed, 82 insertions(+), 167 deletions(-)
diff --git a/tools/in
Follow the same pattern as rapl for imc, and consolidate everything to
work on struct pmu_counter.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 249 ++
1 file changed, 82 insertions(+), 167 deletions(-)
diff --git a/tools/in
With integrated graphics the TDP is shared between the gpu and the cpu,
knowing the total energy consumed by the package is relevant to
understanding throttling.
v2: Tidy integration by eliminating struct rapl and improve output
formatting.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
to
It seems this was forgotten? We do have it for DG1, but for TGL it's not
being applied.
Lucas De Marchi
On Fri, Jul 24, 2020 at 02:21:03PM -0700, Daniele Ceraolo Spurio wrote:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
On 7/10/2020 2:32 PM, john.c.harri...@intel.com wrote:
From: John Har
== Series Details ==
Series: drm/i915/display: Record the plane update times for debugging (rev3)
URL : https://patchwork.freedesktop.org/series/84174/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/
== Series Details ==
Series: series starting with [1/4] drm/i915: Track logically enabled planes for
hw state
URL : https://patchwork.freedesktop.org/series/84230/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18970
==
On Fri, 2020-11-20 at 01:06 +0530, Uma Shankar wrote:
> There are some corner cases wrt underrun when we enable
> FBC with PSR2 on TGL. Recommendation from hardware is to
> keep this combination disabled.
>
> Bspec: 50422 HSD: 14010260002
>
> v2: Added psr2 enabled check from crtc_state (Anshuman
Hi Chris,
On Tue, Nov 24, 2020 at 06:35:21PM +, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> c
== Series Details ==
Series: series starting with [1/4] drm/i915: Track logically enabled planes for
hw state
URL : https://patchwork.freedesktop.org/series/84230/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be chec
== Series Details ==
Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
Gen 12 render compression with Clear Color
URL : https://patchwork.freedesktop.org/series/84183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9378_full -> Patchwork_18961_full
== Series Details ==
Series: series starting with [1/4] drm/i915: Track logically enabled planes for
hw state
URL : https://patchwork.freedesktop.org/series/84230/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8ed43f2396aa drm/i915: Track logically enabled planes for hw state
== Series Details ==
Series: Move display initialization
URL : https://patchwork.freedesktop.org/series/84225/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18969
Summary
---
**SUCCESS**
No regre
Hi Thomas.
Nice clean-up series - quite an effort to move one member to deprecated!
I have read through most of the patches. I left a few notes in my
replies but nothing buggy. Just nitpicks.
On Tue, Nov 24, 2020 at 12:38:09PM +0100, Thomas Zimmermann wrote:
> The pdev field in struct drm_devic
Hi Thomas,
On Tue, Nov 24, 2020 at 12:38:24PM +0100, Thomas Zimmermann wrote:
> We have DRM drivers based on USB, SPI and platform devices. All of them
> are fine with storing their device reference in struct drm_device.dev.
> PCI devices should be no exception. Therefore struct drm_device.pdev is
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:18PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert nouveau to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Ben Skeggs
Suggestion to an alternative implmentation below.
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next sca
On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge. I'm not sure we understand where the balance
> lies in value
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:14PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert gma500 to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Patrik Jakobsson
This patch includes several whitespace chang
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it so
== Series Details ==
Series: drm/i915/tgl, rkl, dg1: Apply WA_1406941453 to TGL, RKL and DG1 (rev2)
URL : https://patchwork.freedesktop.org/series/83383/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18968
== Series Details ==
Series: dma-buf/dma-resv: Respect num_fences when initializing the shared fence
list.
URL : https://patchwork.freedesktop.org/series/84210/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9383_full -> Patchwork_18966_full
===
Quoting Oliver Sang (2020-11-19 07:20:18)
> On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> > Hi,
> >
> > Could you add intel-gfx@lists.freedesktop.org into reports going
> > forward.
> >
> > Quoting kernel test robot (2020-11-11 17:58:11)
> > >
> > > Greeting,
> > >
> > > FY
== Series Details ==
Series: drm/i915/gt: Limit frequency drop to RPe on parking
URL : https://patchwork.freedesktop.org/series/84223/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18967
Summary
---
Quoting Rodrigo Vivi (2020-11-24 19:46:29)
> On Tue, Nov 24, 2020 at 06:35:21PM +, Chris Wilson wrote:
> > We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> > the frequency we intend to restart the GT with. Since the two workloads
> > are likely related (e.g. a composit
== Series Details ==
Series: drm/i915/gt: Limit frequency drop to RPe on parking
URL : https://patchwork.freedesktop.org/series/84223/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
29d842e75c62 drm/i915/gt: Limit frequency drop to RPe on parking
-:26: WARNING:BAD_SIGN_OFF: emai
From: Ville Syrjälä
Let's do the kill_bigjoiner_slave() thing from
intel_bigjoiner_add_affected_crtcs() since it's related to
what we do there. This cleans up the logic in the
compute_config() loop a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 25 ++
From: Ville Syrjälä
If either of the bigjoiner pipes needs a modeset then we need
a modeset on both pipes. Make it so.
v2: Split out the kill_bigjoiner_slave() change (Manasi)
Add affected connectors/planes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 32
From: Ville Syrjälä
drm_atomic_add_affected_planes() only considers planes which
are logically enabled in the uapi state. For bigjoiner we need
to consider planes logically enabled in the hw state. Add a
helper for that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk
From: Ville Syrjälä
Currently crtc_state->uapi.plane_mask only tracks logically
enabled planes on the uapi level. For bigjoiner purposes
we want to do the same for the hw state. Let's follow the
pattern established by active_planes & co. here.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i
+Matt Roper, see question in item (3) below
On Tue, Nov 24, 2020 at 04:20:40PM +0200, Jani Nikula wrote:
On Tue, 24 Nov 2020, Lucas De Marchi wrote:
On Mon, Nov 23, 2020 at 05:32:22PM -0800, Aditya Swarup wrote:
On 11/18/20 1:18 AM, Jani Nikula wrote:
On Tue, 17 Nov 2020, Lucas De Marchi wr
On Tue, Nov 24, 2020 at 06:35:21PM +, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> carry the fr
Quoting Lucas De Marchi (2020-11-24 19:13:16)
> Now that all display-related functions are grouped in
> i915_driver_register(), move them to display/ so we reduce the amount of
> display calls from the rest of the driver.
dsm and vgaswitcheroo are candidates as well. They are on the fine line
betw
Quoting Lucas De Marchi (2020-11-24 19:13:15)
> intel_gt_driver_register() may be called earlier than
> intel_opregion_register() and acpi_video_register(), so move it up.
>
> intel_display_debugfs_register() may be called later, together with the
> other display-related initializations. There is
Quoting Lucas De Marchi (2020-11-24 19:13:14)
> If drm_dev_register() fails there is no reason to continue registering
> the driver and initializing.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deleti
intel_gt_driver_register() may be called earlier than
intel_opregion_register() and acpi_video_register(), so move it up.
intel_display_debugfs_register() may be called later, together with the
other display-related initializations. There is a slight change in
behavior that sysfs files will show u
If drm_dev_register() fails there is no reason to continue registering
the driver and initializing.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drive
Now that all display-related functions are grouped in
i915_driver_register(), move them to display/ so we reduce the amount of
display calls from the rest of the driver.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 53
drivers/gpu/drm/i91
This reduces the surface from which display/ is called by the
other parts of the driver, starting with the init. For that new
intel_display_driver_{register,unregister} functions are created
that will deal with the HAS_DISPLAY check.
There are more changes needed, but I'm sending this early for fe
From: Swathi Dhanavanthri
This workaround is applicable only for tgl,rkl and dg1.
Bspec: 52890, 53273, 53508.
Signed-off-by: Swathi Dhanavanthri
Reviewed-by: Clint Taylor
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +---
1 file changed, 5 inse
On Mon, Nov 23, 2020 at 07:59:22PM +0200, Jani Nikula wrote:
> There are no clients passing NULL callbacks, which makes sense as it
> wouldn't even create a file. Require non-NULL callbacks, and throw away
> the handling for NULL callbacks.
Looks good,
Reviewed-by: Christoph Hellwig
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> IB/hfi1: Fix fall-through warnings for Clang
> IB/mlx4: Fix fall-through warnings for Clang
> IB/qedr: Fix fall-through warnings for Clang
> RDMA/mlx5: Fix fall-through warnings for Clang
I picked these four to the rdm
On Mon, Nov 23, 2020 at 07:59:28PM +0200, Jani Nikula wrote:
> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://li
On Mon, 23 Nov 2020, Joe Perches wrote:
> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code
> > generation. That's for the patch author and (unfortunately) for
> > reviewers.
>
> Ideally, that proof would be provided by the c
On Mon, 23 Nov 2020, Miguel Ojeda wrote:
> On Mon, 23 Nov 2020, Finn Thain wrote:
>
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> >
> > >
> > > It isn't that much effort, isn't it? Plus we need to take into
> > > account the future mistakes that it might prevent, too.
> >
> > We should als
On Mon, Nov 23, 2020 at 08:38:46PM +, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> >
> > In preparation to enable -Wimplicit-f
On Mon, Nov 23, 2020 at 07:59:27PM +0200, Jani Nikula wrote:
> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://li
On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
>
> > IB/hfi1: Fix fall-through warnings for Clang
> > IB/mlx4: Fix fall-through warnings for Clang
> > IB/qedr: Fix fall-through warnings for Clang
> > R
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Nov 23, 2020 at 07:59:23PM +0200, Jani Nikula wrote:
> All clients provide create_buf_file and remove_buf_file callbacks, and
> they're required for relay to make sense. There is no point in them
> being optional.
>
> Also document whether each callback is mandatory/optional.
Looks good,
On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to m
On Mon, Nov 23, 2020 at 07:59:25PM +0200, Jani Nikula wrote:
> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
>
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Looks good,
Reviewed-by: Christoph Hellwig
__
> +/* subbuf_start callback wrapper */
> +static int cb_subbuf_start(struct rchan_buf *buf, void *subbuf,
> +void *prev_subbuf, size_t prev_padding)
I don't think the comment adds any information over just looking at the
function and the two callers. I'd also name it relay
On Mon, Nov 23, 2020 at 07:59:26PM +0200, Jani Nikula wrote:
> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://li
On Mon, Nov 23, 2020 at 07:59:29PM +0200, Jani Nikula wrote:
> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://li
We treat idling the GT (intel_rps_park) as a downclock event, and reduce
the frequency we intend to restart the GT with. Since the two workloads
are likely related (e.g. a compositor rendering every 16ms), we want to
carry the frequency and load information from across the idling.
However, we do al
== Series Details ==
Series: series starting with [01/16] drm/i915/gem: Drop free_work for GEM
contexts
URL : https://patchwork.freedesktop.org/series/84208/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9382_full -> Patchwork_18964_full
==
Quoting Tvrtko Ursulin (2020-11-24 17:19:23)
>
> On 24/11/2020 11:42, Chris Wilson wrote:
> > Pull the repeated check for the last active request being completed to a
> > single spot, when deciding whether or not execlist preemption is
> > required.
> >
> > Signed-off-by: Chris Wilson
> > ---
>
Quoting Tvrtko Ursulin (2020-11-24 17:13:02)
>
> On 24/11/2020 11:42, Chris Wilson wrote:
> > Since the introduction of preempt-to-busy, requests can complete in the
> > background, even while they are not on the engine->active.requests list.
> > As such, the engine->active.request list itself is
On 24/11/2020 11:42, Chris Wilson wrote:
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
1 file chan
Re-reported.
-Original Message-
From: Imre Deak
Sent: Tuesday, November 24, 2020 7:13 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.BAT: failure for series starting with [1/2]
drm/framebuffer: Format modifier for Intel Gen 12 render compression wi
On 24/11/2020 11:42, Chris Wilson wrote:
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the en
== Series Details ==
Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
Gen 12 render compression with Clear Color
URL : https://patchwork.freedesktop.org/series/84183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9378 -> Patchwork_18961
==
On 2020-11-11 at 11:50:48 +0530, Anshuman Gupta wrote:
> This requires for HDCP 2.2 MST check link.
> As for DP/HDMI shims check_2_2_link retrieves the connector
> from dig_port, this is not sufficient or DP MST connector,
> there can be multiple DP MST topology connector associated
> with same dig
On 24/11/2020 16:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-24 16:19:15)
On 24/11/2020 11:42, Chris Wilson wrote:
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
Signed-off-b
== Series Details ==
Series: dma-buf/dma-resv: Respect num_fences when initializing the shared fence
list.
URL : https://patchwork.freedesktop.org/series/84210/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9383 -> Patchwork_18966
=
On 2020-11-11 at 11:50:47 +0530, Anshuman Gupta wrote:
> Add support for multiple mst stream in hdcp port data
> which will be used by RepeaterAuthStreamManage msg and
> HDCP 2.2 security f/w for m' validation.
>
> Security f/w doesn't have any provision to mark the
> stream_type for each stream s
On Tue, Nov 24, 2020 at 03:28:47PM +0530, Anshuman Gupta wrote:
> Platforms with South Display Engine on PCH, doesn't
> require to get/put the AUX power domain in order to
> access PPS register because PPS registers are always on
> with South display on PCH.
>
> Cc: Imre Deak
> Cc:
> Signed-off-
Quoting Tvrtko Ursulin (2020-11-24 16:19:15)
>
> On 24/11/2020 11:42, Chris Wilson wrote:
> > If while we are cancelling the breadcrumb signaling, we find that the
> > request is already completed, move it to the irq signaler and let it be
> > signaled.
> >
> > Signed-off-by: Chris Wilson
> > --
== Series Details ==
Series: dma-buf/dma-resv: Respect num_fences when initializing the shared fence
list.
URL : https://patchwork.freedesktop.org/series/84210/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a3e8d02ad6be dma-buf/dma-resv: Respect num_fences when initializing th
On Fri, Nov 20, 2020 at 01:06:14AM +0530, Uma Shankar wrote:
> There are some corner cases wrt underrun when we enable
> FBC with PSR2 on TGL. Recommendation from hardware is to
> keep this combination disabled.
>
> Bspec: 50422 HSD: 14010260002
>
> v2: Added psr2 enabled check from crtc_state (A
On 24/11/2020 11:42, Chris Wilson wrote:
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 20 -
On 2020-11-24 at 21:47:19 +0530, Ramalingam C wrote:
> On 2020-11-24 at 20:32:43 +0530, Anshuman Gupta wrote:
> > On 2020-11-24 at 19:50:17 +0530, Ramalingam C wrote:
> > > On 2020-11-11 at 11:50:42 +0530, Anshuman Gupta wrote:
> > > > Enable HDCP 1.4 over DP MST for Gen12.
> > > >
> > > > Cc: Ram
On 2020-11-24 at 20:32:43 +0530, Anshuman Gupta wrote:
> On 2020-11-24 at 19:50:17 +0530, Ramalingam C wrote:
> > On 2020-11-11 at 11:50:42 +0530, Anshuman Gupta wrote:
> > > Enable HDCP 1.4 over DP MST for Gen12.
> > >
> > > Cc: Ramalingam C
> > > Signed-off-by: Anshuman Gupta
> > > ---
> > >
== Series Details ==
Series: relay: allow the use of const callback structs
URL : https://patchwork.freedesktop.org/series/84209/
State : failure
== Summary ==
Applying: relay: allow the use of const callback structs
Using index info to reconstruct a base tree...
M include/linux/relay.h
== Series Details ==
Series: drm: Move struct drm_device.pdev to legacy
URL : https://patchwork.freedesktop.org/series/84205/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9382_full -> Patchwork_18963_full
Summary
---
1 - 100 of 162 matches
Mail list logo
