Customer report random display flicker issue on Nightfury board.
And we found this problem might be caused by VT-d and FBC are
both enabled. According to sighting report, it recommend to turn
drm/i915/fbc: disable FBC on Nightfury board
Customer report random display flicker issue on Nightfury
Hi Ville,
> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> wrote:
>
> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
>> LSPCON only supports 8 bpc for RGB/YCbCr444.
>>
>> Set the correct bpp otherwise it renders blank screen.
>
> Hmm. Does
>
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support (rev2)
URL : https://patchwork.freedesktop.org/series/81083/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8930_full ->
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm
connector VRR property (rev2)
URL : https://patchwork.freedesktop.org/series/81081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930_full -> Patchwork_18413_full
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev7)
URL : https://patchwork.freedesktop.org/series/80542/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930_full -> Patchwork_18410_full
Hi Dave and Daniel,
here goes the first pull request towards 5.10:
As requested, the gem patches have been separated into
a drm-intel/topic/drm-intel-gem-next that will be sent separately
by the gem team later.
Thanks,
Rodrigo.
drm-intel-next-2020-08-24-1:
UAPI Changes:
- Introduce a
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master tegra-drm/drm/tegra/for-next
drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong
Hi Tom,
On 2019-12-21 15:03, Tom Murphy wrote:
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver which
causes a huge amount of artifacts on the screen of my laptop. You can see a
picture of it here:
That would be great!
On Wed., Aug. 26, 2020, 2:14 p.m. Robin Murphy,
wrote:
> Hi Tom,
>
> On 2019-12-21 15:03, Tom Murphy wrote:
> > This patchset converts the intel iommu driver to the dma-iommu api.
> >
> > While converting the driver I exposed a bug in the intel i915 driver
> which causes a
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support (rev2)
URL : https://patchwork.freedesktop.org/series/81083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18414
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support (rev2)
URL : https://patchwork.freedesktop.org/series/81083/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1ad237a81b4b
On Wed, Aug 26, 2020 at 1:53 PM Harald Arnesen wrote:
>
> It's a Thinkpad T520.
Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc
ranges won't make any difference on x86-64.
Or are you for some reason running a 32-bit kernel on that thing? Have
you tried building a 64-bit one
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm
connector VRR property (rev2)
URL : https://patchwork.freedesktop.org/series/81081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18413
Dave Airlie [26.08.2020 22:47]:
> On Thu, 27 Aug 2020 at 06:44, Harald Arnesen wrote:
>>
>> Linus Torvalds [26.08.2020 20:04]:
>>
>> > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>> >> Somehow related to lightdm or xfce4? However, it is a regression, since
>> >> kernel 5.8 works.
>> >
On Thu, 27 Aug 2020 at 06:44, Harald Arnesen wrote:
>
> Linus Torvalds [26.08.2020 20:04]:
>
> > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
> >> Somehow related to lightdm or xfce4? However, it is a regression, since
> >> kernel 5.8 works.
> > Yeah, apparently there's something else
Linus Torvalds [26.08.2020 20:04]:
> On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>> Somehow related to lightdm or xfce4? However, it is a regression, since
>> kernel 5.8 works.
> Yeah, apparently there's something else wrong with the relocation changes too.
>
> That said, does that
Chris Wilson [26.08.2020 15:27]:
> On 32b, highmem uses a finite set of indirect PTE (i.e. vmap) to provide
> virtual mappings of the high pages. As these are finite, map_new_virtual()
> must wait for some other kmap() to finish when it runs out. If we map a
> large number of objects, there is no
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm
connector VRR property (rev2)
URL : https://patchwork.freedesktop.org/series/81081/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/81083/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18412
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v6:
* Remove unset of prop
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/81083/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8017026c4d9e drm/i915/display/tgl:
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is
set as EHL combo phy supports HBR3 (Matt R)
Reviewed-by: Matt Roper
Cc: Lee Shawn
Update with latest tunning in the table.
v3: Fix values of to last columns.
BSpec: 21257
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
Reviewed-by: Matt Roper
Cc: Lee Shawn C
Cc: Khaled Almahallawy
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
On Tue, 2020-08-25 at 15:54 -0700, Matt Roper wrote:
> On Tue, Aug 25, 2020 at 11:43:43AM -0700, José Roberto de Souza wrote:
> > Update with latest tunning in the table.
> >
> > BSpec: 21257
> > Cc: Matt Roper <
> > matthew.d.ro...@intel.com
> > >
> > Signed-off-by: José Roberto de Souza <
> >
== Series Details ==
Series: series starting with [1/4] drm/i915/display/dp: Attach and set drm
connector VRR property
URL : https://patchwork.freedesktop.org/series/81081/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18411
== Series Details ==
Series: drm/xen-front: Add support for EDID based configuration
URL : https://patchwork.freedesktop.org/series/81068/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8928_full -> Patchwork_18409_full
== Series Details ==
Series: series starting with [1/4] drm/i915/display/dp: Attach and set drm
connector VRR property
URL : https://patchwork.freedesktop.org/series/81081/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev7)
URL : https://patchwork.freedesktop.org/series/80542/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18410
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev7)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev7)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b76b4b6f3675 drm/nouveau/kms: Fix some indenting in
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: Gwan-gyeong Mun
Cc: Imre Deak
Signed-off-by: Manasi Navare
---
This forces a complete modeset if vrr drm crtc state goes
from enabled to disabled and vice versa.
This patch also computes vrr state variables from the mode timings
and based on the vrr property set by userspace as well as hardware's
vrr capability.
Cc: Ville Syrjälä
Cc: Jani Nikula
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect
Introduce VRR struct in intel_crtc_state and add
VRR crtc state variables Enable, Vtotalmin and Vtotalmax
to be derived from mode timings and VRR crtc property.
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display_types.h | 7 +++
1 file changed, 7
The blocking/polling parameterized tests were introduced to test
different hrtimer configurations.These tests check how many times the
process wakes up to read the reports with different hrtimer values (=
duration of test / hrtimer value). A user is more likely to choose a
larger hrtimer value
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
On Mon, Aug 24, 2020 at 2:56 AM Tom Murphy wrote:
>
> Hi Logan/All,
>
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector")
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_read_downstream_info().
Note that when we do this, we also do make some functional
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..a5934064a75ea 100644
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
v5:
* Drop !!()
* Move drm_dp_has_mst() out of header
* Change name from drm_dp_has_mst() to drm_dp_read_mst_cap()
Signed-off-by: Lyude Paul
Reviewed-by: Sean
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD,
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM related and MST related fixes,
we're missing a lot of nice
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
---
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
On Wed, 2020-08-26 at 05:44 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/gt: Implement WA_1406941453 (rev4)
> URL: https://patchwork.freedesktop.org/series/78243/
> State:failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/index.html
>
On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>
> Somehow related to lightdm or xfce4? However, it is a regression, since
> kernel 5.8 works.
Yeah, apparently there's something else wrong with the relocation changes too.
That said, does that patch at
This addition to cflags enables dyndbg in the gvt component of the
i915 module, on a CONFIG_DYNAMIC_DEBUG_CORE build.
So here are the message classifications that the gvt driver uses.
cut -d= -f2 | cut -d\ -f2,3 | \
perl -ne 'chomp $_ && $h{$_}++; END{print "$_\" \tseen $h{$_}\n" for sort
The gvt component of this driver has ~120 pr_debugs, in 9 "classes".
Add a "knob", like drm.debug, to map bits to these classes.
bash-5.0# echo 0x01 > /sys/module/i915/parameters/debug_dyn
set_dyndbg: result:0x1 from 0x01
dyndbg: query 0: "format='^gvt: cmd: ' +p"
dyndbg: entry,
On Wed, 26 Aug 2020 at 14:28, Chris Wilson wrote:
>
> If we create a new node, it is possible for the slab allocator to return
> us a recently freed node. If that node was just retired, it will retain
> the current jiffy as its node->age. There is then a miniscule window,
> where as that node is
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
Quoting Matthew Auld (2020-08-26 17:36:52)
> On Wed, 26 Aug 2020 at 14:28, Chris Wilson wrote:
> >
> > Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
> > rather than a direct assignment.
>
> and crucially add the missing sync stuff for the mapping?
Fortunately not for
On Wed, 2020-08-26 at 12:56 +0530, Anshuman Gupta wrote:
> On 2020-08-25 at 10:13:29 -0700, José Roberto de Souza wrote:
> > DRRS and PSR can't be enable together, so giving preference to PSR
> > as it allows more power-savings by complete shutting down display,
> > so to guarantee this, it should
On Wed, 26 Aug 2020 at 14:28, Chris Wilson wrote:
>
> Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
> rather than a direct assignment.
and crucially add the missing sync stuff for the mapping?
>
> Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object
On Wed, Aug 26, 2020 at 03:54:14PM +0100, Matthew Wilcox wrote:
> On Wed, Aug 26, 2020 at 10:20:02AM -0400, Johannes Weiner wrote:
> > On Wed, Aug 19, 2020 at 07:48:44PM +0100, Matthew Wilcox (Oracle) wrote:
> > > + return find_get_swap_page(vma->vm_file->f_mapping,
> > > +
On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> LSPCON only supports 8 bpc for RGB/YCbCr444.
>
> Set the correct bpp otherwise it renders blank screen.
Hmm. Does
git://github.com/vsyrjala/linux.git dp_downstream_ports_5
work?
Actually better make that
On Wed, Aug 26, 2020 at 11:09:25AM -0400, Johannes Weiner wrote:
> On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote:
> > There are only three callers remaining of find_get_entry().
> > find_get_swap_page() is happy to get the head page instead of the subpage.
> > Add
On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote:
> On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
> > On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
> > wrote:
> > >
> > > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > > > [...]
> > > > > > > Since both threads
On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote:
> There are only three callers remaining of find_get_entry().
> find_get_swap_page() is happy to get the head page instead of the subpage.
> Add find_subpage() calls to find_lock_entry() and pagecache_get_page()
> to avoid
On Wed, Aug 26, 2020 at 10:20:02AM -0400, Johannes Weiner wrote:
> On Wed, Aug 19, 2020 at 07:48:44PM +0100, Matthew Wilcox (Oracle) wrote:
> > + return find_get_swap_page(vma->vm_file->f_mapping,
> > + linear_page_index(vma, addr));
>
> The refactor makes sense to me, but the
== Series Details ==
Series: drm/xen-front: Add support for EDID based configuration
URL : https://patchwork.freedesktop.org/series/81068/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8928 -> Patchwork_18409
Summary
On Wed, Aug 19, 2020 at 07:48:47PM +0100, Matthew Wilcox (Oracle) wrote:
> i915 does not want to see value entries. Switch it to use
> find_lock_page() instead, and remove the export of find_lock_entry().
>
> Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Johannes Weiner
On Wed, Aug 19, 2020 at 07:48:46PM +0100, Matthew Wilcox (Oracle) wrote:
> Avoid bumping the refcount on pages when we're only interested in the
> swap entries.
>
> Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Johannes Weiner
___
Intel-gfx
On Wed, Aug 19, 2020 at 07:48:45PM +0100, Matthew Wilcox (Oracle) wrote:
> Instead of calling find_get_entry() for every page index, use an XArray
> iterator to skip over NULL entries, and avoid calling get_page(),
> because we only want the swap entries.
>
> Signed-off-by: Matthew Wilcox
On Wed, 26 Aug 2020 at 14:29, Chris Wilson wrote:
>
> On 32b, highmem uses a finite set of indirect PTE (i.e. vmap) to provide
> virtual mappings of the high pages. As these are finite, map_new_virtual()
> must wait for some other kmap() to finish when it runs out. If we map a
> large number of
On Wed, Aug 19, 2020 at 07:48:44PM +0100, Matthew Wilcox (Oracle) wrote:
> The current code does not protect against swapoff of the underlying
> swap device, so this is a bug fix as well as a worthwhile reduction in
> code complexity.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
>
== Series Details ==
Series: series starting with [01/39] drm/i915/gem: Avoid implicit vmap for
highmem on x86-32
URL : https://patchwork.freedesktop.org/series/81064/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8928 -> Patchwork_18408
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's
== Series Details ==
Series: series starting with [01/39] drm/i915/gem: Avoid implicit vmap for
highmem on x86-32
URL : https://patchwork.freedesktop.org/series/81064/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140.
v5.8.2: Build OK!
v5.7.16: Build
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140.
v5.8.2: Failed to apply! Possible
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via
sysfs").
The bot has tested the following trees: v5.8.2, v5.7.16.
v5.8.2: Failed to apply! Possible dependencies:
== Series Details ==
Series: series starting with [01/39] drm/i915/gem: Avoid implicit vmap for
highmem on x86-32
URL : https://patchwork.freedesktop.org/series/81064/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4d11ca4aabc3 drm/i915/gem: Avoid implicit vmap for highmem on
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
warning should we
Let's not try and use PAT attributes for I915_MAP_WC is the CPU doesn't
support PAT.
Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Cc: # v5.6+
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +++
1 file
Pull the GT clock information [used to derive CS timestamps and PM
interval] under the GT so that is it local to the users. In doing so, we
consolidate the two references for the same information, of which the
runtime-info took note of a potential clock source override and scaling
factors.
On 32b, highmem uses a finite set of indirect PTE (i.e. vmap) to provide
virtual mappings of the high pages. As these are finite, map_new_virtual()
must wait for some other kmap() to finish when it runs out. If we map a
large number of objects, there is no method for it to tell us to release
the
Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
rather than a direct assignment.
Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 33
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
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client
Since we expect to inline the csb_parse() routines, the w/a for the
stale CSB data on Tigerlake will be pulled into process_csb(), and so we
might as well simply reuse the logic for all, and so will hopefully
avoid any strange behaviour on Icelake that was not covered by our
previous w/a.
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
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
1 file changed, 16 insertions(+), 4
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
If we manage to hit the intel_gt_set_wedged_on_fini() while active, i.e.
module unload during a stress test, we may cancel the requests but not
clean up. This leads to a slow module unload as we wait for something or
other to trigger the retirement flushing. Instead if we explicitly
cancel then
A CSB entry is 64b, and it is simpler for us to treat it as an array of
64b entries than as an array of pairs of 32b entries.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c
1 - 100 of 150 matches
Mail list logo
