Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't forward flip interrupts to GuC

On Wed, Sep 30, 2015 at 10:16:14AM -0700, O'Rourke, Tom wrote: > On Wed, Sep 30, 2015 at 09:57:37AM -0700, yu@intel.com wrote: > > From: Sagar Arun Kamble > > > > Due to flip interrupts GuC stays awake always and GT does not enter > > RC6. Do not route those

Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

On Wed, Sep 30, 2015 at 05:32:41PM +, R, Durgadoss wrote: > >-Original Message- > >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > >Vetter > >Sent: Tuesday, September 29, 2015 2:35 PM > >To: R, Durgadoss > >Cc: Daniel Vetter; Jani Nikula;

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Update Promotion timer for RC6 TO Mode

On Wed, Sep 30, 2015 at 04:13:43PM +0530, Sagar Arun Kamble wrote: > When using RC6 timeout mode, the timeout value > should be written to GEN6_RC6_THRESHOLD. > > v2: Updated commit message. (Tom) > > Signed-off-by: Sagar Arun Kamble > --- >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: remove pre-atomic check from SKL update_primary_plane

On Wed, Sep 30, 2015 at 05:05:43PM -0300, Paulo Zanoni wrote: > The comment suggests the check was there for some non-fully-atomic > case, and I couldn't find a case where we wouldn't correctly > initialize plane_state, so remove the check. > > Let's leave a WARN there just in case. > >

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Eliminate vmap overhead for cmd parser

On Thu, Oct 01, 2015 at 12:57:10PM +0100, Chris Wilson wrote: > With a little complexity to handle cmds straddling page boundaries, we > can completely avoiding having to vmap the batch and the shadow batch > objects whilst running the command parser. > > On ivb i7-3720MQ: > > x11perf -dot

Re: [Intel-gfx] [PATCH 09/15] drm/i915: Add NV12 support to intel_framebuffer_init

