Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix the channel equalization failure condition during Link Training

On Thu, Aug 17, 2017 at 08:03:04PM -0700, Manasi Navare wrote: > In the channel EQ retry loop, we break from the loop in case > of failure to get link status or failure in clock recovery or > failure to update link training. In these cases channel_eq_status > is still false even though the retry

Re: [Intel-gfx] [PATCH 4/4] drm/i915/cnl: Apply large line width optimization

On 08/15/2017 04:16 PM, Rodrigo Vivi wrote: From: Ben Widawsky This bit enables hardware that will change the approximation used for distances calculations for AA wide lines so that they are rendered more accurately. The default value for this bit leaves the

Re: [Intel-gfx] [PATCH 16/16] drm/i915: Reinstate GMBUS and AUX interrupts on gen4/g4x

On Fri, 18 Aug 2017, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that we're not using MSI anymore on gen4 we can start > using GMBUS and AUX interrupts again. These were disable on > account of them causing the hardware to somehow generate >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Redo old gmch irq handling (rev2)

Quoting Patchwork (2017-08-18 20:41:45) > == Series Details == > > Series: drm/i915: Redo old gmch irq handling (rev2) > URL : https://patchwork.freedesktop.org/series/26215/ > State : success > > == Summary == > > Series 26215v2 drm/i915: Redo old gmch irq handling >

Re: [Intel-gfx] [PULL] drm-misc-fixes

On Fri, Aug 18, 2017 at 11:57:34AM -0400, Sean Paul wrote: > Hi Dave, > Here's the latest and greatest from drm-misc-fixes. We have a couple nice > cleanups from Maarten centered around properly handling errors (and > specifically > EDEADLK) in atomic_check. They're not cleanups, stuff actually

[Intel-gfx] [PATCH] drm/doc: Document ioctl errno value patterns

We're not super-consistent about these, but I think it's worth to document at least the commmon patterns. v2: - Add a not about ENOTTY (it's just a confusing name, but used exactly what it's meant for in DRM) (Chris). - Unconfuse the text for ENODEV (Daniel) - Move text undert the IOCTL heading

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Redo old gmch irq handling (rev2)

== Series Details == Series: drm/i915: Redo old gmch irq handling (rev2) URL : https://patchwork.freedesktop.org/series/26215/ State : success == Summary == Series 26215v2 drm/i915: Redo old gmch irq handling https://patchwork.freedesktop.org/api/1.0/series/26215/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

On Fri, Aug 18, 2017 at 10:13:08PM +0200, Daniel Vetter wrote: > On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote: > > 2017-08-14 Maarten Lankhorst : > > > > > complete_crtc_signaling is freeing fence_state, but when retrying > > > num_fences and

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: make is_edp non-static and rename to intel_dp_is_edp

On Fri, Aug 18, 2017 at 12:30:20PM +0300, Jani Nikula wrote: > Expose across driver for future work. No functional changes. Reviewed-by: Jim Bride > Cc: Manasi Navare > Cc: Jim Bride > Signed-off-by: Jani Nikula

