On Thu, Nov 05, 2020 at 06:41:25PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2020-11-05 15:49:34)
> > Move the specialised interactions with the physical GEM object from the
> > pread/pwrite ioctl handler into the phys backend.
which depends on the backend...
> >
>
> Fixes: c6790dc2231
On 2020.10.27 12:54:06 +0800, Colin Xu wrote:
> This patch add gvt resume wrapper into i915_drm_resume().
> GVT relies on i915 so resume gvt at last.
>
> V2:
> - Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c.
> The wrapper and implementation will check and call gvt routine
On 2020.10.27 12:53:08 +0800, Colin Xu wrote:
> This patch save/restore necessary GVT info during i915 suspend/resume so
> that GVT enabled QEMU VM can continue running.
>
> Only GGTT and fence regs are saved/restored now. GVT will save GGTT
> entries on each host_entry update, restore the saved d
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required to set the protections on multiple
> >
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from include/linux/kernel.h:14,
from include/asm-generic/bug.h:20,
from arch/arm/include/asm/bug.h:60,
from include
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/msm_gem.c:1014:10: error: initialization of 'int (*)(struct
drm_gem_object *, struct dma_buf_map *)' from incompatible pointer type 'void *
(*)(struct drm_gem_object
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending o
On Fri, Oct 16, 2020 at 06:54:11PM +0100, Chris Wilson wrote:
> MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> based on plaform and the number of EU based on the number of slices and
> subslices. This
From: Ville Syrjälä
Move cnl_get_ddi_pll() into a better spot from between
icl_get_ddi_pll() and dg1_get_ddi_pll(). Also reorder
the calls to the skl and bxt functions because ocd.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 48 ++--
1 file c
From: Ville Syrjälä
On icl+ we want to populate both crtc_state.{shared_dpll,dpll_hw_state}
and crtc_state.port_dplls[] during readout, whereas on pre-icl we
want to leave the latter stuff untouched. Rather than adding more ifs
into hsw_get_ddi_port_state() to copy the DPLL hw state around let's
From: Ville Syrjälä
Add a wrapper for the pll .get_hw_state() vfunc. Makes life
a bit less miserable when you don't have to worry where the
function pointer is stored.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++--
drivers/gpu/drm/i915/displa
From: Ville Syrjälä
Currently the DPLL .get_freq() uses pll->state.hw_state which
is not the thing we actually read out (except during driver
load/resume). Outside of that pll->state.hw_state is just the
thing we committed last time around. During state check we
just read the thing into crtc_stat
On Fri, Nov 06, 2020 at 07:30:37PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pass the whole intel_atomic_state to skl_build_pipe_wm()
> and skl_allocate_pipe_ddb() so we can start to iterate
> stuff containerd in the commit.
>
> Signed-off-by: Ville Syrjälä
This looks good to me,
All the review comments addressed here,
@Ville could you review this?
Manasi
On Mon, Nov 09, 2020 at 12:12:46PM -0800, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> Small changes to intel_dp_mode_valid(), allow listing modes that
> can only be supported in the bigjoiner configuration, whic
On Tue, 2020-10-20 at 07:40 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/edp/jsl: Update vswing table for HBR and HBR2 (rev3) URL:
> https://patchwork.freedesktop.org/series/82206/ State: success Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18738/index.html
> CI Bug
On Tue, 2020-10-20 at 11:06 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP.
>
> BSpec: 21257
>
> Changes since V1:
> - Fixed few checkpatch errors
>
Reviewed-by: José Roberto de Souza
> Cc: Souza Jose
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote:
> Now that hpd/display related calls are split from the rest in
> intel_irq_init(), skip all of that in case we don't have display.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Jani Nikula
> Signed-off-by: Luc
On Mon, Nov 09, 2020 at 08:15:05PM +, Chris Wilson wrote:
> Quoting Jason Ekstrand (2020-11-09 19:52:26)
> > We need to land this patch. The number of bugs we have piling up in
> > Mesa gitlab related to this is getting a lot larger than I'd like.
> > I've gone back and forth with various HW a
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote:
> In intel_irq_init() move what's display/hpd related after what is gt and
> guc. This makes it easier to support !HAS_DISPLAY() in future.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote:
> Use the convention of new platforms first. No need to special case
> HAS_GMCH() since that stopped being true at the lattest on gen8 (for
> cherryview).
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> dr
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote:
> From: Jani Nikula
>
> !HAS_DISPLAY() implies !HAS_OVERLAY(), skipping overlay setup anyway, so
> return earlier from intel_modeset_init() for clarity.
Reviewed-by: José Roberto de Souza
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Ni
Enabling atomic operations in L3 leads to unrecoverable GPU hangs, as
the machine stops responding milliseconds after receipt of the reset
request [GDRT]. By disabling the cached atomics, the hang do not occur
and we presume the GPU would reset normally for similar hangs.
Reported-by: Jason Ekstra
Quoting Jason Ekstrand (2020-11-09 19:52:26)
> We need to land this patch. The number of bugs we have piling up in
> Mesa gitlab related to this is getting a lot larger than I'd like.
> I've gone back and forth with various HW and SW people internally for
> countless e-mail threads and there is no
From: Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
v13:
* Allow bigjoiner if hdisplay >5120
v12:
* slice_count logic simplify (Ville)
* Fix unnecessary changes in downstream_mo
No functional changes, create a separate intel_encoder_get_config()
function that calls encoder->get_config hook.
This is needed so that later we can add beigjoienr related
readout here.
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 1
No functional changes here, just adds a from_crtc_state
as a prep for bigjoiner
v2:
* More prep with intel_atomic_state (Ville)
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 9 +
drivers/gpu/drm/i915/displa
Create a new function intel_crtc_get_pipe_config()
that calls platform specific hooks for get_pipe_config()
No functional change here.
Suggested-by: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
1 fil
No functional changes, to align with previous cleanups pass
intel_atomic_state instead of drm_atomic_state.
Also pass this intel_atomic_state with crtc_state to
some of the atomic_check functions.
v2:
* Squash some changes from next patch (Ville)
Signed-off-by: Manasi Navare
Reviewed-by: Ville S
From: Maarten Lankhorst
With bigjoiner, there will be 2 pipes driving 2 halves of 1 transcoder,
because of this, we need a pipe_mode for various calculations, including
for example watermarks, plane clipping, etc.
v10:
* remove redundant pipe_mode assignment (Ville)
v9:
* pipe_mode in state dump
No functional changes. This patch just moves some mode checks
around to prepare for adding bigjoiner related mode validation
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+),
We need to land this patch. The number of bugs we have piling up in
Mesa gitlab related to this is getting a lot larger than I'd like.
I've gone back and forth with various HW and SW people internally for
countless e-mail threads and there is no other good workaround. Yes,
the perf hit to atomics
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Thursday, November 5, 2020 10:50 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [CI 2/2] drm/i915/gem: Pull phys pread/pwrite
>implementations to the backend
>
>Move the specialised interactions with the
== Series Details ==
Series: drm/i915/region: fix order when adding blocks
URL : https://patchwork.freedesktop.org/series/83641/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9295_full -> Patchwork_18873_full
Summary
--
Allow us to validate mocs configurations after reset if we have either
engine or global reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 40 +
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_
== Series Details ==
Series: drm/i915/region: fix order when adding blocks
URL : https://patchwork.freedesktop.org/series/83641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9295 -> Patchwork_18873
Summary
---
**SUC
Quoting Chris Wilson (2020-11-09 11:28:04)
> Quoting Matthew Auld (2020-11-09 11:12:49)
> > When performing an allocation we try split it down into the largest
> > possible power-of-two blocks/pages-sizes, and for the common case we
> > expect to allocate the blocks in descending order. This also n
Quoting Matthew Auld (2020-11-09 11:12:49)
> When performing an allocation we try split it down into the largest
> possible power-of-two blocks/pages-sizes, and for the common case we
> expect to allocate the blocks in descending order. This also naturally
> fits with our GTT alignment tricks(inclu
== Series Details ==
Series: User friendly lsgpu default output
URL : https://patchwork.freedesktop.org/series/83640/
State : failure
== Summary ==
Applying: intel_gpu_top: User friendly device listing
error: sha1 information is lacking or useless (lib/igt_device_scan.c).
error: could not buil
When performing an allocation we try split it down into the largest
possible power-of-two blocks/pages-sizes, and for the common case we
expect to allocate the blocks in descending order. This also naturally
fits with our GTT alignment tricks(including the hugepages selftest),
where we sometimes tr
From: Tvrtko Ursulin
Adding a new device selection print type suitable for user-facing
use cases like intel_gpu_top -L and later lsgpu.
Instead of:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/de
From: Tvrtko Ursulin
As per individual changelogs end result is:
$ lsgpu
card0 8086:193Bdrm:/dev/dri/card0
└─renderD128 drm:/dev/dri/renderD128
$ lsgpu --sysfs
card0 8086:193B
sys:/sys/devices/pci:00/000
From: Tvrtko Ursulin
New default user frindly device listing mode which replaces:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/devices/pci:00/:00:02.0
sys:/sys/devices/pci:00/:00:
From: Tvrtko Ursulin
In the previous patch we switched the lsgpu output to a short and user
friendly format but some users will need a shorthand for getting other
types of device selection filters than the defaut drm.
Add some command line switches to enable this:
$ lsgpu
card0
Hi!
> As the error capture will compress user buffers as directed to by the
> user, it can take an arbitrary amount of time and space. Break up the
> compression loops with a call to cond_resched(), that will allow other
> processes to schedule (avoiding the soft lockups) and also serve as a
> war
On Fri, 06 Nov 2020, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> Display is always disabled and enabled when resetting any engine, but if
> there is no display it should not do anything with display and only
> reset the needed engines.
>
> Cc: Jani Nikula
> Signed-off-by: José Rober
On Fri, 06 Nov 2020, Lucas De Marchi wrote:
> Rename intel_finish_reset to intel_display_finish_reset, so it's clear
> from gt/ that we are calling out the display code.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>
On Fri, 06 Nov 2020, Lucas De Marchi wrote:
> Rename intel_prepare_reset to intel_display_prepare_reset, so it's clear
> from gt/ that we are calling out the display code.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>
== Series Details ==
Series: Final prep series for bigjoiner (rev2)
URL : https://patchwork.freedesktop.org/series/83547/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9294 -> Patchwork_18871
Summary
---
**FAILURE**
On 2020-11-09 at 11:06:24 +0530, Anshuman Gupta wrote:
> On 2020-11-06 at 16:42:21 +0530, Ramalingam C wrote:
> > On 2020-11-06 at 14:57:25 +0530, Ramalingam C wrote:
> > > On 2020-11-03 at 11:57:00 +0530, Anshuman Gupta wrote:
> > > > Add support for HDCP 2.2 DP MST shim callback.
> > > > This add
== Series Details ==
Series: Final prep series for bigjoiner (rev2)
URL : https://patchwork.freedesktop.org/series/83547/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6cf2a64fbb76 drm/i915/dp: Some reshuffling in mode_valid as prep for bigjoiner
modes
99648dc9d2bf drm/i915: M
50 matches
Mail list logo