On Thu, Oct 01, 2015 at 02:37:27PM +0300, Ville Syrjälä wrote: > On Wed, Sep 30, 2015 at 10:58:07PM +, Konduru, Chandra wrote: > > > > @@ -14241,6 +14241,7 @@ static int intel_framebuffer_init(struct > > > drm_device *dev, > > > > { > > > > unsigned int aligned_height; > > > >

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Update Promotion timer for RC6 TO Mode

On Thu, Oct 01, 2015 at 03:27:44PM +0530, Sagar Arun Kamble wrote: > When using RC6 timeout mode, the timeout value > should be written to GEN6_RC6_THRESHOLD. > > v2: Updated commit message. (Tom) > > Signed-off-by: Sagar Arun Kamble When resending a patch which

Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

On Thu, Oct 01, 2015 at 03:14:13PM +0300, Ville Syrjälä wrote: > On Wed, Sep 30, 2015 at 05:05:44PM -0300, Paulo Zanoni wrote: > > We were considering the whole framebuffer height, but the spec says we > > should only consider the active display height size. There were still > > some unclear

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Eliminate vmap overhead for cmd parser

On Thu, Oct 01, 2015 at 03:37:21PM +0300, Ville Syrjälä wrote: > On Thu, Oct 01, 2015 at 12:57:10PM +0100, Chris Wilson wrote: > > - while (cmd < batch_end) { > > - const struct drm_i915_cmd_descriptor *desc; > > - u32 length; > > + k = i; > > +

Re: [Intel-gfx] [BXT MIPI PATCH v5 11/14] drm/i915/bxt: Modify BXT BLC according to VBT changes

On Wed, 30 Sep 2015, Uma Shankar wrote: > From: Sunil Kamath > > Latest VBT mentions which set of registers will be used for BLC, > as controller number field. Making use of this field in BXT > BLC implementation. Also, the registers are used in

Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix FBC buffer size checks

On Wed, Sep 30, 2015 at 05:05:45PM -0300, Paulo Zanoni wrote: > According to my experiments (and later confirmation from the hardware > developers), the maximum sizes mentioned in the specification delimit > how far in the buffer the hardware tracking can go. And the hardware > calculates the size

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, a few i915 fixes for v4.3. Do note the drm kms helper change from Egbert, I'm afraid it was not posted on dri-devel, just intel-gfx. However the change is trivial and needed as a dependency for the deadlock fix in i915. BR, Jani. The following changes since commit

[Intel-gfx] [PATCH 2/5] drm/i915: Add a tracepoint for the shrinker

Often it is very useful to know why we suddenly purge vast tracts of memory and surprisingly up until now we didn't even have a tracepoint for when we shrink our memory. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 ++

[Intel-gfx] [PATCH 5/5] drm/i915: Avoid GPU stalls from kswapd

Exclude active GPU pages from the purview of the background shrinker (kswapd), as these cause uncontrollable GPU stalls. Given that the shrinker is rerun until the freelists are satisfied, we should have opportunity in subsequent passes to recover the pages once idle. If the machine does run out

[Intel-gfx] [PATCH 2/3] drm/i915: Fix userptr deadlock with aliased GTT mmappings

Michał Winiarski found a really evil way to trigger a struct_mutex deadlock with userptr. He found that if he allocated a userptr bo and then GTT mmaped another bo, or even itself, at the same address as the userptr using MAP_FIXED, he could then cause a deadlock any time we then had to invalidate

[Intel-gfx] [PATCH 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range

Whilst discussing possible ways to trigger an invalidate_range on a userptr with an aliased GGTT mmapping (and so cause a struct_mutex deadlock), the conclusion is that we can, and we must, prevent any possible deadlock by avoiding taking the mutex at all during invalidate_range. This has numerous

[Intel-gfx] [PATCH 1/3] drm/i915: Only update the current userptr worker

The userptr worker allows for a slight race condition where upon there may two or more threads calling get_user_pages for the same object. When we have the array of pages, then we serialise the update of the object. However, the worker should only overwrite the obj->userptr.work pointer if and

[Intel-gfx] [PATCH 3/5] drm/i915: During shrink_all we only need to idle the GPU

We can forgo an evict-everything here as the shrinker operation itself will unbind any vma as required. If we explicitly idle the GPU through a switch to the default context, we not only create a request in an illegal context (e.g. whilst shrinking during execbuf with a request already allocated),

Re: [Intel-gfx] [PATCH 09/15] drm/i915: Add NV12 support to intel_framebuffer_init

On Wed, Sep 30, 2015 at 10:58:07PM +, Konduru, Chandra wrote: > > > @@ -14241,6 +14241,7 @@ static int intel_framebuffer_init(struct > > drm_device *dev, > > > { > > > unsigned int aligned_height; > > > int ret; > > > + int i; > > > u32 pitch_limit, stride_alignment; > > > > > >

[Intel-gfx] [PATCH v2 (not really v2)] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset

There are some allocations that must be only referenced by 32-bit offsets. To limit the chances of having the first 4GB already full, objects not requiring this workaround use DRM_MM_SEARCH_BELOW/ DRM_MM_CREATE_TOP flags In specific, any resource used with flat/heapless (0x-0xf000)

Re: [Intel-gfx] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!

On Thu, Oct 01, 2015 at 11:41:34AM +0200, Jiri Kosina wrote: > Hi, > > since I've updated on my thinkpad x200s to latest Linus' tree (3235031), I > am getting a lot of > > [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't > calculate constants, dotclock = 0! What's a

[Intel-gfx] [PATCH 1/5] drm/i915: shrinker_control->nr_to_scan is now unsigned long

As the shrinker_control now passes us unsigned long targets, update our shrinker functions to match. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++-- 2 files changed, 3 insertions(+), 3

[Intel-gfx] [PATCH 4/5] drm/i915: Remove dead i915_gem_evict_everything()

With UMS gone, we no longer use it during suspend. And with the last user removed from the shrinker, we can remove the dead code. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem_evict.c | 45

[Intel-gfx] [PATCH] drm/i915: Allow userptr backchannel for passing around GTT mappings

Once userptr becomes part of client API, it is almost a certainty that eventually someone will try to create a new object from a mapping of another client object, e.g. new = vaImport(vaMap(old, ), size); (using a hypothethical API, not meaning to pick on anyone!) Since this is actually fairly

Re: [Intel-gfx] [PATCH v2 (not really v2)] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset

On Thu, Oct 01, 2015 at 01:33:57PM +0100, Michel Thierry wrote: > There are some allocations that must be only referenced by 32-bit > offsets. To limit the chances of having the first 4GB already full, > objects not requiring this workaround use DRM_MM_SEARCH_BELOW/ > DRM_MM_CREATE_TOP flags > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen8: Flip the 48b switch

On Wed, Sep 30, 2015 at 03:36:19PM +0100, Michel Thierry wrote: > Use 48b addresses if hw supports it (i915.enable_ppgtt=3). > Update the sanitize_enable_ppgtt for 48 bit PPGTT mode. > > Note, aliasing PPGTT remains 32b only. > > v2: s/full_64b/full_48b/. (Akash) > v3: Add sanitize_enable_ppgtt

[Intel-gfx] [PATCH 5/6] drm/i915: Reduce pointer indirection during cmd parser lookup

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_cmd_parser.c | 51 -- drivers/gpu/drm/i915/i915_drv.h| 4 ++- 2 files changed, 14 insertions(+), 41 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c

[Intel-gfx] [PATCH 2/6] drm/i915: Cache last cmd descriptor when parsing

The cmd parser has the biggest impact on the BLT ring, because it is relatively verbose composed to the other engines as the vertex data is inline. It also typically has runs of repeating commands (again since the vertex data is inline, it typically has sequences of XY_SETUP_BLT,

[Intel-gfx] [PATCH 3/6] drm/i915: Use WC copies on !llc platforms for the command parser

Since we blow the TLB caches by using kmap/kunmap, we may as well go the whole hog and see if declaring our destination page as WC is faster than keeping it as WB and using clflush. It should be! Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_cmd_parser.c |

[Intel-gfx] [PATCH 4/6] drm/i915: Reduce arithmetic operations during cmd parser lookup

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_cmd_parser.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index f4d4c3132932..4fc995b2729d 100644 ---

[Intel-gfx] [PATCH 6/6] drm/i915: Improve hash function for the command parser

The existing code's hashfunction is very suboptimal (most 3D commands use the same bucket degrading the hash to a long list). The code even acknowledge that the issue was known and the fix simple: /* * If we attempt to generate a perfect hash, we should be able to look at bits * 31:29 of a

[Intel-gfx] [PATCH 1/6] drm/i915: Eliminate vmap overhead for cmd parser

With a little complexity to handle cmds straddling page boundaries, we can completely avoiding having to vmap the batch and the shadow batch objects whilst running the command parser. On ivb i7-3720MQ: x11perf -dot before 54.3M, after 53.2M (max 203M) glxgears before 7110 fps, after 7300 fps

Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

On Wed, Sep 30, 2015 at 05:05:44PM -0300, Paulo Zanoni wrote: > We were considering the whole framebuffer height, but the spec says we > should only consider the active display height size. There were still > some unclear questions based on the spec, but the hardware guys > clarified them for us.

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Eliminate vmap overhead for cmd parser

On Thu, Oct 01, 2015 at 02:24:53PM +0100, Chris Wilson wrote: > On Thu, Oct 01, 2015 at 03:37:21PM +0300, Ville Syrjälä wrote: > > On Thu, Oct 01, 2015 at 12:57:10PM +0100, Chris Wilson wrote: > > > - while (cmd < batch_end) { > > > - const struct drm_i915_cmd_descriptor *desc; > > > -

[Intel-gfx] [RFC 0/1] drm/i915: Add scheduling priority to per-context parameters

A proposal for an ioctl to allow a user process to alter its GPU scheduling priority. It's defined as a new per-context parameter, and each execbuffer submitted thereafter inherits its priority from the context. This allows a single process to associate different priorities with different

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Eliminate vmap overhead for cmd parser

On Thu, Oct 01, 2015 at 04:29:48PM +0300, Ville Syrjälä wrote: > On Thu, Oct 01, 2015 at 02:24:53PM +0100, Chris Wilson wrote: > > On Thu, Oct 01, 2015 at 03:37:21PM +0300, Ville Syrjälä wrote: > > > On Thu, Oct 01, 2015 at 12:57:10PM +0100, Chris Wilson wrote: > > > > - while (cmd <

Re: [Intel-gfx] [PATCH] drm/i915: Handle HPD when it has actually occurred

On Wed, 08 Jul 2015, Daniel Vetter wrote: > On Wed, Jul 08, 2015 at 05:07:47PM +0530, Sonika Jindal wrote: >> Writing to PCH_PORT_HOTPLUG for each interrupt is not required. >> Handle it only if hpd has actually occurred like we handle other >> interrupts. >> v2: Make few

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen8: Flip the 48b switch

On 10/1/2015 2:16 PM, Daniel Vetter wrote: On Wed, Sep 30, 2015 at 03:36:19PM +0100, Michel Thierry wrote: Use 48b addresses if hw supports it (i915.enable_ppgtt=3). Update the sanitize_enable_ppgtt for 48 bit PPGTT mode. Note, aliasing PPGTT remains 32b only. v2: s/full_64b/full_48b/.

[Intel-gfx] [RFC 1/1] drm/i915: Add scheduling priority to per-context parameters

The next use for the i915 get/set per-context parameters ioctl, ahead of the introduction of the forthcoming GPU scheduler. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_drv.h | 28 drivers/gpu/drm/i915/i915_gem_context.c

[Intel-gfx] [PATCH v3 1/1] drm/i915: Update Promotion timer for RC6 TO Mode

When using RC6 timeout mode, the timeout value should be written to GEN6_RC6_THRESHOLD. v2: Updated commit message. (Tom) v3: Rebase over whitespace differences. (Daniel) Cc: Tom O'Rourke Signed-off-by: Sagar Arun Kamble ---

[Intel-gfx] [PATCH i-g-t] benchmarks: Fix build errors on Android M-Dessert

Android M-Dessert treats implicit declaration of function warnings as errors resulting in igt failing to build. This patch fixes the errors by including missing header files as required. Mostly this involved including igt.h in the benchmarks. Signed-off-by: Derek Morton

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Sanitize watermarks after hardware state readout

On Fri, 25 Sep 2015, Matt Roper wrote: > Although we can do a good job of reading out hardware state, the > graphics firmware may have programmed the watermarks in a creative way > that doesn't match how i915 would have chosen to program them. We > shouldn't trust the

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Sanitize watermarks after hardware state readout

On Thu, Oct 01, 2015 at 04:58:38PM +0300, Jani Nikula wrote: > On Fri, 25 Sep 2015, Matt Roper wrote: > > Although we can do a good job of reading out hardware state, the > > graphics firmware may have programmed the watermarks in a creative way > > that doesn't match

Re: [Intel-gfx] [PATCH] drm/i915: prevent out of range pt in the PDE macros (take 3)

On Thu, Oct 01, 2015 at 04:59:35PM +0100, Michel Thierry wrote: > We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of > range pt in gen6_for_each_pde"). > > But the static analyzer still complains that, just before we break due > to "iter < I915_PDES", we do "pt =

Re: [Intel-gfx] [BXT MIPI PATCH v5 05/14] drm/i915/bxt: DSI encoder support in CRTC modeset

>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Thursday, October 1, 2015 3:24 PM >To: Shankar, Uma; intel-gfx@lists.freedesktop.org >Cc: Kumar, Shobhit; Deak, Imre; Sharma, Shashank; Shankar, Uma >Subject: Re: [BXT MIPI PATCH v5 05/14] drm/i915/bxt:

Re: [Intel-gfx] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!

On Thu, 1 Oct 2015, Ville Syrjälä wrote: > > since I've updated on my thinkpad x200s to latest Linus' tree (3235031), I > > am getting a lot of > > > > [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't > > calculate constants, dotclock = 0! > > What's a lot? I think you

[Intel-gfx] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!

Hi, since I've updated on my thinkpad x200s to latest Linus' tree (3235031), I am getting a lot of [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! googling revealed this patch:

[Intel-gfx] [PATCH igt v6 0/8] Blob property and atomic modesetting tests

Hi all, Another respin of the blob/atomic tests. Pretty minor changes compared to the last round this time; this introduces the new drm_ioctl_err macro, and moves some of the asserts into macros rather than helper functions, so we can pin the failures at the exact callsite, rather than just in a

[Intel-gfx] [PATCH] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state

When watermark calculation was moved up to the atomic check phase, the code was updated to calculate based on in-flight atomic state rather than already-committed state. However the hsw_compute_linetime_wm() didn't get updated and continued to pull values out of the currently-committed CRTC

[Intel-gfx] [PATCH igt 1/8] lib/igt_core: Add igt_assert_neq_*() variants

Similar to igt_assert_eq_*(), add variants for non-equality of types other than int. Signed-off-by: Daniel Stone --- lib/igt_core.h | 27 +++ 1 file changed, 27 insertions(+) diff --git a/lib/igt_core.h b/lib/igt_core.h index f8bfbf0..9a5d9c5

[Intel-gfx] [PATCH igt 4/8] lib/drmtest: Add do_ioctl_err to expect failure

do_ioctl demands that the ioctl returns success; add a variant named do_ioctl_err, which expects the ioctl to fail, and demands a particular result. Signed-off-by: Daniel Stone --- lib/drmtest.h | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-)

[Intel-gfx] [PATCH igt 2/8] lib/igt_core: Add igt_assert_fd

Skip open-coding and assert that fds are valid. Signed-off-by: Daniel Stone --- lib/igt_core.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/lib/igt_core.h b/lib/igt_core.h index 9a5d9c5..8f93e8e 100644 --- a/lib/igt_core.h +++ b/lib/igt_core.h @@

Re: [Intel-gfx] [RFC 1/1] drm/i915: Add scheduling priority to per-context parameters

Hi Dave, [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] config: x86_64-allyesconfig (attached as .config) reproduce: git checkout 5be87551bfc8fabcb9cad4762a45c0f12d0c6cdf # save the attached .config to linux build tree make ARCH=x86_64

Re: [Intel-gfx] [PATCH] drm/i915: Resurrect golden context on gen6/7

Daniel Vetter writes: > In > > commit 8f0e2b9d95a88ca5d8349deef2375644faf184ae > Author: Daniel Vetter > Date: Tue Dec 2 16:19:07 2014 +0100 > > drm/i915: Move golden context init into ->init_context > > I've shuffled around per-ctx init

[Intel-gfx] [RFC 1/1 v2] drm/i915: Add scheduling priority to per-context parameters

Hmmm ... the email seems to have been damaged during composition :( I probably shouldn't try to use vi(1) [where '~' means toggle-letter-case] over an ssh link [where '~' is an escape, of sorts] from another Linux machine inside a PuTTY terminal under Windows [where various keys send escape

[Intel-gfx] [PATCH] drm/i915: Resurrect golden context on gen6/7

In commit 8f0e2b9d95a88ca5d8349deef2375644faf184ae Author: Daniel Vetter Date: Tue Dec 2 16:19:07 2014 +0100 drm/i915: Move golden context init into ->init_context I've shuffled around per-ctx init code a bit for legacy contexts but accidentally dropped the render

[Intel-gfx] [PATCH] drm/i915: prevent out of range pt in the PDE macros (take 3)

We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of range pt in gen6_for_each_pde"). But the static analyzer still complains that, just before we break due to "iter < I915_PDES", we do "pt = (pd)->page_table[iter]" with an iter value that is bigger than I915_PDES. Of course,

[Intel-gfx] [PATCH igt 7/8] tests: Add blob-property test

Exercises the new blob-creation ioctl, testing lifetimes and behaviour of user-created blobs, as well as exercising all the invariant conditions we guarantee from modes exposed as blob properties. v2: Renamed to core_prop_blob, skip test if blob not available. v3: No changes. v4: Consistently

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

On 09/22/2015 05:21 PM, Tvrtko Ursulin wrote: > > On 09/22/2015 03:53 PM, David Herrmann wrote: >> Hi >> >> On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin >> wrote: >>> On 09/10/2015 10:56 AM, Daniel Vetter wrote: That's not different from the compositor

[Intel-gfx] [BXT MIPI PATCH v5 05/14] drm/i915/bxt: DSI encoder support in CRTC modeset

From: Shashank Sharma SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset functions are re-used for modeset sequence. But DDI interface doesn't include support for DSI. This patch adds: 1. cases for DSI encoder, in those modeset functions and allows

[Intel-gfx] [PATCH igt 3/8] lib/igt.cocci: Add greater-than to igt_assert_lt*

Change m >= n patterns to igt_assert_lte(n, m), and ditto for strict greater-than. Signed-off-by: Daniel Stone --- lib/igt.cocci | 12 1 file changed, 12 insertions(+) diff --git a/lib/igt.cocci b/lib/igt.cocci index 3aee72f..b4f8ee4 100644 ---

[Intel-gfx] [PATCH igt 5/8] lib/igt.cocci: De-opencode ioctls

Use do_ioctl and do_ioctl_err where possible. Signed-off-by: Daniel Stone --- lib/igt.cocci | 18 ++ 1 file changed, 18 insertions(+) diff --git a/lib/igt.cocci b/lib/igt.cocci index b4f8ee4..10abd21 100644 --- a/lib/igt.cocci +++ b/lib/igt.cocci @@

Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix FBC buffer size checks

Em Qui, 2015-10-01 às 15:22 +0300, Ville Syrjälä escreveu: > On Wed, Sep 30, 2015 at 05:05:45PM -0300, Paulo Zanoni wrote: > > According to my experiments (and later confirmation from the > > hardware > > developers), the maximum sizes mentioned in the specification > > delimit > > how far in the

Re: [Intel-gfx] [PATCH 09/15] drm/i915: Add NV12 support to intel_framebuffer_init

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Thursday, October 01, 2015 4:41 AM > To: Konduru, Chandra > Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel; Syrjala, Ville > Subject: Re: [Intel-gfx] [PATCH 09/15] drm/i915: Add NV12 support to

Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

On Thu, Oct 01, 2015 at 05:47:11PM +, Zanoni, Paulo R wrote: > Em Qui, 2015-10-01 às 15:23 +0300, Ville Syrjälä escreveu: > > On Thu, Oct 01, 2015 at 03:14:13PM +0300, Ville Syrjälä wrote: > > > On Wed, Sep 30, 2015 at 05:05:44PM -0300, Paulo Zanoni wrote: > > > > We were considering the whole

Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

Em Qui, 2015-10-01 às 15:23 +0300, Ville Syrjälä escreveu: > On Thu, Oct 01, 2015 at 03:14:13PM +0300, Ville Syrjälä wrote: > > On Wed, Sep 30, 2015 at 05:05:44PM -0300, Paulo Zanoni wrote: > > > We were considering the whole framebuffer height, but the spec > > > says we > > > should only

Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

Em Qui, 2015-10-01 às 21:11 +0300, Ville Syrjälä escreveu: > On Thu, Oct 01, 2015 at 05:47:11PM +, Zanoni, Paulo R wrote: > > Em Qui, 2015-10-01 às 15:23 +0300, Ville Syrjälä escreveu: > > > On Thu, Oct 01, 2015 at 03:14:13PM +0300, Ville Syrjälä wrote: > > > > On Wed, Sep 30, 2015 at

[Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

We were considering the whole framebuffer height, but the spec says we should only consider the active display height size. There were still some unclear questions based on the spec, but the hardware guys clarified them for us. According to them: - CFB size = CFB stride * Number of lines FBC

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Try to print INSTDONE bits for all slice/subslice

On Wed, Sep 30, 2015 at 11:00:46PM +0300, Imre Deak wrote: > From: Ben Widawsky > > Signed-off-by: Ben Widawsky > > --- > Changes (Imre): > - use the new INSTDONE capturing by default on new GENs (On Ben's request) > - keep printing the render

[Intel-gfx] [PATCH] drm/i915: Allow minimum brightness upon backlight enable

From: Clint Taylor backlight minimum is a valid value so you don't need to set maximum. Signed-off-by: Clint Taylor --- drivers/gpu/drm/i915/intel_panel.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 3/3] drm/i915: fix FBC buffer size checks

According to my experiments (and later confirmation from the hardware developers), the maximum sizes mentioned in the specification delimit how far in the buffer the hardware tracking can go. And the hardware calculates the size based on the plane address we provide - and the provided plane

Re: [Intel-gfx] [PATCH 3/5] drm/i915: rename INSTDONE1 to GEN4_INSTDONE1

On Wed, Sep 30, 2015 at 11:00:44PM +0300, Imre Deak wrote: > This register was added on GEN4, by the name INSTDONE_1 whereas the GEN6 > specification calls it INSTDONE_2. Keep the original name with a > platform prefix to make it clearer which INSTDONE register instance this > is. Also add a

[Intel-gfx] [PATCH] fixup! drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)

Cc: Paulo Zanoni Signed-off-by: Matt Roper --- Paulo, I'm not positive that this is the cause of the issues you're seeing, but I did find this unwanted behavior change while re-reading all the SKL watermark code. Could you give this a try and

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Try to print INSTDONE bits for all slice/subslice

On Wed, Sep 30, 2015 at 11:00:46PM +0300, Imre Deak wrote: > From: Ben Widawsky > > Signed-off-by: Ben Widawsky > > --- > Changes (Imre): > - use the new INSTDONE capturing by default on new GENs (On Ben's request) > - keep printing the render

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

On Thu, Oct 01, 2015 at 12:47:17PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > ERROR: "drm_agp_release" [drivers/gpu/drm/radeon/radeon.ko] undefined! > ERROR: "drm_agp_acquire"

Re: [Intel-gfx] [BXT MIPI PATCH v5 05/14] drm/i915/bxt: DSI encoder support in CRTC modeset

On Wed, 30 Sep 2015, Uma Shankar wrote: > From: Shashank Sharma > > SKL and BXT qualifies the HAS_DDI() check, and hence haswell > modeset functions are re-used for modeset sequence. But DDI > interface doesn't include support for DSI. > This

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't forward flip interrupts to GuC

On 10/1/2015 2:22 PM, Jani Nikula wrote: On Thu, 01 Oct 2015, Daniel Vetter wrote: On Wed, Sep 30, 2015 at 10:16:14AM -0700, O'Rourke, Tom wrote: On Wed, Sep 30, 2015 at 09:57:37AM -0700, yu@intel.com wrote: From: Sagar Arun Kamble Due to

Re: [Intel-gfx] [BXT MIPI PATCH v4 05/14] drm/i915/bxt: DSI encoder support in CRTC modeset

On Wed, 30 Sep 2015, "Shankar, Uma" wrote: >>-Original Message- >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >>Sent: Tuesday, September 29, 2015 12:59 PM >>To: Shankar, Uma; intel-gfx@lists.freedesktop.org >>Cc: Kumar, Shobhit; Deak, Imre; Sharma,

[Intel-gfx] [PATCH v2 1/1] drm/i915: Update Promotion timer for RC6 TO Mode

When using RC6 timeout mode, the timeout value should be written to GEN6_RC6_THRESHOLD. v2: Updated commit message. (Tom) Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_pm.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't forward flip interrupts to GuC

On Thu, 01 Oct 2015, Daniel Vetter wrote: > On Wed, Sep 30, 2015 at 10:16:14AM -0700, O'Rourke, Tom wrote: >> On Wed, Sep 30, 2015 at 09:57:37AM -0700, yu@intel.com wrote: >> > From: Sagar Arun Kamble >> > >> > Due to flip interrupts GuC stays

Re: [Intel-gfx] i915 kernel error

+ intel-gfx@lists.freedesktop.org On Thu, Oct 01, 2015 at 12:20:10AM -0700, Gary Barrueto wrote: > Got a intel nuc i7 and am getting this when I start playing video in > vlc and many times the system just freezes. > > Oct 1 00:08:59 inuc kernel: [ 81.127657] [ cut here >

Re: [Intel-gfx] [drm-intel:for-linux-next-fixes 3/4] DockBook: drivers/gpu/drm/drm_probe_helper.c:107: warning: Excess function parameter 'dev' description in 'DRM_OUTPUT_POLL_PERIOD'

On Wed, 30 Sep 2015, Egbert Eich wrote: > Jani Nikula writes: > > On Wed, 30 Sep 2015, Daniel Vetter wrote: > > > On Wed, Sep 30, 2015 at 05:09:04PM +0800, kbuild test robot wrote: > > >> tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes > >

Re: [Intel-gfx] [PATCH 2/6] scripts/kernel-doc: Adding infrastructure for markdown support

On Mon, 07 Sep 2015, Danilo Cesar Lemes de Paula wrote: > %.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE > + @(which pandoc > /dev/null 2>&1) || \ > + (echo "*** To get propper documentation you need to install pandoc > ***";)

[Intel-gfx] [PATCH 3/3] drm/i915: add DOC for i915_component

From: Libin Yang Add the DOC for i915_component.h. Explain the struct i915_audio_component_ops and struct i915_audio_component_audio_ops usage. Signed-off-by: Libin Yang --- drivers/gpu/drm/i915/intel_audio.c | 5 + 1 file changed, 5

[Intel-gfx] [PATCH 2/3] drm/i915: DocBook add i915_component.h support

From: Libin Yang Add the item of i915_component.h in DocBook Signed-off-by: Libin Yang --- Documentation/DocBook/drm.tmpl | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't forward flip interrupts to GuC

On Thu, Oct 01, 2015 at 11:52:36AM +0300, Jani Nikula wrote: > On Thu, 01 Oct 2015, Daniel Vetter wrote: > > On Wed, Sep 30, 2015 at 10:16:14AM -0700, O'Rourke, Tom wrote: > >> On Wed, Sep 30, 2015 at 09:57:37AM -0700, yu@intel.com wrote: > >> > From: Sagar Arun Kamble