Re: [PATCH] drm/i915/display: Introduce Display Metrics info

On Tue, 2024-05-07 at 08:48 -0400, Rodrigo Vivi wrote: > On Mon, May 06, 2024 at 11:19:56PM -0400, Kumar, Naveen1 wrote: > > > > > > > -Original Message- > > > From: Vivi, Rodrigo > > > Sent: Monday, May 6, 2024 10:52 PM > > > To: Kumar, Naveen1 > > > Cc:

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank

On Fri, 2023-11-17 at 11:50 -0500, Rodrigo Vivi wrote: > On Fri, Nov 17, 2023 at 11:26:44AM +0200, Ville Syrjälä wrote: > > On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote: > > > On Fri, Nov 17, 2023 at 08:05:21AM +, Coelho, Luciano wrote: > > > > Thanks for your comments, Ville!

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove early/pre-production Haswell code

On Fri, 2023-10-06 at 09:31 +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > It is not our policy to keep pre-production hardware support for this long > so I guess this one was just forgotten. Wouldn't it make sense to also remove the PCI IDs if they never made it to the real production

Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware

On Thu, 2023-04-13 at 11:20 +0200, Andi Shyti wrote: > From: Paulo Zanoni Hi https://en.wikipedia.org/wiki/Ship_of_Theseus My original patch was written in 2018. Since then, the implementation has been rebased and changed multiple times, the commit message has been changed, the subject line has

Re: [Intel-gfx] [PATCH v10 00/23] drm/i915/vm_bind: Add VM_BIND functionality

On Tue, 2023-01-17 at 23:15 -0800, Niranjana Vishwanathapura wrote: > DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM > buffer objects (BOs) or sections of a BOs at specified GPU virtual > addresses on a specified address space (VM). Multiple mappings can map > to the same

Re: [Intel-gfx] [PATCH v9 10/23] drm/i915/vm_bind: Add out fence support

On Mon, 2022-12-12 at 15:15 -0800, Niranjana Vishwanathapura wrote: > Add support for handling out fence for vm_bind call. > > v2: Reset vma->vm_bind_fence.syncobj to NULL at the end > of vm_bind call. > v3: Remove vm_unbind out fence uapi which is not supported yet. > v4: Return error if

Re: [Intel-gfx] [PATCH 0/2] drm/i915: Remove frontbuffer tracking from gem.

Hi I was given a link to https://patchwork.freedesktop.org/series/111494/ but can't seem to find it on the mailing list, so I'll reply here. On Thu, 2022-08-25 at 08:46 +0200, Maarten Lankhorst wrote: > Frontbuffer tracking in gem is used in old drivers, but nowadays everyone > calls dirtyfb

Re: [Intel-gfx] [PATCH v7 00/20] drm/i915/vm_bind: Add VM_BIND functionality

On Sat, 2022-11-12 at 23:57 -0800, Niranjana Vishwanathapura wrote: > DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM > buffer objects (BOs) or sections of a BOs at specified GPU virtual > addresses on a specified address space (VM). Multiple mappings can map > to the same

Re: [Intel-gfx] [PATCH v6 00/20] drm/i915/vm_bind: Add VM_BIND functionality

On Thu, 2022-11-10 at 15:05 +, Matthew Auld wrote: > On 10/11/2022 14:47, Tvrtko Ursulin wrote: > > > > On 10/11/2022 05:49, Niranjana Vishwanathapura wrote: > > > On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote: > > > > On Mon,

Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/vm_bind: Implement bind and unbind of object

On Thu, 2022-11-10 at 08:32 -0800, Niranjana Vishwanathapura wrote: > On Wed, Nov 09, 2022 at 05:28:59PM -0800, Zanoni, Paulo R wrote: > > On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: > > > Add uapi and implement support for bind and unbind

Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/vm_bind: Implement bind and unbind of object

On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: > Add uapi and implement support for bind and unbind of an > object at the specified GPU virtual addresses. > > The vm_bind mode is not supported in legacy execbuf2 ioctl. > It will be supported only in the newer execbuf3 ioctl.