Re: [Intel-gfx] [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

2017-08-14 Maarten Lankhorst : > complete_crtc_signaling is freeing fence_state, but when retrying > num_fences and fence_state are not zero'd. This caused duplicate > fd's in the fence_state array, followed by a BUG_ON in fs/file.c > because we reallocate freed

[Intel-gfx] [PATCH] drm/i915: Re-enable per-engine reset for Broxton

The corruption in CSB mmio reads we were seeing has been tracked down to incorrectly touching forcewake of all domains, following an engine reset. It is still a mistery why we only catched this in Broxton, since it could happen in any platform. With that fix already merged, commit 4055dc75d6b5

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: make is_edp non-static and rename to intel_dp_is_edp

Thanks for the patch, will rebase my patch on top of this. Manasi On Fri, Aug 18, 2017 at 12:30:20PM +0300, Jani Nikula wrote: > Expose across driver for future work. No functional changes. > > Cc: Manasi Navare > Cc: Jim Bride >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make infoframe code available to (e)DP ports (rev3)

== Series Details == Series: drm/i915: Make infoframe code available to (e)DP ports (rev3) URL : https://patchwork.freedesktop.org/series/8183/ State : success == Summary == Series 8183v3 drm/i915: Make infoframe code available to (e)DP ports

[Intel-gfx] ✓ Fi.CI.BAT: success for i915, drm/fourcc: Improve the CCS modifier documentation

== Series Details == Series: i915, drm/fourcc: Improve the CCS modifier documentation URL : https://patchwork.freedesktop.org/series/29016/ State : success == Summary == Series 29016v1 i915, drm/fourcc: Improve the CCS modifier documentation

Re: [Intel-gfx] [PATCH 11/22] drm/i915: support 1G pages for the 48b PPGTT

-Auld/huge-gtt-pages/20170818-202207 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-a0-08190316 (attached as .config) compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All

Re: [Intel-gfx] [PULL] drm-misc-fixes

On Fri, Aug 18, 2017 at 4:19 PM, Daniel Vetter wrote: > On Fri, Aug 18, 2017 at 11:57:34AM -0400, Sean Paul wrote: >> Hi Dave, >> Here's the latest and greatest from drm-misc-fixes. We have a couple nice >> cleanups from Maarten centered around properly handling errors (and >>

Re: [Intel-gfx] [PATCH 1/4] drm/i915/cnl: Introduce initial Cannonlake Workarounds.

On 08/15/2017 04:16 PM, Rodrigo Vivi wrote: Let's inherit workarounds from previous platforms that according to wa_database and BSpec are still valid for Cannonlake. v2: Add missed workarounds. v3: Rebase v4: Remove bad chunk that was added to rc6 disable. (Ander) Also remove A0 W/a that

Re: [Intel-gfx] [PATCH v2 11/16] drm/i915: Rewrite GMCH irq handlers to avoid loops

Quoting ville.syrj...@linux.intel.com (2017-08-18 19:37:00) > From: Ville Syrjälä > > Eliminate the loops from the gen2-3 irq handlers. Since we don't use > MSI anymore on these platforms, and thus the CPU interrupt will be level > triggered, we shouldn't need to

Re: [Intel-gfx] [PATCH i-g-t v2] pm_rps: Changes in waitboost scenario

On Fri, Aug 18, 2017 at 02:45:32PM +0100, Chris Wilson wrote: > Quoting Katarzyna Dec (2017-08-18 12:08:44) > > While I'm here let's also make sure that we're running as DRM > > master to catch the common case, where the test is being ran > > along with Xorg. > > Semantic changes to the test

Re: [Intel-gfx] [PATCH] dim: Include TODO in sphinx docs

On Fri, Aug 18, 2017 at 12:34:39PM +0300, Jani Nikula wrote: > On Fri, 18 Aug 2017, Daniel Vetter wrote: > > More visibility > > > > Signed-off-by: Daniel Vetter > > Ack. > > I guess qf man page should be extracted from the script, and put here

[Intel-gfx] [PULL] drm-misc-next

Hi Dave, Here's the last of -misc-next for 4.14, we'll switch over to drm-misc-next-fixes now and drm-misc-next will target 4.15. I'll send a PSA to misc committers once the branches are set up. Since we just send a pull a few days ago, there's not much here, and the tl;dr is Noralf. We have the

[Intel-gfx] [PATCH 02/16] drm/i915: Clear pipestat consistently

From: Ville Syrjälä We have a lot of different ways of clearing the PIPESTAT registers. Let's unify it all into one function. There's no magic in PIPESTAT that would require any of the double clearing and whatnot that some of the code tries to do. All we can really

[Intel-gfx] [PATCH v2 03/16] drm/i915: s/GEN5/GEN3/

From: Ville Syrjälä The GEN5_IRQ_RESET/INIT macros are perfectly suitable even for gen3/4 hardware as those have 32 bit interrupt registers. Let's rename the macros to reflect that fact. Gen2 on the other hand has 16 bit interrupt registers so these macros aren't

[Intel-gfx] [PATCH 06/16] drm/i915: Setup EMR first on all gen2-4

From: Ville Syrjälä Unify the appaerance of the gen2-4 irq postinstall hooks a little bit by doing the EMR setup first on all the platforms. Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 05/16] drm/i915: Introduce GEN2_IRQ_RESET/INIT

