Quoting Huang, Sean Z (2020-11-15 23:07:54)
> Rename the whitelist to allowlist as suggested
This patch should really be a separate series and most likely needs to
be done in one go to avoid confusion.
$ git grep -E '(whitelist|blacklist)' | wc -l
173
The next patch also uses "passlist" terminol
Quoting Huang, Sean Z (2020-11-15 23:07:53)
> Enable one ioctl action to allow ring3 driver to set its ring3
> context, so ring0 PXP can track the context id through this ring3
> context list.
Overall the patches should refer to "userspace" not "ring3" to avoid
confusion. "kernel" vs "user" not ri
Quoting Huang, Sean Z (2020-11-15 23:07:49)
> PXP (Protected Xe Path) is an i915 componment, that
> helps ring3 to establish the hardware protected session and
> manage the status of each alive software session, as well as
> the life cycle of each session.
>
> By design PXP will expose ioctl so al
Hi Dave & Daniel,
Here goes the drm-intel-gt-next PR for 5.11.
Most importantly there is a healthy chunk of Tigerlake
related fixes and a fix for user reported issue #2381 where
graphics output would stop at "switching to inteldrmfb from
simple".
Fixes to DMA mapped sg usage in i915 to unblock i
Quoting Jonny Grant (2020-10-30 16:05:02)
>
>
> On 30/10/2020 10:54, Chris Wilson wrote:
> > Quoting Joonas Lahtinen (2020-10-30 10:17:17)
> >> + intel-gfx mailing list
> >>
> >> Quoting Joonas Lahtinen (2020-10-30 12:15:44)
> >>> Quoti
Quoting Lucas De Marchi (2020-11-05 03:04:22)
> On Wed, Nov 04, 2020 at 11:55:15AM +0200, Joonas Lahtinen wrote:
> >Quoting Lucas De Marchi (2020-10-27 06:46:18)
> >> GT_PERF_STATUS and RP_STATE_LIMITS were added a long time ago in
> >> commit 3b8d8d91d51c ("
+ Rodrigo,
Quoting Aditya Swarup (2020-10-21 16:32:08)
> From: Anusha Srivatsa
>
> - Inherit the gen12 workarounds.
> - Add placeholders to setup GT WA.
> - Extend permanent driver WA Wa_1409767108 to adl-s and
> Wa_14010685332 to adl-s.
> - Extend permanent driver WA Wa_1606054188 to adl-s
>
Quoting Chris Wilson (2019-12-22 16:40:46)
> From: Andi Shyti
>
> The GT system is becoming more and more a stand-alone system in
> i915 and it's fair to assign it its own debugfs directory.
>
> rc6, rps and llc debugfs files are gt related, move them into the
> gt debugfs directory.
>
> Signed
Quoting Lucas De Marchi (2020-10-27 06:46:18)
> GT_PERF_STATUS and RP_STATE_LIMITS were added a long time ago in
> commit 3b8d8d91d51c ("drm/i915: dynamic render p-state support for Sandy
> Bridge"). Other than printing their values in debugfs we don't do
> anything with them. There's not much us
Quoting Tvrtko Ursulin (2020-11-03 11:14:32)
>
>
> On 03/11/2020 02:53, Lu Baolu wrote:
> > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
> >>
> >> On 02/11/2020 02:00, Lu Baolu wrote:
> >>> Hi Tvrtko,
> >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
>
> On 29/09/2020 01:11, Lu Baolu wrote:
+ intel-gfx mailing list
Quoting Joonas Lahtinen (2020-10-30 12:15:44)
> Quoting Jonny Grant (2020-10-27 22:42:19)
> > Hello Jani, Joonas
> >
> > https://gitlab.gnome.org/GNOME/eog/-/issues/146
> >
> > Is this issue something you could debug?
>
&
Quoting john.c.harri...@intel.com (2020-10-28 16:58:23)
> From: John Harrison
>
> Update to the latest GuC firmware
>
> v2: Rebase to newer tree, updated a commit message (review feedback
> from Daniele) and dropped the patch to enable GuC/HuC loading by
> default as apparently this is not allow
Quoting Tvrtko Ursulin (2020-10-22 18:22:10)
>
> + Joonas for maintainer class question.
>
> On 15/10/2020 19:28, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > Update to the latest GuC firmware
> >
> > v2: Rebase to newer tree, updated a commit message (review feedback
> > f
+ Zhenyu & Zhi,
Should not we instead fix the reason why the errors happen instead of
rate-limiting them?
Regards, Joonas
Quoting Stefan Fritsch (2020-10-16 18:23:40)
> If linux is running as a guest and the host is doing igd pass-through
> with VT-d enabled, this message is logged dozens of tim
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to me.
Regards, Joonas
Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59)
> As reported by Sphinx:
>
> ./Docum
E index of tgl_mocs_table
> with desired value.
>
> Cc: Chris Wilson
> Cc: Lucas De Marchi
> Cc: Tomasz Lis
> Cc: Matt Roper
> Cc: Joonas Lahtinen
> Cc: Francisco Jerez
> Cc: Mathew Alwin
> Cc: Mcguire Russell W
> Cc: Spruit Neil R
> Cc: Zhou Cheng
>
Quoting Daniel Vetter (2020-10-01 18:13:26)
> On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula
> wrote:
> >
> > On Thu, 01 Oct 2020, Daniel Vetter wrote:
> > > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
> > >>
> > >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > >
Quoting paul...@kernel.org (2020-09-29 02:30:58)
> From: Thomas Gleixner
>
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
Change looks fine:
Reviewed-by: Joonas Lahtinen
Are you looking for us to merge or m
Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests
> > into
> > two the drm-intel/for-linux-next branch is now missing material f
(+ intel-gfx for being i915 related)
(+ Chris who has looked into the issue)
Hi,
Thanks for reporting!
Could you open a bug report according to following instructions:
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
A full dmesg of a bad boot and git bisect logs will be
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> ---
> tests/i915/gem_exec_parallel.c | 31 +--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/tests/i915/gem_exec_parallel.c b/tests/i915/gem_exec_parallel.c
> index bf94b93d4..96feb
+ Dave and Daniel
+ Stephen
Quoting Christoph Hellwig (2020-09-26 09:29:59)
> On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> >
> > > this series removes alloc_vm_area, which was left over from the big
> > > vmalloc
e kernel patches, the right thing to do.
Acked-by: Joonas Lahtinen
Regards, Joonas
> ---
> tests/i915/gem_ctx_persistence.c | 92
> 1 file changed, 92 insertions(+)
>
> diff --git a/tests/i915/gem_ctx_persistence.c
> b/tests/i915/gem_ctx_pers
check for hung contexts -- but we did not prevent those
> contexts from being resubmitted if they survived the final hangcheck.
>
> Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
> Testcase: igt/gem_ctx_persistence/heartbeat-stop
> Signed-
+ Jani and Ville
Quoting Matthew Auld (2020-09-11 11:56:56)
> On 11/09/2020 06:42, Dave Airlie wrote:
> > I've just been looking at the current DG1 uapi, and I can't see any
> > flag to allow userspace to upfront say it was a contiguous vram BO.
> >
> > I think you'd really want this for scanout,
Hi Dave & Daniel,
Exactly same content as previous PR:
https://lists.freedesktop.org/archives/intel-gfx/2020-September/247626.html
Just rebased adding the missing S-o-b:s and updated "Fixes:" tags accordingly
as requested.
Regards, Joonas
***
drm-intel-gt-next-2020-09-07:
(Same content as dr
Hi Dave & Daniel,
Here goes the GT pull request for v5.10. It's the same patches as
previously at "topic/drm-intel-gem-next", one dropped and a few
re-ordered while creating the "drm-intel-gt-next" branch. So the
patches have been part of drm-tip already for weeks.
More about the PR itself at the
Quoting Dave Airlie (2020-07-13 08:09:30)
> On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote:
> >
> > We need to add support for pwrite'ing an LMEM object.
>
> why? DG1 is a discrete GPU, these interfaces we already gross and
> overly hacky for integrated, I'd prefer not to drag them across into
Quoting Dave Airlie (2020-07-14 22:26:16)
> On Wed, 15 Jul 2020 at 02:57, Tang, CQ wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Auld, Matthew
> > > Sent: Tuesday, July 14, 2020 8:02 AM
> > > To: Dave Airlie
>
Quoting Dave Airlie (2020-07-20 00:52:19)
> On Thu, 16 Jul 2020 at 20:11, Matthew Auld wrote:
> >
> > On 16/07/2020 01:43, Dave Airlie wrote:
> > > On Wed, 15 Jul 2020 at 00:35, Matthew Auld wrote:
> > >>
> > >> On 13/07/2020 06:09, Dave Airlie wrote:
> > >>> On Fri, 10 Jul 2020 at 22:00, Matthew
Hi Dave & Daniel,
(Covering for Jani here for drm-intel-next-fixes)
5 new commits over drm-intel-next here.
Fix for KASAN detected race condition and linux-next scheduler
WARNs. Patch to avoid IRQ spinlock and Cc: stable PMU refcount
update.
CI machinery needed some kicking, so results didn't a
Quoting Zhenyu Wang (2020-07-20 11:05:41)
>
> Hi,
>
> Sorry that this might be a bit late as last week our QA people were
> busy on something else..So this is gvt changes queued for 5.9 which is
> to improve guest suspend/resume with proper PCI PM state tracking for
> resource handling, e.g ppgtt
Hi,
Based on there being no replies, I'll assume the below mentioned
patches can be skipped.
There is one new commit, which I'll skip considering we're at -rc7
already:
b588e7015c92 ("drm/i915: Provide the perf pmu.module")
Regards, Joonas
Quoting Jani Nikula (2020-07-15 16:16:19)
>
> Hi all
Quoting Zhenyu Wang (2020-06-17 07:34:18)
>
> Hi,
>
> This contains misc fixes for gvt. Two MMIO handler fixes on SKL/CFL,
> one mask register bit checking fix exposed in suspend/resume path and
> one lockdep error fix for debugfs entry access.
Could not pull this one due to the extra hassle wit
Hi Dave & Daniel,
-rc1 required the usual juggling to get baseline from CI.
Needed to temporarily apply this fixup to drm-intel-fixes:
"ext4: mballoc: Use this_cpu_read instead of this_cpu_ptr"
For display side, fix for TypeC interrupt storm detection. Fixes to
TypeC, DDI and MST hardware registe
Quoting Stephen Rothwell (2020-06-16 02:39:12)
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5972:
> drivers/gpu/drm/i915/gt/selftest_lrc.c: In function
> 'liv
Quoting Joonas Lahtinen (2020-06-10 12:37:00)
> Hi Dave & Daniel,
>
> Sending this one early for it to hopefully make it in before -rc1.
>
> Two important fixes: OOPS fix that was missing "Fixes:" tag and
> not picked up earlier. Also fix for a use-after-free in
Hi Dave & Daniel,
Sending this one early for it to hopefully make it in before -rc1.
Two important fixes: OOPS fix that was missing "Fixes:" tag and
not picked up earlier. Also fix for a use-after-free in cmdparser.
Additional fixup to module param types.
Regards, Joonas
***
drm-intel-next-fi
lication.
Now we have the worst coherency by default if an application is using
reserved entry, making it more likely to be noticed at develop time. And
even if it would not be noticed, modifying the entry for better
coherency should not functionally break the application.
Regards, Joonas
> >
drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions
Joonas Lahtinen (1):
Merge tag 'gvt-next-fixes-2020-05-28' of
https://github.com/intel/gvt-linux into drm-intel-next-fixes
Nathan Chancellor (1):
drm/i915: Mark check_shadow_context_ppgtt as maybe
Quoting Zhenyu Wang (2020-05-28 06:35:59)
>
> Hi,
>
> Here's two queued warning fixes for gvt-next. One is for clang warning
> on debug only function and another one from coccicheck to use ARRAY_SIZE.
Pulled now, thanks for the PR.
Regards, Joonas
>
> Thanks
> --
> The following changes since
Hi Dave & Daniel,
Two bigger fixes to corner case kernel access faults
and three workload scheduling fixups this week.
CI_DINF_191 at:
https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html?
I got gvt-next-fixes pull today, I'll pull it next week so it
has time to run through CI
ompute routine on PSR
Imre Deak (2):
drm/i915/tgl+: Fix interrupt handling for DP AUX transactions
drm/i915: Fix AUX power domain toggling across TypeC mode resets
Joonas Lahtinen (3):
Merge tag 'gvt-next-2020-05-12' of https://github.com/intel/gvt-linux
into drm-intel
t; Fixes: 2e46a2a0b014 ("drm/i915: Use explicit flag to mark unreachable
> intel_context")
> Fixes: 2b703bbda271 ("Merge drm/drm-next into drm-intel-next-queued")
> Signed-off-by: Chris Wilson
> Cc: Rodrigo Vivi
> Cc: Joonas Lahtinen
Reviewed-by: Joon
drm/i915: Stop sending DP SDPs on ddi disable
drm/i915/dp: Add compute routine for DP PSR VSC SDP
drm/i915/psr: Use new DP VSC SDP compute routine on PSR
Imre Deak (1):
drm/i915/tgl+: Fix interrupt handling for DP AUX transactions
Joonas Lahtinen (3):
Merge tag 'gvt-
Pushed using the note:: block. Thanks for the review and ack.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Zhenyu Wang (2020-05-12 12:40:17)
>
> Hi,
>
> This includes support for ppgtt update by LRI command which gvt
> replaces by shadow ppgtt, another small optimization for shadow
> ctx and one workload destroy cleanup.
This is now pulled. Thanks for the PR.
Regards, Joonas
>
> Thanks
> -
Quoting Dave Airlie (2020-05-14 04:28:17)
> On Thu, 14 May 2020 at 03:10, Joonas Lahtinen
> wrote:
> >
> > Ping for merging this? If there are no issues, I'd prefer to pull in
> > next gvt-next and tag the final pull sooner than later.
>
> Can you check
Ping for merging this? If there are no issues, I'd prefer to pull in
next gvt-next and tag the final pull sooner than later.
Regards, Joonas
Quoting Joonas Lahtinen (2020-04-30 15:49:04)
> Hi Dave & Daniel,
>
> Fix for performance regression GitLab #1698: Iris Plus 655 and
&g
Quoting Dave Airlie (2020-05-07 21:27:27)
> On Fri, 8 May 2020 at 01:44, Chris Wilson wrote:
> >
> > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin whic
Quoting Lionel Landwerlin (2020-04-28 13:08:16)
> Add 2 new properties to the i915-perf open ioctl to specify an array
> of GEM context handles as well as the length of the array.
>
> This can be used by drivers using multiple GEM contexts to implement a
> single GL context.
>
> Signed-off-by: Li
drm/i915/audio: error log non-zero audio power refcount after unbind
drm/i915/hdmi: remove unused intel_hdmi_hdcp2_protocol()
drm/i915: drop a bunch of superfluous inlines
drm/i915/audio: fix compressed_bpp check
Joonas Lahtinen (2):
Merge tag 'gvt-next-2020-04-22'
Quoting Zhenyu Wang (2020-04-26 05:46:19)
> On 2020.04.22 13:12:30 +0800, Zhenyu Wang wrote:
> >
> > Hi,
> >
> > Here's current gvt-next. This removes left non-upstream xen support bits
> > which will be kept out of tree instead. And several guest context shadow
> > optimizations from Yan.
> >
>
Quoting Sultan Alsawaf (2020-04-20 18:42:16)
> On Mon, Apr 20, 2020 at 12:02:39PM +0300, Joonas Lahtinen wrote:
> > I think the the patch should be dropped for now before the issue is
> > properly addressed. Either by backporting the mainline fixes or if
> > those are too big
Quoting Sultan Alsawaf (2020-04-20 19:15:14)
> On Mon, Apr 20, 2020 at 11:21:42AM +0300, Joonas Lahtinen wrote:
> > So it seems that the patch got pulled into v5.6 and has been backported
> > to v5.5 but not v5.4.
>
> You're right, that's my mistake.
Did applying
Quoting Greg KH (2020-04-14 11:23:44)
> On Tue, Apr 14, 2020 at 09:15:07AM +0100, Chris Wilson wrote:
> > Quoting Greg KH (2020-04-11 12:39:57)
> > > On Fri, Apr 10, 2020 at 07:17:38AM -0700, Sultan Alsawaf wrote:
> > > > On Fri, Apr 10, 2020 at 11:08:38AM +0200, Greg KH wrote:
> > > > > On Tue, Ap
Quoting Sultan Alsawaf (2020-04-20 08:24:19)
> Chris,
>
> Could you please look at this in earnest? This is a real bug that crashes my
> laptop without any kind of provocation. It is undeniably a bug in i915, and
> I've
> clearly described it in my patch. If you dont like the patch, I'm open to a
r struct drm_device based logging
drm/i915/stolen: prefer struct drm_device based logging
drm/i915/gt: prefer struct drm_device based logging
drm/i915/uc: prefer struct drm_device based logging
Joonas Lahtinen (3):
Merge drm/drm-next into drm-intel-next-queued
Merge tag &
Quoting Jani Nikula (2020-04-15 10:48:15)
> On Wed, 15 Apr 2020, Daniel Vetter wrote:
> > On Wed, Apr 15, 2020 at 8:40 AM Jani Nikula
> > wrote:
> >>
> >> On Wed, 08 Apr 2020, Maarten Lankhorst
> >> wrote:
> >> > Hey,
> >> >
> >> > Here's a pull request to pull in the DP PHY Compliance series.
> > --+--
> > HuC state | option B
> > --+--
> > no HuC hardware | -ENODEV
> > GuC fw disabled | -EOPNOTSUPP -> user decision, why error?
> > HuC fw disabled | -EOPNOTSUPP -> user decision, why error?
> > HuC
Quoting Bloomfield, Jon (2020-01-31 17:45:02)
> Reducing audience as this series is of high interest externally.
>
> I fully agree with Joonas' suggestion here, and we have been looking at doing
> just that. But can we iterate as a follow up patch series? Putting in the
> infra to support igt as
esetting the engine if it is active. If we are unable to
> reset the engine to remove hostile userspace, we should not allow
> userspace to opt into using non-persistent contexts.
>
> Fixes: a0e047156cde ("drm/i915/gem: Make context persistence optional")
> Signed-off-by:
Quoting Akeem G Abodunrin (2020-01-30 18:57:21)
> From: Prathap Kumar Valsan
>
> On gen7 and gen7.5 devices, there could be leftover data residuals in
> EU/L3 from the retiring context. This patch introduces workaround to clear
> that residual contexts, by submitting a batch buffer with dedicated
of the "dev_priv" dependency in display/.
>
> All the patches here are per-file and independent of each other. We could also
> pick and apply the ones that are least likely to conflict.
>
> Opinions?
Acked-by: Joonas Lahtinen
Regards, Joonas
xa_limit_32b, GFP_KERNEL);
> rcu_read_unlock();
> + if (!vm)
> + return -ENODEV;
> +
> + err = xa_alloc(&file_priv->vm_xa, &id, vm,
> + xa_limit_32b, GFP_KERNEL);
Reviewed-by: Joonas Lahtinen
Regards, Joonas
Hi Dave & Daniel,
Last pull request for 5.5. Then it's Jani's turn
to handle 5.6.
A fix for huge userptr objects and a fix that is
also cc stable, to correctly handle negative values
in engine->uabi_class/instance.
Regards, Joonas
***
drm-intel-fixes-2020-01-23:
- Avoid overflow with huge use
upport"). Remove alpha support.
>
> Cc: Arkadiusz Hiler
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tomi Sarvela
> Signed-off-by: Jani Nikula
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx maili
Quoting Stephen Rothwell (2020-01-20 23:34:24)
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
>
> Caused by commit
>
> d8fcca47e195 ("drm/i915/userptr: fix size calculation")
>
> I have reverted that commit for today
Hi Dave & Daniel,
Two new fixes still, the VMA activity fixes are overflow from
last week as I couldn't get CI results then.
One important uAPI fix for PMU names to comply with tools/perf,
thanks for our media team for noticing. A compile fix and two
VMA activity tracking fixes for error capture
Quoting Joonas Lahtinen (2020-01-09 15:34:58)
> Hi Dave & Daniel,
>
> Happy New Year, now back from the holiday break.
>
> A bunch of important fixes. Further fixes for the power/perf
> regressions caused by the past security fixes. Then fix for
> user reported GPU h
Hi Dave & Daniel,
Happy New Year, now back from the holiday break.
A bunch of important fixes. Further fixes for the power/perf
regressions caused by the past security fixes. Then fix for
user reported GPU hang regression. Revert to avoid screen flicker
caused by HDA audio. Then missing two W/A a
Quoting Wambui Karuga (2020-01-07 17:13:29)
> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/i915/intel_pch.c | 46 +---
Quoting Jani Nikula (2019-12-19 14:37:02)
> On Thu, 19 Dec 2019, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commits
> >
> > 987e379d7500 ("Revert "devtmpfs: use do_mount() instead of ksys_mount()"")
> > 9bd5ba4fe25a ("Revert "initrd: use do_mount() instead of ksys_mount()"")
> > fa31001c96a
et fence_work.ops before dma_fence_init
drm/i915/gem: Keep request alive while attaching fences
Gao Fred (1):
drm/i915/gvt: Fix guest boot warning
Joonas Lahtinen (1):
Merge tag 'gvt-fixes-2019-12-18' of https://github.com/intel/gvt-linux
into drm-intel-fixes
Matt
mmers
> +/* A simple estimator for the round-trip latency of an engine */
> +DECLARE_EWMA(delay, 6, 4)
i915_delay as the minimum to emphasis that this is specific tous,
with that name clarified;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
ine idles")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
;
> + if (front) {
> + intel_frontbuffer_invalidate(front, origin);
> + intel_frontbuffer_put(front);
> + }
> +}
Could be de-duped as by taking the vfunc as parameter, but that's
just by coincidence that parameters match.
The rest checks out, so with the loop removed:
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ect *obj,
> struct i915_vma_work {
> struct dma_fence_work base;
> struct i915_vma *vma;
> + struct drm_i915_gem_object *pin;
This would reach much nicer as "pinned" to me.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
_
Quoting Zhenyu Wang (2019-12-18 07:16:57)
>
> Hi,
>
> Here's current gvt fixes which has fix for vGPU display dmabuf,
> one guest reset warning and one locking issue. Details below.
Pulled, thanks for the PR. I'll send out this tomorrow along with
other fixes once CI results arrive.
I'll be out
d up back in userspace, we try again.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Dave & Daniel,
Two important user visible fixes; GPU hang on BDW/SKL when idling
and top of screen corruption on GLK+ when FBC enabled.
Fix to Tigerlake perf/OA, HDCP commit computation touching global
state.
Then two CI spotted corner cases, race condition about context
retirement and lockde
Quoting Jani Nikula (2019-12-11 12:36:10)
> On Fri, 15 Nov 2019, Chris Wilson wrote:
> > Quoting Jani Nikula (2019-11-15 11:04:28)
> >> On Fri, 15 Nov 2019, Chris Wilson wrote:
> >> > Quoting Jani Nikula (2019-11-15 10:18:40)
> >> >> Get rid of the module specific static variable.
> >> >>
> >> >
t;resv, NULL);
> + dma_resv_add_excl_fence(shadow->resv, &pw->base.dma);
> + dma_resv_unlock(shadow->resv);
> +
> + dma_fence_work_commit(&pw->base);
> + return 0;
> +}
After de-duping, I think this is just fine as far as the fences com
> +
> + if (ret == -EACCES) {
> + u32 bbs;
> +
> + bbs = MI_BATCH_BUFFER_START;
> + bbs |= MI_BATCH_NON_SECURE_I965;
> + if (IS_HAS
length -= len;
> + ptr += len;
> + src += len;
> + }
> + GEM_BUG_ON(!IS_ALIGNED((unsigned long)src, 16));
> +
> + i915_memcpy_from_wc(ptr, src, ALIGN(length, 16));
Could be a helper function.
R
econd comment is bit of a repetition, especially after the code
flow is simplified.
Either way;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Chris Wilson (2019-12-07 19:01:04)
> Declutter the calling interface by reducing the parameters to the
> i915_vma and associated offsets.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx
n
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Chris Wilson (2019-12-07 19:01:03)
> The cmdparser rejection debug is not for driver development, but for the
> user, for which we use a plain DRM_DEBUG().
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reg
; - rename the file intel_de.h
> - move intel_de_wait_for_* there too
> - also add de fw helpers
>
> Cc: Chris Wilson
> Cc: Daniele Ceraolo Spurio
> Cc: Joonas Lahtinen
> Cc: Lucas De Marchi
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> Signed-off-by: Jan
t to remind us we cannot add the check later.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
/gem: Take timeline->mutex to walk list-of-requests
Gao, Fred (2):
drm/i915/gvt: Refine non privilege register address calucation
drm/i915/gvt: Update force-to-nonpriv register whitelist
Joonas Lahtinen (1):
Merge tag 'gvt-next-fixes-2019-12-02' of
https://github.co
Quoting Zhenyu Wang (2019-12-05 08:11:41)
>
> ping..
This was pulled, but my dim push was interrupted so I had to re-push and
wait for CI results. Looks all good. Thanks for the PR.
Do you have a plan to start adding Fixes: and Link: tags to the GVT
commits?
Regards, Joonas
Hi Dave & Daniel,
Most importantly we have the fix to power regression that was
introduced by the security fixes. Then fix for query uAPI and
increase in request pre-emption timeout to accommodate super
heavy benchmarks.
Couple of display voltage programming fixes too.
Thanks to Chris for fixing
Quoting Niranjan Vishwanathapura (2019-11-27 21:23:56)
> >We should try to have the uAPI as final as early as possible. The
> >change process is harder the later it is done, even for RFC :)
> >
> >On the same note, I'm inclined to have I915_SVM_MIGRATE called
> >I915_GEM_VM_PREFAULT from the start,
Quoting Chris Wilson (2019-11-25 17:27:09)
> One does not lightly add a new hidden struct_mutex dependency deep within
> the execbuf bowels! The immediate suspicion in seeing the whitelist
> cached on the context, is that it is intended to be preserved between
> batches, as the kernel is quite adep
so that we should not
> > adversely affect existing clients.
> >
> > 640ms ought to be enough for anyone.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112169
> > Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption")
> &
Quoting Niranjana Vishwanathapura (2019-11-22 22:57:21)
> Shared Virtual Memory (SVM) allows the programmer to use a single virtual
> address space which will be shared between threads executing on CPUs and GPUs.
> It abstracts away from the user the location of the backing memory, and hence
> simp
Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)
> On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
> >Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
> >> Shared Virtual Memory (SVM) runtime allocator support allows
> >> binding a shared virtual address to a buffer objec
ges.
>
> Cc: Joonas Lahtinen
> Cc: Jon Bloomfield
> Cc: Daniel Vetter
> Cc: Sudeep Dutt
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Venkata Sandeep Dhanalakota
Having this as a separate commit ahead of the functionality breaks
bisecting.
The uAPI should be e
201 - 300 of 2919 matches
Mail list logo