Re: [Intel-gfx] [PATCH v6 00/20] drm/i915/vm_bind: Add VM_BIND functionality

On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: > DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM > buffer objects (BOs) or sections of a BOs at specified GPU virtual > addresses on a specified address space (VM). Multiple mappings can map > to the same

Re: [Intel-gfx] [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support

On Mon, 2022-11-07 at 00:52 -0800, Niranjana Vishwanathapura wrote: > Asynchronously unbind the vma upon vm_unbind call. > Fall back to synchronous unbind if backend doesn't support > async unbind or if async unbind fails. > > No need for vm_unbind out fence support as i915 will internally >

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

On Thu, 2022-06-30 at 09:18 -0700, Niranjana Vishwanathapura wrote: > On Wed, Jun 29, 2022 at 11:39:52PM -0700, Zanoni, Paulo R wrote: > > On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote: > > > On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote: &g

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote: > On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote: > > On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote: > > > VM_BIND and related uapi definitions > > > > > >

Re: [Intel-gfx] [PATCH v6 1/3] drm/doc/rfc: VM_BIND feature design document

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote: > VM_BIND design document with description of intended use cases. > > v2: Reduce the scope to simple Mesa use case. > v3: Expand documentation on dma-resv usage, TLB flushing and > execbuf3. > v4: Remove vm_bind tlb flush

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote: > VM_BIND and related uapi definitions > > v2: Reduce the scope to simple Mesa use case. > v3: Expand VM_UNBIND documentation and add > I915_GEM_VM_BIND/UNBIND_FENCE_VALID > and I915_GEM_VM_BIND_TLB_FLUSH flags. > v4:

Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition

On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote: > VM_BIND and related uapi definitions > > v2: Ensure proper kernel-doc formatting with cross references. > Also add new uapi and documentation as per review comments > from Daniel. > > Signed-off-by: Niranjana

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote: > VM_BIND design document with description of intended use cases. > > v2: Add more documentation and format as per review comments > from Daniel. > > Signed-off-by: Niranjana Vishwanathapura > --- > > diff --git

Re: [Intel-gfx] [PATCH RESEND i-g-t 1/2] tests/kms_frontbuffer_tracking: Skip if CRTC not selected

Em Qua, 2017-04-26 às 15:40 -0300, Gabriel Krisman Bertazi escreveu: > Paulo Zanoni writes: > > > > > Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi > > escreveu: > > > > > > After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline > > >

Re: [Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC

Em Qui, 2016-12-08 às 17:00 +0100, Daniel Vetter escreveu: > On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote: > > > > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: > > > > > > This series implements following set of functionality > > > Implement IPC WA's for

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: unconditionally apply the memory bandwidth WA

Em Seg, 2016-10-10 às 16:34 -0400, Lyude Paul escreveu: > Was there a new workaround added recently? Or was this something I > just > missed when writing the original code for this It's listed on the public spec: https://01.org/sites/default/files/docum

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen9: fix watermarks when using the pipe scaler

Em Sex, 2016-10-07 às 17:13 -0300, Paulo Zanoni escreveu: > Luckily, the necessary adjustments for when we're using the scaler > are > exactly the same as the ones needed on ILK+, so just reuse the > function we already have. Now that I sent it, I realized that I should just have inverted the

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size

Em Seg, 2016-09-19 às 15:19 -0300, Paulo Zanoni escreveu: > Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu: > > > > From: Mahesh Kumar > > > > This patch make changes to use linetime latency instead of > > allocated > > DDB size during plane watermark

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

Em Qua, 2016-09-14 às 10:22 +0100, Chris Wilson escreveu: > On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote: > > > > I was looking at some wait_for() timeouts on a slow system, with > > lots of > > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were > > mishandling the

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

Em Qua, 2016-09-14 às 12:59 +0300, Jani Nikula escreveu: > On Tue, 13 Sep 2016, "Zanoni, Paulo R" <paulo.r.zan...@intel.com> > wrote: > > > > I got confirmation from the Hardware guys that KBL does need to run > > the > > SAGV code, and it has the sam

Re: [Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

Em Qua, 2016-09-14 às 12:34 +0300, Jani Nikula escreveu: > On Wed, 14 Sep 2016, Paulo Zanoni wrote: > > > > Hi > > > > Here's the series with the reviews implemented. There's a new > > patch, > > based on the additional issue spotted by Lyude. > > There's a bunch of

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

Em Ter, 2016-09-13 às 20:40 +0100, Chris Wilson escreveu: > I was looking at some wait_for() timeouts on a slow system, with lots > of > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were > mishandling the timeout, I tried to ensure that we loop at least once > after first testing

Re: [Intel-gfx] [PATCH 5/8] drm/i915/gen9: minimum scanlines for Y tile is not always 4

Em Qua, 2016-09-07 às 19:03 -0400, Lyude escreveu: > On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote: > > > > During watermarks calculations, this value is used in 3 different > > places. Only one of them was not using a hardcoded 4. Move the code > > up > > so everybody can benefit from

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

Em Qua, 2016-09-07 às 12:17 -0400, Lyude escreveu: > I'm not sure that kbl has this either. The kbl machine I've been > working with thus-far has passed a few modesetting stress tests with > the chameleon, and I don't have anything trying to control sagv stuff > on it. > > This being said though

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Em Seg, 2016-09-12 às 21:25 +0100, Chris Wilson escreveu: > On Mon, Sep 12, 2016 at 05:02:56PM -0300, Paulo Zanoni wrote: > > > > Ever since I started working on FBC I was already aware that FBC > > can > > really amplify the FIFO underrun symptoms. On systems where FIFO > > underruns were

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

Hi Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu: > In the next patch we want to handle reset directly by a locked waiter > in > order to avoid issues with returning before the reset is handled. To > handle the reset, we must first know whether we hold the > struct_mutex. > If we do

Re: [Intel-gfx] [PATCH 1/8] drm/i915: SAGV is not SKL-only, so rename a few things

Em Qua, 2016-09-07 às 12:05 -0400, Lyude escreveu: > My only thought is that it seems like we prefix functions skl_, kbl_, > etc. just to indicate which generation introduced the feature. Skl > uses > quite a few sandybridge and haswell functions. If this is a little > closer to what most intel

Re: [Intel-gfx] [PATCH 2/8] drm/i915: introduce intel_has_sagv()

Em Sex, 2016-09-09 às 11:06 +0300, Jani Nikula escreveu: > On Thu, 08 Sep 2016, Lyude Paul wrote: > > > > On Thu, 2016-09-08 at 11:59 +0300, Jani Nikula wrote: > > > > > > On Wed, 07 Sep 2016, Lyude wrote: > > > > > > > > > > > > On Tue, 2016-09-06 at

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Em Sex, 2016-09-02 às 05:58 +, Pandiyan, Dhinakaran escreveu: > On Mon, 2016-08-15 at 19:36 -0300, Paulo Zanoni wrote: > > > > Ever since I started working on FBC I was already aware that FBC > > can > > really amplify the FIFO underrun symptoms. On systems where FIFO > > underruns were

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

Em Sex, 2016-09-02 às 17:16 +0530, Mahesh Kumar escreveu: > Hi, > > On Wednesday 31 August 2016 07:17 PM, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu: > > > > > > Hi > > > > > >

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

Hi Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu: > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: > > > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > > > > > > We seem to have an xrandr regression with skylake now.  What's > > > happening is that I can

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu: > Hi > > Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu: > > > > This patch enables Transition WM for SKL+ platforms. > > > > Transition WM are used if IPC is enabled, to decide, numbe

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

Hi Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu: > This patch enables Transition WM for SKL+ platforms. > > Transition WM are used if IPC is enabled, to decide, number of blocks > to be fetched before reducing the priority of display to fetch from > memory. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hsw+: set intel_crtc active once pipe is active

Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu: > Set the intel_crtc->active flag after pipe/crtc is actually active in > haswell_crtc_enable function. Why? Can you please elaborate more on why this change is needed, what are the benefits it brings, what are the problems it solves and

Re: [Intel-gfx] [CI] Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen"

Em Qua, 2016-08-24 às 19:00 +0100, Chris Wilson escreveu: > This reverts commit 8678fdaf396c ("drm/i915/fbc: Allow on unfenced > surfaces, > for recent gen") as Skylake has issues with unfenced FBC tracking > (and > yes Skylake doesn't even enable FBC yet) But it used to work if you had

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Switch to using the DRM function for reading DP link status

Em Qua, 2016-08-17 às 12:02 -0700, Dhinakaran Pandiyan escreveu: > Since a DRM function that reads link DP link status is available, > let's > use that instead of the i915 clone. One could describe the i915 function as a convenient wrapper instead of a clone, since it allows passing just intel_dp

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

Later iterations of fbc are > > > more > > > flexible and allow operation on unfenced frontbuffers. > > > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > > Cc: Daniel Vetter <daniel.vet...@intel.com> > > > Cc: "Zanoni, Pau

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

l.vet...@intel.com> > Cc: "Zanoni, Paulo R" <paulo.r.zan...@intel.com> Hi I see this patch was applied. Now, on my Skylake machine, if I boot with i915.enable_fbc=1 I'll get FIFO underruns under fbcon. Just booting already gives me a FIFO underrun message, and then if I "

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

t some workarounds we skipped. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Daniel Vetter <daniel.vet...@intel.com> > Cc: "Zanoni, Paulo R" <paulo.r.zan...@intel.com> > --- >  drivers/gpu/drm/i915/intel_fbc.c | 6 -- >  1

Re: [Intel-gfx] [PATCH] drm/i915: Mark up the GTT flush following WC writes as ORIGIN_CPU

Em Qua, 2016-08-17 às 19:20 +0100, Chris Wilson escreveu: > Similarly to invalidating beforehand, if the object is mmapped via > I915_MMAP_WC we cannot track writes through the I915_GEM_DOMAIN_GTT. > At > the conclusion of the write, i915_gem_object_flush_gtt_writes() we > also > need to treat the

Re: [Intel-gfx] [PATCH] drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip

Em Qua, 2016-08-17 às 20:49 +0100, Chris Wilson escreveu: > On Wed, Aug 17, 2016 at 04:41:44PM -0300, Paulo Zanoni wrote: > > > > From: Chris Wilson > > > > intel_fbc_pre_update() depends upon the new state being already > > pinned > > in place in the Global GTT

Re: [Intel-gfx] [PATCH] drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip

nd > nonblocking...") I think it actually fixes e8216e502acaad129210c3c8b30cb4ab41e70239 ("drm/i915/fbc: call intel_fbc_pre_update earlier during page flips"). > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Daniel Vetter <daniel.vet...@intel.com>

Re: [Intel-gfx] [PATCH 11/25] drm/i915/fbc: fix the FBC state checking code

Em Seg, 2016-08-15 às 21:55 +0100, Chris Wilson escreveu: > On Tue, Jan 19, 2016 at 11:35:44AM -0200, Paulo Zanoni wrote: > > > > We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate > > during atomic commits. This will continue to guarantee that we > > deactivate FBC and it will

Re: [Intel-gfx] drm/i915/fbc: disable FBC on FIFO underruns

Em Sáb, 2016-08-13 às 10:05 +0100, Chris Wilson escreveu: > On Fri, Aug 12, 2016 at 11:24:59PM +, Pandiyan, Dhinakaran wrote: > Do we know why we get black screens in this scenario? I don't know exactly, but I can speculate that it's probably because the display engine fails to decompress the

Re: [Intel-gfx] [PATCH v10] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Em Ter, 2016-08-09 às 14:44 +0200, Maarten Lankhorst escreveu: > Hey, > > Op 08-08-16 om 23:03 schreef Lyude: > > > > Since the watermark calculations for Skylake are still broken, > > we're apt > > to hitting underruns very easily under multi-monitor > > configurations. > > While it would be

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

Em Seg, 2016-08-08 às 19:35 +0100, Chris Wilson escreveu: > On Mon, Aug 08, 2016 at 06:25:49PM +0000, Zanoni, Paulo R wrote: > > > > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu: > > > > > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: &

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

Em Seg, 2016-08-08 às 18:25 +, Zanoni, Paulo R escreveu: > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu: > > > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: > > > > > > > > > Reviewed-by: Lyude <cp...@redhat.com> >

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu: > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: > > > > Reviewed-by: Lyude > > Merged to dinq.  Thanks for the quick review. Regression? This patch makes my SKL machine fail any modesets. I now boot to a

Re: [Intel-gfx] [PATCH] drm/i915: remove redundant fbc warnings

Em Ter, 2016-07-05 às 10:28 +0100, Matthew Auld escreveu: > The fbc enabled/active sanity checks are already done in > __intel_fbc_disable so no need to do them again. > > Signed-off-by: Matthew Auld Reviewed-by: Paulo Zanoni > --- >  

Re: [Intel-gfx] [PATCH v3] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Em Qua, 2016-06-22 às 21:34 +0100, Chris Wilson escreveu: > On Tue, Jun 21, 2016 at 03:31:25PM +0200, Daniel Vetter wrote: > > > > On Tue, Jun 21, 2016 at 08:25:27AM +0100, Chris Wilson wrote: > > > > > > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC > > > Are Enabled > > > >

Re: [Intel-gfx] [PATCH v3] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Em Ter, 2016-06-21 às 08:25 +0100, Chris Wilson escreveu: > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are > Enabled > > "Display flickering may occur when both FBC (Frame Buffer > Compression) > and VT - d (Intel® Virtualization Technology for Directed I/O) are > enabled >

Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

Em Sex, 2016-06-10 às 08:44 +0200, Stefan Richter escreveu: > On Jun 09 Zanoni, Paulo R wrote: > > > > Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu: > > > > > > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : > > > > > > This w

Re: [Intel-gfx] [PATCH] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Em Sex, 2016-06-17 às 17:39 +0100, Chris Wilson escreveu: > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are > Enabled > > "Display flickering may occur when both FBC (Frame Buffer > Compression) > and VT - d (Intel® Virtualization Technology for Directed I/O) are > enabled >

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Em Seg, 2016-06-13 às 13:47 +0200, Stefan Richter escreveu: > On Jun 10 Paulo Zanoni wrote: > > > > Since my test machines don't produce FIFO underrun errors, I tested > > this by > > creating a debugfs file that just calls > > intel_fbc_handle_fifo_underrun(). I'd > > appreciate some Tested-by

Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu: > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : > > This was kind of a difficult bug to track down. If you're using a > Haswell system running GNOME and you have fbc completely enabled and > working, playing videos can result in video

Re: [Intel-gfx] Screen update issue (drm/i915/fbc: enable FBC by default on HSW and BDW)

Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu: > Hi, Hi CC'ing the mailing list. > > With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by > default, I get a strange issue with screen update/refresh (sorry if > my > terminology is off - I'm not a graphics dev!). >

Re: [Intel-gfx] [PATCH v4 1/4] drm: Add helper for DP++ adaptors

Em Ter, 2016-05-03 às 20:56 +0300, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Add a helper which aids in the identification of DP dual mode > (aka. DP++) adaptors. There are several types of adaptors > specified: type 1 DVI, type 1 HDMI, type

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

Em Sex, 2016-05-06 às 00:54 +0200, Stefan Richter escreveu: > On May 05 Zanoni, Paulo R wrote: > > > > Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu: > > > > > > Oh, and in case you - the person reading this commit message > > > - foun

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu: > On Apr 30 Stefan Richter wrote: > > > > On Apr 29 Stefan Richter wrote: > > > > > > On Apr 26 Stefan Richter wrote:   > > > > > > > > v4.6-rc solidly hangs after a short while after boot, login to > > > > X11, and > > > > doing

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Add lspcon core functions

Em Ter, 2016-05-03 às 21:44 +0530, Sharma, Shashank escreveu: > > On 5/3/2016 9:39 PM, Ville Syrjälä wrote: > > > > On Tue, May 03, 2016 at 09:18:49PM +0530, Sharma, Shashank wrote: > > > > > > Regards > > > Shashank > > > > > > On 5/2/2016 7:21 PM, Ville Syrjälä wrote: > > > > > > > > On

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Add and initialize lspcon connector

Em Seg, 2016-04-04 às 17:31 +0530, Shashank Sharma escreveu: > lspcon is a device which acts as DP in some cases > and as HDMI in some. Here is how: > - lspcon needs DP(aux) for all the i2c_ove_aux read/write >   transitions so it needs to have some DP level initializations > - lspcon is detected

Re: [Intel-gfx] [PATCH i-g-t 1/2] kms_pipe_crc_basic: Only test one pipe in the basic set

Em Seg, 2016-04-25 às 10:45 +0100, Tvrtko Ursulin escreveu: > On 25/04/16 09:51, Daniel Vetter wrote: > > > > On Fri, Apr 22, 2016 at 04:11:11PM +0100, Chris Wilson wrote: > > > > > > On Fri, Apr 22, 2016 at 03:41:55PM +0100, Tvrtko Ursulin wrote: > > > > > > > > From: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add sys PSR toggle interface

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > This interface allows an immediate enabling of PSR feature. What > allow us > to see immediately the PSR savings and will allow us to expose this > through sysfs interface for powertop to leverage its functionality. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > This project is explained in detail on the HAS > https://docs.google.com/a/intel.com/document/d/1E-en_xqfHgCnhD1Tes3f0 > 8UYrOc-etv2W-pU0ZErKdE/edit?usp=sharing   > > Summary:  > Permits the user to identify and toggle values for PSR,

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Add sys FBC toggle interface

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > This interface allows an immediate enabling of FBC feature. What > allow us > to see immediately the FBC There's no way to guarantee the user will immediately see any FBC savings. FBC depends on a lot of conditions (e.g., X tiling,

Re: [Intel-gfx] [PATCH 0/4] Enable FBC on SKL, v3

Em Qua, 2016-04-06 às 10:36 +0530, Thulasimani, Sivakumar escreveu: > dont want to hijack thread but wanted to point out a possible > regression  > in the > previous patches of this series. > > intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug) How? It will check for

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

Em Sex, 2016-04-01 às 17:45 +0300, Ville Syrjälä escreveu: > On Thu, Mar 31, 2016 at 10:06:37PM +0000, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com > > escreveu: > > > > > > From: Ville Syrjälä <vill

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > DP dual mode type 1 DVI adaptors aren't required to implement any > registers, so it's a bit hard to detect them. The best way would > be to check the state of the

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

Em Qui, 2016-02-25 às 14:51 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > To save a bit of power, let's try to turn off the TMDS output buffers > in DP++ adaptors when we're not driving the port. > > v2: Let's not forget DDI, toss in a

Re: [Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors

Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Add a helper which aids in he identification of DP dual mode (aka. > DP++) > adaptors. There are several types of adaptors specified: > type 1 DVI, type 1 HDMI,

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

Em Qui, 2016-03-24 às 21:20 +, ch...@chris-wilson.co.uk escreveu: > On Thu, Mar 24, 2016 at 09:03:59PM +, ch...@chris-wilson.co.uk > wrote: > > > > On Thu, Mar 24, 2016 at 08:53:21PM +0000, Zanoni, Paulo R wrote: > > > > > > Em Qui, 2016-03-24 à

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

Em Qui, 2016-03-24 às 21:03 +, ch...@chris-wilson.co.uk escreveu: > On Thu, Mar 24, 2016 at 08:53:21PM +0000, Zanoni, Paulo R wrote: > > > > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu: > > > > > > On Thu, Mar 24, 2016 at 04:

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu: > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote: > > > > FBC and the frontbuffer tracking infrastructure were designed > > assuming > > that user space applications would follow a specific set of rules > > regarding

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable FDI RX before DDI_BUF_CTL

Em Qua, 2016-03-23 às 23:57 +0200, Ville Syrjälä escreveu: > On Wed, Mar 23, 2016 at 09:14:34PM +0000, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-03-01 às 16:16 +0200, ville.syrj...@linux.intel.com > > escreveu: > > > > > > From: Ville Syrjälä <ville.s

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable FDI RX before DDI_BUF_CTL

Em Ter, 2016-03-01 às 16:16 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists > FDI RX disable both as step 13 and step 18 in the sequence. But I dug > up an old BUN mail

Re: [Intel-gfx] [PATCH v5 8/8] drm/i915: Remove vblank wait from hsw_enable_ips, v2.

Em Qua, 2016-03-23 às 14:33 +0100, Maarten Lankhorst escreveu: > intel_post_plane_update did an extra vblank wait that's no longer > needed when enabling ips. > > Changes since v1: > - Add comment explaining why vblank wait is performed. (Paulo) > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [RFC xf86-video-intel] sna: Call dirtyfb for all non-tear-free cases

Em Qua, 2016-03-23 às 09:50 +0100, Daniel Vetter escreveu: > On Tue, Mar 22, 2016 at 09:35:36PM +0000, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu: > > > > > > On Mon, Mar 21, 2016 at 04:

Re: [Intel-gfx] [PATCH 4/4] drm/i915/fbc: enable FBC on SKL too

Em Ter, 2016-03-22 às 12:16 +0100, Daniel Vetter escreveu: > On Mon, Mar 21, 2016 at 04:26:58PM -0300, Paulo Zanoni wrote: > > > > Now that we're more protected against user space doing frontbuffer > > mmap rendering, the last - how many times did I say this before? - > > SKL problem seems to be

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

Em Ter, 2016-03-22 às 12:29 +0100, Daniel Vetter escreveu: > On Mon, Mar 21, 2016 at 04:26:57PM -0300, Paulo Zanoni wrote: > > > > FBC and the frontbuffer tracking infrastructure were designed > > assuming > > that user space applications would follow a specific set of rules > > regarding

Re: [Intel-gfx] [RFC xf86-video-intel] sna: Call dirtyfb for all non-tear-free cases

Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu: > On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote: > > > > The sna_mode_wants_tear_free() function tries to detect FBC and PSR > > based on Kernel module parameters. Currently it fails to detect FBC > > due to the default

Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbc: update busy_bits even for GTT and flip flushes

Em Ter, 2016-03-22 às 12:13 +0100, Daniel Vetter escreveu: > On Mon, Mar 21, 2016 at 04:26:54PM -0300, Paulo Zanoni wrote: > > > > We ignore ORIGIN_GTT because the hardware tracking can recognize > > GTT > > writes and take care of them. We also ignore ORIGIN_FLIP because we > > deal with flips

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Nuke fbc members from intel_crtc->atomic, v4.

Em Qua, 2016-03-09 às 10:35 +0100, Maarten Lankhorst escreveu: > Whenever there's an update to the primary plane, > fbc_pre_update and fbc_post_update are called. Kill off > intel_crtc->atomic.update_fbc and now that intel_crtc->atomic > is empty, kill it off too. > > Changes since v1: > - Add a

Re: [Intel-gfx] [PATCH i-g-t] kms_frontbuffer_tracking: Remove hardcoded PIPE_A

Em Sex, 2016-03-04 às 12:02 +0200, Gabriel Feceoru escreveu: > Use the pipe which is given from the possible_crcs for that connected > port > instead. > > On BSW there are constrains for the crtc<-->connector, this fix make > this test > passing on BSW. > > Signed-off-by: Gabriel Feceoru

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only recalculate wm's for planes part of the state, v2.

Em Ter, 2016-03-01 às 14:28 -0800, Matt Roper escreveu: > On Tue, Mar 01, 2016 at 11:07:22AM +0100, Maarten Lankhorst wrote: > > Only planes that are part of the state should be used for > > recalculating > > watermarks. For planes not part of the state the previous patch > > allows > > us to

Re: [Intel-gfx] [PATCH v1.1 1/2] drm/i915: Allow preservation of watermarks, v2.

Em Qua, 2016-03-02 às 12:38 +0100, Maarten Lankhorst escreveu: > As Paulo has noted we can help bisectability by separating computing > watermarks on a noop in 2 separate commits. > > This patch no longer clears the crtc watermark state, but > recalculates > it completely. Regardless whether a

Re: [Intel-gfx] [PATCH v4.1 6/8] drm/i915: Nuke fbc members from intel_crtc->atomic, v3.

Em Seg, 2016-02-29 às 10:58 +0100, Maarten Lankhorst escreveu: > Whenever there's an update to the primary plane, > fbc_pre_update and fbc_post_update are called. Kill off > intel_crtc->atomic.update_fbc and now that intel_crtc->atomic > is empty, kill it off too. > > Changes since v1: > - Add a

Re: [Intel-gfx] [PATCH v6 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.

Em Qua, 2016-02-24 às 11:24 +0100, Maarten Lankhorst escreveu: > Currently we perform our own wait in post_plane_update, > but the atomic core performs another one in wait_for_vblanks. > This means that 2 vblanks are done when a fb is changed, > which is a bit overkill. > > Merge them by creating

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/fbc: enable FBC by default on HSW and BDW

Em Qua, 2016-02-17 às 08:40 +, Patchwork escreveu: > == Summary == > > Series 3500v1 drm/i915/fbc: enable FBC by default on HSW and BDW > http://patchwork.freedesktop.org/api/1.0/series/3500/revisions/1/mbox > / > > Test pm_rpm: > Subgroup basic-pci-d3-state: > pass   

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Make the LPT iclkip 20MHz case more generic

Em Qua, 2016-02-17 às 21:41 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > The reason for spcial casing 20MHz in the iclkip calculations is that > it would overflow the 7 bit divisor value. Let's rewrite the special > case to check for

Re: [Intel-gfx] [PATCH v4 7/8] drm/i915: Do not compute watermarks on a noop.

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > No atomic state should be included after all validation when nothing > has > changed. During modeset all active planes will be added to the state, > while disabled planes won't change their state. As someone who is also not super

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

Em Qui, 2016-02-18 às 15:46 +0100, Maarten Lankhorst escreveu: > Op 18-02-16 om 15:14 schreef Zanoni, Paulo R: > > Em Qui, 2016-02-18 às 14:22 +0100, Maarten Lankhorst escreveu: > > > Op 17-02-16 om 22:20 schreef Zanoni, Paulo R: > > > > Em Qua, 2016-02-10 às

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

Em Qui, 2016-02-18 às 14:22 +0100, Maarten Lankhorst escreveu: > Op 17-02-16 om 22:20 schreef Zanoni, Paulo R: > > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > > > Currently we perform our own wait in post_plane_update, > > > but the atomi

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915: Pass crtc state to modeset_get_crtc_power_domains.

Em Qui, 2016-02-18 às 10:51 +0100, Maarten Lankhorst escreveu: > Op 17-02-16 om 18:54 schreef Zanoni, Paulo R: > > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > > > Use our newly created encoder_mask to iterate over the encoders. > > As someone who

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > Currently we perform our own wait in post_plane_update, > but the atomic core performs another one in wait_for_vblanks. > This means that 2 vblanks are done when a fb is changed, > which is a bit overkill. > > Merge them by creating

  1   2   >