From: Ville Syrjälä Unify the appearance of the gen2 irq code with the gen3+ code by introducing the GEN2_IRQ_RESET/INIT macros. Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 07/16] drm/i915: Eliminate PORT_HOTPLUG_EN setup from gen3/4 irq_postinstall

From: Ville Syrjälä We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook so doing it again in the .irq_postinstall is pointless. Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH v2 00/16] drm/i915: Redo old gmch irq handling

From: Ville Syrjälä Reposted GMCH irq rework series. A few patches fell out completely since the flip interrupt handling was nuked in the meantime. I also added a patch to remove some more flip irq leftover, and I tossed in a patch to reinstate GMBUS/AUX irqs on

[Intel-gfx] [PATCH 01/16] drm/i915: Don't enable/unmask flip interrupts

From: Ville Syrjälä commit fd3a40242e87 ("drm/i915: Rip out legacy page_flip completion/irq handling") removed the code to hande the flip done/pending interrupts, but it failed to actually disable/mask those interrupts. Let's do that now. Also remove a stale

[Intel-gfx] [PATCH v2 11/16] drm/i915: Rewrite GMCH irq handlers to avoid loops

From: Ville Syrjälä Eliminate the loops from the gen2-3 irq handlers. Since we don't use MSI anymore on these platforms, and thus the CPU interrupt will be level triggered, we shouldn't need to play any tricks with IER to induce edges from IIR. IIR itself still

[Intel-gfx] [PATCH 08/16] drm/i915: Unify the appearance of gen3/4 irq_postistall hooks

From: Ville Syrjälä Do the irq_mask/enable_mask setup in the same way on gen3/4, and also reorder the steps to make the code more uniform. Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 10/16] drm/i915: Extract PIPESTAT irq handling into separate functions

From: Ville Syrjälä Extract the gen2-4 PIPESTAT irq handling into separate functions just like we already do on VLV/CHV. We can share valleyview_pipestat_irq_ack() on all gmch platforms to actually read and clear the PIPESTAT status bits, so let's rename it to

[Intel-gfx] [PATCH 09/16] drm/i915: Remove NULL dev_priv checks from irq_uninstall

From: Ville Syrjälä There should be no way to land in irq_uninstall without a valid dev_priv. Let's kill off the remaining checks, which are probably some kind of UMS leftovers. Not all the irq_uninstall hooks even had them anymore. Reviewed-by: Chris Wilson

[Intel-gfx] [PATCH 04/16] drm/i915: Use GEN3_IRQ_RESET/INIT on gen3/4

From: Ville Syrjälä Replace the manual IMR+IER+IIR write sequences with the appropriate GEN3_IRQ_RESET/INIT macro invocations in gen3/4. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 24 ++--

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dp: rename intel_dp_is_edp to intel_dp_is_port_edp

On Fri, Aug 18, 2017 at 12:30:19PM +0300, Jani Nikula wrote: > Emphasize that this is based on the port, not intel_dp. This is also in > line with the underlying intel_bios_is_port_edp() function. No > functional changes. > > Cc: Manasi Navare > Cc: Jim Bride

Re: [Intel-gfx] [PATCH 04/16] drm/i915: Use GEN3_IRQ_RESET/INIT on gen3/4

Quoting ville.syrj...@linux.intel.com (2017-08-18 19:36:53) > From: Ville Syrjälä > > Replace the manual IMR+IER+IIR write sequences with the appropriate > GEN3_IRQ_RESET/INIT macro invocations in gen3/4. > > Signed-off-by: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Re-enable per-engine reset for Broxton

== Series Details == Series: drm/i915: Re-enable per-engine reset for Broxton URL : https://patchwork.freedesktop.org/series/29011/ State : success == Summary == Series 29011v1 drm/i915: Re-enable per-engine reset for Broxton

[Intel-gfx] [PATCH 12/16] drm/i915: Mask everything in ring HWSTAM on gen6+ in ringbuffer mode

From: Ville Syrjälä The execlist code already masks everything in the ring HWSTAM, but the ringbuffer code doesn't. Let's go ahead and do that. Pre-gen6 platforms setup HWSTAM during irq setup already since there's just the one register, and it also contains bits

[Intel-gfx] [PATCH 16/16] drm/i915: Reinstate GMBUS and AUX interrupts on gen4/g4x

