On 10/21/21 13:44, Matthew Auld wrote:
Should not be needed. Even with non-coherent display, we should be using
device local-memory there, and not system memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
On 10/21/21 13:44, Matthew Auld wrote:
Move it next to its partner in crime; gpu_write_needs_clflush.
A motivation in the commit message?
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Otherwise:
Reviewed-by: Thomas Hellström
Quoting Matthew Brost (2021-10-25 19:34:04)
> Hide the guc_id and tail fields, for request trace points, behind
> CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> are ABI (maybe?) so don't change them without kernel developers Kconfig
> options.
I've pushed the simple fix to el
On 10/21/21 13:44, Matthew Auld wrote:
We seem to have an unfortunate issue where we arrive from:
i915_gem_object_flush_if_display+0x86/0xd0 [i915]
intel_user_framebuffer_dirty+0x1a/0x50 [i915]
drm_mode_dirtyfb_ioctl+0xfb/0x1b0
Which can be before the pages are populated(and pi
On 10/21/21 13:44, Matthew Auld wrote:
In theory if clflush_work_create() somehow fails here, and we don't yet
have mm.pages populated then we end up resetting cache_dirty, which is
likely wrong, since that will potentially skip the flush-on-acquire, if
it was needed.
It looks like intel_user_
+ Jani and Rodrigo in order to pick this to -fixes.
Quoting Patchwork (2021-10-27 13:31:33)
> Patch Details
>
> Series: drm/i915: Revert 'guc_id' from i915_request tracepoint
> URL: https://patchwork.freedesktop.org/series/96336/
> State: success
> Details: https://intel-gfx-ci.01.org/tree
Quoting Dave Airlie (2021-10-26 03:34:52)
> On Mon, 25 Oct 2021 at 23:51, Daniel Vetter wrote:
> >
> > On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen
> > wrote:
> > >
> > > Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver.
> > > Tvrtko will bring added bandwidth and focus to the GT/GEM
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correc
This patch series prepares error capture for asynchronous migration,
where the vma pages may not reflect the pages the GPU is currently
executing from but may be several migrations ahead.
The first patch deals with refcounting sg-list so that they don't
disappear under the capture code, which typi
From: Thomas Hellström
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for three purposes:
1) Error capture.
2) Asynchronous m
== Series Details ==
Series: drm/i915: Revert 'guc_id' from i915_request tracepoint
URL : https://patchwork.freedesktop.org/series/96336/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10795 -> Patchwork_21458
Summary
--
On Tue, Oct 26, 2021 at 06:08:44PM -0400, Lyude Paul wrote:
> This simply adds proper support for panel backlights that can be controlled
> via VESA's backlight control protocol, but which also require that we
> enable and disable the backlight via PWM instead of via the DPCD interface.
> We also e
== Series Details ==
Series: drm/i915/gem: Remove gpu reloc workaround
URL : https://patchwork.freedesktop.org/series/96333/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10795 -> Patchwork_21457
Summary
---
**FAILUR
On Wed, 27 Oct 2021 at 10:33, Joonas Lahtinen
wrote:
>
> Avoid adding backend specific data to the tracepoints outside of
> the LOW_LEVEL_TRACEPOINTS kernel config protection. These bits of
> information are bound to change depending on the selected submission
> method per platform and are not nec
DP 1.4 spec limits max compression bpp to
uncompressed bpp -1, which is supported from
XELPD onwards.
Instead of uncompressed bpp, max dsc input bpp
was being used to limit the max compression bpp.
Fixes: 831d5aa96c97 ("drm/i915/xelpd: Support DP1.4 compression BPPs")
Signed-off-by: Vandita Kulkar
On Wed, 27 Oct 2021 at 10:44, Jani Nikula wrote:
>
> On Wed, 27 Oct 2021, Matthew Auld wrote:
> > On Wed, 27 Oct 2021 at 09:58, Jani Nikula
> > wrote:
> >>
> >> On Wed, 27 Oct 2021, Matthew Auld wrote:
> >> > On Thu, 21 Oct 2021 at 13:54, Matthew Auld
> >> > wrote:
> >> >>
> >> >> wbinvd_on_
On Wed, 27 Oct 2021, Matthew Auld wrote:
> On Wed, 27 Oct 2021 at 09:58, Jani Nikula wrote:
>>
>> On Wed, 27 Oct 2021, Matthew Auld wrote:
>> > On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>> >>
>> >> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
>> >> include asm/s
Avoid adding backend specific data to the tracepoints outside of
the LOW_LEVEL_TRACEPOINTS kernel config protection. These bits of
information are bound to change depending on the selected submission
method per platform and are not necessarily possible to maintain in
the future.
Fixes: dbf9da8d55e
Quoting Matthew Brost (2021-10-26 18:51:17)
> On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote:
> > Quoting Matthew Brost (2021-10-25 18:15:09)
> > > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote:
> > > > Quoting Matthew Brost (2021-10-22 19:42:19)
> > > > > On Fri,
On Wed, 27 Oct 2021 at 09:36, Thomas Hellström
wrote:
>
> GPU relocs are gone. There should be no need for this workaround anymore.
> Remove it.
>
> Signed-off-by: Thomas Hellström
I was completely wrong here, sorry. Digging through the git history it
looks like this came from:
Commit 149c84077
On Tue, Oct 26, 2021 at 02:01:15PM +0300, Jani Nikula wrote:
> On Mon, 25 Oct 2021, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Looks like we never updated intel_bios_is_port_dp_dual_mode() when
> > the VBT port mapping became erratic on modern platforms. This
> > is causing us to look u
On Wed, 27 Oct 2021 at 09:58, Jani Nikula wrote:
>
> On Wed, 27 Oct 2021, Matthew Auld wrote:
> > On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
> >>
> >> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
> >> include asm/smp.h here.
> >>
> >> Reported-by: kernel test robo
On Wed, 27 Oct 2021, Jani Nikula wrote:
> On Wed, 27 Oct 2021, Matthew Auld wrote:
>> On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>>>
>>> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
>>> include asm/smp.h here.
>>>
>>> Reported-by: kernel test robot
>>> Signed-off
On Wed, 27 Oct 2021, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>>
>> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
>> include asm/smp.h here.
>>
>> Reported-by: kernel test robot
>> Signed-off-by: Matthew Auld
>> Cc: Thomas Hellström
>
> Ja
On Wed, Oct 27, 2021 at 12:57:37PM +0530, Nautiyal, Ankit K wrote:
>
> On 10/15/2021 7:09 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We lack sufficient state tracking to figure out whether
> > we want the DFP to perform the RGB->YCbCr conversion for us
> > or not. So currently we ar
On Wed, Oct 27, 2021 at 12:36:17PM +0530, Nautiyal, Ankit K wrote:
>
> On 10/15/2021 7:09 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Consolidate the double pfit call, and reorder things so that
> > intel_dp_output_format() and intel_dp_compute_link_config() are
> > back-to-back. The
GPU relocs are gone. There should be no need for this workaround anymore.
Remove it.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuf
On Wed, Oct 27, 2021 at 06:41:25AM +, Kasireddy, Vivek wrote:
> Hi Ville,
>
> >
> > On Mon, Oct 25, 2021 at 11:38:11PM -0700, Vivek Kasireddy wrote:
> > > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> > > more framebuffers/scanout buffers results in only one that is
On Tue, 26 Oct 2021 11:02:31 -0400
Harry Wentland wrote:
> On 2021-10-12 17:01, Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Pekka Paalanen
> >> Sent: Tuesday, October 12, 2021 5:25 PM
> >> To: Shankar, Uma
> >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.
On Wed, 27 Oct 2021, Imre Deak wrote:
> On Tue, Oct 26, 2021 at 08:52:12PM +0300, Jani Nikula wrote:
>> AFAICT there are no intel_plane_caps references anywhere after this, and
>> it no longer looks like an enum, so perhaps it just shouldn't be an enum
>> anymore? Just make them macros?
>
> There
On Tue, 26 Oct 2021 11:36:33 -0400
Harry Wentland wrote:
> On 2021-10-14 15:44, Shankar, Uma wrote:
> >
...
> > +
> > +* Plane CTM
> > + * This is a Property to program the color transformation
> > matrix.
>
> No mode property here? Is there any hardware with
On Tue, 26 Oct 2021, Lucas De Marchi wrote:
> On Wed, Oct 13, 2021 at 03:12:55PM +0300, Jani Nikula wrote:
>>On Fri, 08 Oct 2021, Matt Roper wrote:
>>> On a multi-tile platform, each tile has its own registers + GGTT space,
>>> and BAR 0 is extended to cover all of them. Upcoming patches will st
On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>
> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
> include asm/smp.h here.
>
> Reported-by: kernel test robot
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
Jani, would it make sense to cherry-pick this to -fixes?
On Tue, 2021-10-26 at 15:33 -0700, José Roberto de Souza wrote:
> PSR2 is supported in transcoder A and B on Alderlake-P.
>
> BSpec: 49185
> Cc: Mika Kahola
> Cc: Jouni Hogander
> Signed-off-by: José Roberto de Souza
LGTM
Reviewed-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/int
On 10/15/2021 7:09 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We lack sufficient state tracking to figure out whether
we want the DFP to perform the RGB->YCbCr conversion for us
or not. So currently we are blindly just enabling that all the
time when supported by the DFP. That is nonsense.
Hi Lyude,
On Mon, Oct 25, 2021 at 09:30:14PM -0400, Lyude Paul wrote:
> topic/amdgpu-dp2.0-mst-2021-10-25:
> UAPI Changes:
> Nope!
>
> Cross-subsystem Changes:
> drm_dp_update_payload_part1() takes a new argument for specifying what the
> VCPI slot start is
>
> Core Changes:
> Make the DP MST he
On Fri, Oct 08, 2021 at 02:56:31PM -0700, Matt Roper wrote:
From: Paulo Zanoni
The first step of interrupt handling is to read a tile0 register that
tells us in which tile the interrupt happened; we can then we read the
usual interrupt registers from the appropriate tile.
Note that this is jus
On 10/15/2021 7:09 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Consolidate the double pfit call, and reorder things so that
intel_dp_output_format() and intel_dp_compute_link_config() are
back-to-back. They are intimately related, and will need to be
called twice to properly handle the "4:2:
On Fri, Oct 08, 2021 at 02:56:29PM -0700, Matt Roper wrote:
From: Tvrtko Ursulin
Add some basic plumbing to support more than one dynamically allocated
struct intel_gt. Up to four gts are supported in i915->gts[], with slot
zero shadowing the existing i915->gt to enable source compatibility wi
101 - 140 of 140 matches
Mail list logo