From: Ville Syrjälä Now that we're not using MSI anymore on gen4 we can start using GMBUS and AUX interrupts again. These were disable on account of them causing the hardware to somehow generate legacy interrupts even when MSI was enabled. See commit c12aba5aa0e6

[Intel-gfx] [PATCH 15/16] drm/i915: Remove duplicated irq_preinstall/uninstall hooks

From: Ville Syrjälä All the irq_preinstall and irq_uninstall hooks are now identical. Let's just rename them all the irq_reset and remove the pointless duplicates. Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 14/16] drm/i915: Clean up the HWSTAM mess

From: Ville Syrjälä Currently we're unmasking some random looking bits in HWSTAM on gen3/4/5. The two bits we apparently unmask are 0 and 12, and also bits 16-31 on gen4/5. What those bits do depends on the gen as follows: bit 0: Breakpoint (gen2), ASLE (gen3),

[Intel-gfx] [maintainer-tools PATCH] dim: Add drm-misc-commit-flow.svg to clean target

Clean up drm-misc-commit-flow.svg when running make clean. Signed-off-by: Sean Paul --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 44fcdc9..8daa912 100644 --- a/Makefile +++ b/Makefile @@ -47,6 +47,6 @@ mancheck:

[Intel-gfx] [PATCH 13/16] drm/i915: Gen3 HWSTAM is actually 32 bits

From: Ville Syrjälä Bspec claims that HWSTAM is only 16 bits on gen3, but the other interrupts registers are 32 bits and there are 18 valid interrupt bits. Hence a 16 bit HWSTAM wouldn't be able to contain all the bits, so it seems the spec is incorrect about the

[Intel-gfx] [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation

This updates the documentation on the intel CCS modifiers for a couple of reasons: 1) The old documentation required that the CCS modifier only be used with formats. While i915 currently only supports CCS scanout with formats (and advertises such through the blob format), CCS

Re: [Intel-gfx] [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote: > 2017-08-14 Maarten Lankhorst : > > > complete_crtc_signaling is freeing fence_state, but when retrying > > num_fences and fence_state are not zero'd. This caused duplicate > > fd's in the

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dp: rename intel_dp_is_edp to intel_dp_is_port_edp

On Fri, Aug 18, 2017 at 12:30:19PM +0300, Jani Nikula wrote: > Emphasize that this is based on the port, not intel_dp. This is also in > line with the underlying intel_bios_is_port_edp() function. No > functional changes. Reviewed-by: Jim Bride > Cc: Manasi Navare

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Make infoframe code available to (e)DP ports (rev3)

== Series Details == Series: drm/i915: Make infoframe code available to (e)DP ports (rev3) URL : https://patchwork.freedesktop.org/series/8183/ State : failure == Summary == Series 8183v3 drm/i915: Make infoframe code available to (e)DP ports

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/doc: Document ioctl errno value patterns (rev2)

== Series Details == Series: drm/doc: Document ioctl errno value patterns (rev2) URL : https://patchwork.freedesktop.org/series/28974/ State : success == Summary == Series 28974v2 drm/doc: Document ioctl errno value patterns

Re: [Intel-gfx] [PATCH i-g-t v2] pm_rps: Changes in waitboost scenario

Quoting Daniel Vetter (2017-08-18 21:28:08) > On Fri, Aug 18, 2017 at 02:45:32PM +0100, Chris Wilson wrote: > > Quoting Katarzyna Dec (2017-08-18 12:08:44) > > > While I'm here let's also make sure that we're running as DRM > > > master to catch the common case, where the test is being ran > > >

Re: [Intel-gfx] [PATCH v2] drm/i915: Set our shrinker->batch to 4096 (~16MiB)

Quoting Chris Wilson (2017-08-18 13:56:08) > Quoting Chris Wilson (2017-08-16 15:23:06) > > Prefer to defer activating our GEM shrinker until we have a few > > megabytes to free; or we have accumulated sufficient mempressure by > > deferring the reclaim to force a shrink. The intent is that

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Properly handle series on apply_branch

On Fri, Aug 18, 2017 at 12:07 AM, Jani Nikula wrote: > On Thu, 17 Aug 2017, Rodrigo Vivi wrote: >> So far we could use *dim* to apply a whole series >> in a mbox, but only the very last patch was receiving >> all the checks and patchwork link. >> >>

[Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.

On my own workflow I was missing a way to download mboxes directly from patchwork with the patchwork id. So my first reflex was to modify dim to fulfil my needs. However that was increasing dim in complexity and dependencies and leaving that messy. That was when Jani suggested me the dimrc

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

On Fri, Aug 18, 2017 at 2:07 AM, Jani Nikula wrote: > On Thu, 17 Aug 2017, Stéphane Marchesin wrote: >> On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula >> wrote: >>> >>> On Thu, 15 Jun 2017, Imre Deak

Re: [Intel-gfx] [PATCH v2] drm/i915: Clear lost context-switch interrupts across reset

Quoting Michel Thierry (2017-08-18 17:31:38) > On 18/08/17 02:05, Chris Wilson wrote: > > During a global reset, we disable the irq. As we disable the irq, the > > hardware may be raising a GT interrupt that we then ignore, leaving it > > pending in the GTIIR. After the reset, we then re-enable

Re: [Intel-gfx] [PATCH 4/4] drm/i915/cnl: Apply large line width optimization

patches merged to dinq thanks for the reviews On Fri, Aug 18, 2017 at 6:39 AM, Oscar Mateo wrote: > > > On 08/15/2017 04:16 PM, Rodrigo Vivi wrote: >> >> From: Ben Widawsky >> >> This bit enables hardware that will change the approximation

[Intel-gfx] [maintainer-tools PATCH] qf: Include qf man into sphinx docs.

No modification to the original content. Cc: Jani Nikula Cc: Daniel Vetter Signed-off-by: Rodrigo Vivi --- index.rst | 1 + qf| 282 +- qf.rst| 250

[Intel-gfx] [PATCH i-g-t] pm_rps: Changes in waitboost scenario

Waitboost and reset test cases were failing because maximum frequency is not always boost frequency (sometimes overcloking occurs). Moreover more time is needed for boost to be finished. Changed boost_freq function so boost occurred on the same engine as low load. Added function waiting for boost

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix integer overflow tests

Quoting Dan Carpenter (2017-08-18 08:07:00) > There are some potential integer overflows here on 64 bit systems. > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the > check for now and look a couple lines

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Add fast-feedback-simulation.testlist

On Thu, Aug 17, 2017 at 07:53:45AM -0700, Kelvin Gardiner wrote: > On 17/08/17 00:50, Daniel Vetter wrote: > > On Wed, Aug 16, 2017 at 05:30:08PM -0700, Kelvin Gardiner wrote: > > > > > > > > > On 16/08/17 07:04, Daniel Vetter wrote: > > > > On Wed, Aug 16, 2017 at 11:33 AM, Petri Latvala > > >

Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: use NULL for GPIO connection ID

On Thu, 17 Aug 2017, Mika Kahola wrote: > Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01) > > Tested-by: Mika Kahola Do we have a bxt system available for testing this? With that, Acked-by: Jani Nikula BR, Jani.

Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset

Michel Thierry writes: > On 17/08/17 10:32, Chris Wilson wrote: >> Forcewake is not affected by the engine reset on gen6+. Indeed the >> reason why we added intel_uncore_forcewake_reset() to >> gen6_reset_engines() was to keep the bookkeeping intact because the >> reset

Re: [Intel-gfx] [PATCH] drm/i915: Return -EPERM when i915_gem_mmap_ioctl handling prime objects

On Wed, Aug 16, 2017 at 03:26:43AM +, Zhang, Tina wrote: > > > > -Original Message- > > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > > Behalf Of Chris Wilson > > Sent: Tuesday, August 15, 2017 11:02 PM > > To: Daniel Vetter > > Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Return -EPERM when i915_gem_mmap_ioctl handling prime objects

On Fri, 2017-08-18 at 10:03 +0200, Daniel Vetter wrote: > On Wed, Aug 16, 2017 at 03:26:43AM +, Zhang, Tina wrote: > > > Quoting Daniel Vetter (2017-08-15 15:48:03) > > > > On Tue, Aug 15, 2017 at 4:35 PM, Chris Wilson > > > > - If we need that special errno,

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

On Thu, 17 Aug 2017, Stéphane Marchesin wrote: > On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula > wrote: >> >> On Thu, 15 Jun 2017, Imre Deak wrote: >> > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote: >> >> I

[Intel-gfx] [PATCH v2] drm/i915: Clear lost context-switch interrupts across reset

During a global reset, we disable the irq. As we disable the irq, the hardware may be raising a GT interrupt that we then ignore, leaving it pending in the GTIIR. After the reset, we then re-enable the irq, triggering the pending interrupt. However, that interrupt was for the stale state from

Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset

Quoting Mika Kuoppala (2017-08-18 09:56:23) > Michel Thierry writes: > > > On 17/08/17 10:32, Chris Wilson wrote: > >> Forcewake is not affected by the engine reset on gen6+. Indeed the > >> reason why we added intel_uncore_forcewake_reset() to > >> gen6_reset_engines()

[Intel-gfx] ✓ Fi.CI.BAT: success for pm_rps: Changes in waitboost scenario

== Series Details == Series: pm_rps: Changes in waitboost scenario URL : https://patchwork.freedesktop.org/series/28966/ State : success == Summary == IGT patchset tested on top of latest successful build 5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decoding of child

Re: [Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

On Fri, 2017-08-18 at 08:54 +0100, Chris Wilson wrote: > Quoting Chris Wilson (2017-08-17 13:37:06) > > If we miss the current vblank because the gpu was busy, that may cause a > > jitter as the frame rate temporarily drops. We try to limit the impact > > of this by then boosting the GPU clock to

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Properly handle series on apply_branch

On Thu, 17 Aug 2017, Rodrigo Vivi wrote: > So far we could use *dim* to apply a whole series > in a mbox, but only the very last patch was receiving > all the checks and patchwork link. > > So this patch remove this limitation by using git mailsplit > to split the mbox and

Re: [Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

Quoting Chris Wilson (2017-08-17 13:37:06) > If we miss the current vblank because the gpu was busy, that may cause a > jitter as the frame rate temporarily drops. We try to limit the impact > of this by then boosting the GPU clock to deliver the frame as quickly > as possible. Originally done in

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix integer overflow tests

On Fri, Aug 18, 2017 at 08:46:25AM +0100, Chris Wilson wrote: > Quoting Dan Carpenter (2017-08-18 08:07:00) > > There are some potential integer overflows here on 64 bit systems. > > > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > > true on 32 bit systems, it's a no-op

Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset

On Thu, Aug 17, 2017 at 06:32:29PM +0100, Chris Wilson wrote: > Forcewake is not affected by the engine reset on gen6+. Indeed the > reason why we added intel_uncore_forcewake_reset() to > gen6_reset_engines() was to keep the bookkeeping intact because the > reset did not touch the forcewake bit

[Intel-gfx] [PATCH] dim: Include TODO in sphinx docs

More visibility Signed-off-by: Daniel Vetter --- TODO => TODO.rst | 11 +-- index.rst| 1 + 2 files changed, 10 insertions(+), 2 deletions(-) rename TODO => TODO.rst (97%) diff --git a/TODO b/TODO.rst similarity index 97% rename from TODO rename to

Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset

Quoting Daniel Vetter (2017-08-18 09:12:12) > On Thu, Aug 17, 2017 at 06:32:29PM +0100, Chris Wilson wrote: > > Forcewake is not affected by the engine reset on gen6+. Indeed the > > reason why we added intel_uncore_forcewake_reset() to > > gen6_reset_engines() was to keep the bookkeeping intact

[Intel-gfx] [PATCH v2] drm/i915: Fix integer overflow tests

There are some potential integer overflows here on 64 bit systems. The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the check for now and look a couple lines after: if (!access_ok(VERIFY_READ, user,

Re: [Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.

On Thu, 17 Aug 2017, Rodrigo Vivi wrote: > On Thu, Aug 17, 2017 at 10:33 AM, Jani Nikula wrote: >> On Thu, 17 Aug 2017, Rodrigo Vivi wrote: >>> On my own workflow I was missing a way to download mboxes >>> directly from

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix integer overflow tests (rev4)

== Series Details == Series: drm/i915: Fix integer overflow tests (rev4) URL : https://patchwork.freedesktop.org/series/28898/ State : success == Summary == Series 28898v4 drm/i915: Fix integer overflow tests https://patchwork.freedesktop.org/api/1.0/series/28898/revisions/4/mbox/

Re: [Intel-gfx] [PATCH v4 i-g-t] tests/kms: increase max threshold time for edid read

On Tue, Aug 15, 2017 at 11:04:21AM -0700, Clint Taylor wrote: > > > On 08/15/2017 12:58 AM, Daniel Vetter wrote: > > On Mon, Aug 14, 2017 at 10:21:51AM -0700, Clint Taylor wrote: > > > > > > On 08/14/2017 07:40 AM, Daniel Vetter wrote: > > > > On Thu, Aug 10, 2017 at 10:50:19AM -0700,

Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset

Quoting Michel Thierry (2017-08-17 18:41:16) > On 17/08/17 10:32, Chris Wilson wrote: > > Forcewake is not affected by the engine reset on gen6+. Indeed the > > reason why we added intel_uncore_forcewake_reset() to > > gen6_reset_engines() was to keep the bookkeeping intact because the > > reset

Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP

On Thu, Aug 17, 2017 at 12:46:53PM -0700, Manasi Navare wrote: > On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: > >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare > ><[1]manasi.d.nav...@intel.com> wrote: > > > > In case of eDP because the panel has a fixed mode we

Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset

Quoting Daniel Vetter (2017-08-18 09:12:12) > On Thu, Aug 17, 2017 at 06:32:29PM +0100, Chris Wilson wrote: > > Forcewake is not affected by the engine reset on gen6+. Indeed the > > reason why we added intel_uncore_forcewake_reset() to > > gen6_reset_engines() was to keep the bookkeeping intact

Re: [Intel-gfx] [PATCH v2] drm/i915: Mark the GT as busy before idling the previous request

On Thu, 2017-08-17 at 15:47 +0100, Chris Wilson wrote: > In a synchronous setup, we may retire the last request before we > complete allocating the next request. As the last request is retired, we > queue a timer to mark the device as idle, and promptly have to execute > ad cancel that timer once

[Intel-gfx] [PATCH] drm/doc: Document ioctl errno value patterns

We're not super-consistent about these, but I think it's worth to document at least the commmon patterns. Cc: Joonas Lahtinen Cc: Chris Wilson Cc: "Zhang, Tina" Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH] dim: Include TODO in sphinx docs

On Fri, 18 Aug 2017, Daniel Vetter wrote: > More visibility > > Signed-off-by: Daniel Vetter Ack. I guess qf man page should be extracted from the script, and put here too. BR, Jani. > --- > TODO => TODO.rst | 11 +-- > index.rst

Re: [Intel-gfx] [PATCH igt] lib: Avoid actually throttling from igt_require_gem()

Quoting Chris Wilson (2017-08-18 11:46:19) > igt_require_gem() checks whether we can use the i915 fd for submitting > requests by detecting a wedged driver. It was intended to be used just > after opening DRIVER_INTEL for a gem test to provide an early skip if > the device was unusable. However,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clear lost context-switch interrupts across reset (rev2)

== Series Details == Series: drm/i915: Clear lost context-switch interrupts across reset (rev2) URL : https://patchwork.freedesktop.org/series/28450/ State : success == Summary == Series 28450v2 drm/i915: Clear lost context-switch interrupts across reset

Re: [Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

Quoting Chris Wilson (2017-08-17 13:37:06) > If we miss the current vblank because the gpu was busy, that may cause a > jitter as the frame rate temporarily drops. We try to limit the impact > of this by then boosting the GPU clock to deliver the frame as quickly > as possible. Originally done in

Re: [Intel-gfx] [PATCH i-g-t 2/3] lib: Add ALSA library with dedicated helpers

On Thu, Aug 17, 2017 at 07:05:56PM +0300, Paul Kocialkowski wrote: > This introduces an ALSA library, with dedicated helpers for handling > playback and capture. It handles ALSA device identification and > configuration as well as a run loop with callback mechanisms for feeding > output data and

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib: Add audio library with dedicated helpers

Note: Alsa libraries are not installed in CI atm so this series wasn't quite tested. -- Petri Latvala On Thu, Aug 17, 2017 at 04:24:21PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] lib: Add audio library with dedicated > helpers > URL :

[Intel-gfx] [PATCH v14 7/7] drm/i915/gvt: Dmabuf support for GVT-g

This patch introduces a guest's framebuffer sharing mechanism based on dma-buf subsystem. With this sharing mechanism, guest's framebuffer can be shared between guest VM and host. v14: - add PROBE, DMABUF and REGION flags. (Alex) v12: - refine the lifecycle of dmabuf. v9: - remove dma-buf

[Intel-gfx] [PATCH v14 3/7] drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format

The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10 guest VM. This patch is to add this pixel format support to gvt device model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash and make guest screen black. Signed-off-by: Tina Zhang diff

[Intel-gfx] [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation

Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and get the plan and its related information. This ioctl can be invoked with: 1) either flag DMABUF or REGION is set. Vendor driver returns success and the plane_info only when the specific kind of buffer is supported. 2) flag

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs

Chris Wilson writes: > Quoting Mika Kuoppala (2017-08-18 12:07:20) >> Chris Wilson writes: >> > if (!eb->reloc_cache.vaddr && >> > (DBG_FORCE_RELOC == FORCE_GPU_RELOC || >> > -

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_params: Delete the circularly defined tests

On Tue, Aug 15, 2017 at 11:57:40PM +0100, Chris Wilson wrote: > For the set of execbuf flags who by definition are based on whether or > not the kernel supports that feature, the ultimate arbiter of whether or > not the kernel accepts the flag is the kernel. The negative tests were > second

[Intel-gfx] [PATCH v14 2/7] drm: Introduce RGB 64-bit 16:16:16:16 float format

The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in windows. The float format in each component is 1:5:10 MSb-sign:exponent: fraction. This patch is to introduce the format to drm, so that the windows guest's framebuffer in this kind of format can be recognized and used by

[Intel-gfx] [PATCH v14 0/7] drm/i915/gvt: Dma-buf support for GVT-g

v13->v14: 1) add PROBE, DMABUF and REGION flags. (Alex) 2) return -ENXIO when gem proxy object is banned by ioctl. (Chris) (Daniel) 3) add some details about the float pixel format. (Daniel) 4) add F suffix to the defined name. (Daniel) 5) refine pixel format table. (Zhenyu) v12->v13: 1) add

[Intel-gfx] [PATCH v14 1/7] drm/i915/gvt: Add framebuffer decoder support

This patch is to introduce the framebuffer decoder which can decode guest OS's framebuffer information, including primary, cursor and sprite plane. v14: - refine pixel format table. (Zhenyu) v9: - move drm format change to a separate patch. (Xiaoguang) v8: - fix a bug in decoding primary plane.

[Intel-gfx] [PATCH v14 4/7] drm/i915/gvt: Add opregion support

Windows guest driver needs vbt in opregion, to configure the setting for display. Without opregion support, the display registers won't be set and this blocks display model to get the correct information of the guest display plane. This patch is to provide a virtual opregion for guest. Current

[Intel-gfx] [PATCH v14 6/7] drm/i915: Introduce GEM proxy

GEM proxy is a kind of GEM, whose backing physical memory is pinned and produced by guest VM and is used by host as read only. With GEM proxy, host is able to access guest physical memory through GEM object interface. As GEM proxy is such a special kind of GEM, a new flag I915_GEM_OBJECT_IS_PROXY

Re: [Intel-gfx] [PATCH igt 01/24] lib/debugfs: Make is_mountpoint() non-fatal

On Mon, Aug 14, 2017 at 09:18:25PM +0100, Chris Wilson wrote: > is_mountpoint() asserts rather than report the error. Normally this > isn't a problem, except for atypical selftests. > > Signed-off-by: Chris Wilson Reviewed-by: Arkadiusz Hiler

Re: [Intel-gfx] [PATCH igt] lib: Avoid actually throttling from igt_require_gem()

Quoting Chris Wilson (2017-08-18 11:46:19) > igt_require_gem() checks whether we can use the i915 fd for submitting > requests by detecting a wedged driver. It was intended to be used just > after opening DRIVER_INTEL for a gem test to provide an early skip if > the device was unusable. However,

  1   2   >