Re: [Intel-gfx] [PATCH v4 2/6] drm/i915: tidy up initialisation failure paths (GEM & LRC)

On Mon, Feb 01, 2016 at 09:45:25AM +, Dave Gordon wrote: > On 30/01/16 11:28, Chris Wilson wrote: > >On Sat, Jan 30, 2016 at 10:56:27AM +, Chris Wilson wrote: > >>On Fri, Jan 29, 2016 at 07:19:27PM +, Dave Gordon wrote: > >>>1. add call to i915_gem_context_fini() to deallocate the

Re: [Intel-gfx] [IGT PATCH 5/6] kms_force_connector_basic: Add force-load-detect test

On Mon, Feb 01, 2016 at 02:44:01PM +0100, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > diff --git a/tests/kms_force_connector_basic.c > b/tests/kms_force_connector_basic.c > index bd80caeffd82..f827d0008f7b 100644 > ---

Re: [Intel-gfx] [PATCH v4 0/6] Check pixel clock when setting mode

On Tue, Feb 02, 2016 at 03:16:37PM +0200, Mika Kahola wrote: > From EDID we can read and request higher pixel clock than > our HW can support. This set of patches add checks if > requested pixel clock is lower than the one supported by the HW. > The requested mode is discarded if we cannot support

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

Daniel, I've already tried Ville's patch you've mentioned with no luck. Kindly find unpatched v4.5-rc3 dmesg with drm debug enabled here: [1] [1] https://gist.github.com/efb44b7c6bc325978b80 11.02.2016 10:21, Daniel Vetter wrote: Please boot with drm.debug=0xe and attach the dmesg. Also

Re: [Intel-gfx] [v2 4/6] drm/i915/skl+: Use scaling amount for plane data rate calculation

On Wed, Feb 10, 2016 at 11:39:41AM -0800, Matt Roper wrote: > On Wed, Jan 27, 2016 at 09:40:01PM +0530, Shobhit Kumar wrote: > > From: "Kumar, Mahesh" > > > > if downscaling is enabled plane data rate increases according to scaling > > amount. take scaling amount under

[Intel-gfx] [PATCH] drm/i915/gen9: Check for DC state mismatch

The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_csr.c

Re: [Intel-gfx] [PATCH V3] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

On Wed, Feb 10, 2016 at 05:37:20PM -0800, Marc Herbert wrote: > On 10/02/16 06:27, Ville Syrjälä wrote: > > On Tue, Feb 09, 2016 at 04:28:27PM -0800, clinton.a.tay...@intel.com wrote: > >> From: Clint Taylor > >> > >> Track VCO frequency of SKL instead of the boot

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Use atomic state to obtain load detection crtc.

On Mon, Feb 01, 2016 at 02:43:57PM +0100, Maarten Lankhorst wrote: > Instead of restoring dpms and a flag for whether a temp fb is allocated > duplicate > the old plane_state and crtc_state, and restore the members we potentially > touched. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 2/3] tests/kms_hdmi_inject: Test to make use of HDMI injection capabilities.

On Tue, Feb 02, 2016 at 03:03:37PM +0200, Marius Vlad wrote: > Signed-off-by: Marius Vlad > --- > tests/Makefile.sources | 1 + > tests/kms_hdmi_inject.c | 165 > > 2 files changed, 166 insertions(+) > create mode

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

On Thu, Feb 11, 2016 at 10:54:08AM +0200, Oleksandr Natalenko wrote: > Daniel, > > I've already tried Ville's patch you've mentioned with no luck. > > Kindly find unpatched v4.5-rc3 dmesg with drm debug enabled here: [1] > > [1] https://gist.github.com/efb44b7c6bc325978b80 That's an IVB. So no

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

On Thu, Feb 11, 2016 at 09:45:17AM +0200, Oleksandr Natalenko wrote: > Daniel, > > I do confirm that this hacky patch: > > https://lkml.org/lkml/2016/1/19/637 > > works around my issue. I understand that this is improper fix, so let me > know how could I debug my issue further. Please boot

Re: [Intel-gfx] [PATCH v4 0/6] Check pixel clock when setting mode

On Tue, Feb 02, 2016 at 06:25:39PM +0200, Ville Syrjälä wrote: > On Tue, Feb 02, 2016 at 03:16:37PM +0200, Mika Kahola wrote: > > From EDID we can read and request higher pixel clock than > > our HW can support. This set of patches add checks if > > requested pixel clock is lower than the one

Re: [Intel-gfx] [PATCH] drm/i915: Support HDMI EDID injection

On Tue, Feb 02, 2016 at 01:05:07PM +0200, Marius Vlad wrote: > Use the drm_property_blob data for EDID when an blob EDID > has been supplied over the debugfs interface. > > Signed-off-by: Marius Vlad v2 of patches must have an in-patch changelog of what (and why) stuff

Re: [Intel-gfx] [PATCH] drm/i915: Support HDMI EDID injection

On Mon, Feb 01, 2016 at 06:35:33PM +0200, Marius Vlad wrote: > Allow HDMI EDID injection by making a copy of edid_blob_ptr. When > disconnecting > the connector, or forcing a disconnect, the copy will free'd by > intel_hdmi_unset_edid(). > > Signed-off-by: Marius Vlad

Re: [Intel-gfx] [PATCH 1/2] dmr/i915: Use appropriate spinlock flavour

On Mon, Feb 01, 2016 at 11:00:07AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We know this never runs from interrupt context so > don't need to use the flags variant. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Daniel Vetter

Re: [Intel-gfx] [PATCH] drm/i915: Fix hpd live status bits for g4x

On Thu, 11 Feb 2016, Daniel Vetter wrote: > On Wed, Feb 10, 2016 at 07:59:05PM +0200, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> Looks like g4x hpd live status bits actually agree with the spec. At >> least they do on the

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

Hi Dave - Intel fixes all around, mostly display. Sorry I'm late this week. BR, Jani. The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95: Linux 4.5-rc3 (2016-02-07 15:38:30 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

Ville, I've applied patch you've provided and did couple of replugging with intel_reg in between. Here are the results. I used additional VGA cable to see what actually I type in console :). Both HDMI and VGA cables plugged: [1] Both HDMI and VGA cables unplugged: [2] Only HDMI cable

Re: [Intel-gfx] [PATCH v3 08/12] drm/i915: Fix struct mutex vs. RPS lock inversion

On Tue, Feb 02, 2016 at 02:46:58PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > RPS lock must be taken before the struct_mutex to avoid > locking inversion. So stop grabbing it for the whole > powersave initialization and instead only take it during > the

Re: [Intel-gfx] [PATCH 07/12] drm/i915: GEM operations need to be done under the big lock

On Tue, Feb 02, 2016 at 11:06:25AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > VMA creation and GEM list management need the big lock. > > v2: > > Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) > > Not to mention

Re: [Intel-gfx] Video glitches E3845 ATOM, Fedora 21

On Wed, 10 Feb 2016, "Rogers, Martin" wrote: > Hi Jani, > > I have not submitted a bug yet, because no kernel msgs were produced the > moment I recreated the issue. > I used : drm.debug=0x14 > > Can you suggest something else ? We want the log anyway to

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Disable use of stolen area by User when Intel RST is present

On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma The BIOS RapidStartTechnology may corrupt the stolen memory across S3 suspend due to unalarmed hibernation, in which case we will not be able to preserve the User data stored in

Re: [Intel-gfx] [PATCH v3 0/1] Add a lib for power management helpers

On Thu, Feb 11, 2016 at 09:25:35AM +0200, David Weinehall wrote: > This patch aims to create a separate lib for power management related > helpers. Initially it only contains code that modify settings for > external components (to handle components with default settings that > prevents entering

Re: [Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)

On Wed, Feb 03, 2016 at 06:05:01AM -0800, Matt Roper wrote: > On Wed, Feb 03, 2016 at 01:16:38PM +0200, Ville Syrjälä wrote: > > On Tue, Feb 02, 2016 at 10:06:51PM -0800, Matt Roper wrote: > > > Due to our lack of two-step watermark programming, our driver has > > > historically pretended that the

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Use atomic state in intel_fb_initial_config.

On Mon, Feb 01, 2016 at 02:44:02PM +0100, Maarten Lankhorst wrote: > This is another step in removing legacy state. > > Signed-off-by: Maarten Lankhorst Patches 2,3,4,6 lgtm. Reviewed-by: Ville Syrjälä Though I'd still prefer

Re: [Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)

On Thu, Feb 11, 2016 at 09:50:45AM +0100, Daniel Vetter wrote: > On Wed, Feb 03, 2016 at 06:05:01AM -0800, Matt Roper wrote: > > On Wed, Feb 03, 2016 at 01:16:38PM +0200, Ville Syrjälä wrote: > > > On Tue, Feb 02, 2016 at 10:06:51PM -0800, Matt Roper wrote: > > > > Due to our lack of two-step

[Intel-gfx] [PATCH] drm/i915: Add missing 'else' to intel_digital_port_connected()

From: Ville Syrjälä intel_digital_port_connected() lacks one 'else'. There's no actual harm in not having it since each branch has an unconditional return, so it can't accidentally end up in taking two branches instead of just the one. But let's be consistent and

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: fix context/engine cleanup order

Chris Wilson writes: > On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote: >> On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote: >> > From: Nick Hoath >> > >> > Swap the order of context & engine cleanup, so that contexts

[Intel-gfx] [PATCH 1/3 V2] drm/i915: Using the bpp value wrt the pixel format

From: Deepak M The bpp value which is used while calulating the txbyteclkhs values should be wrt the pixel format value. Currently bpp is coming from pipe config to calculate txbyteclkhs. Fix it in this patch. V2: dsi_pixel_format_bpp is used to retrieve the bpp from

[Intel-gfx] [PATCH 2/3 V3] drm/i915/BXT: Fixed COS blanking issue

From: Uma Shankar During Charging OS mode, mipi display was blanking.This is because during driver load, though encoder, connector were active but crtc returned inactive. This caused sanitize function to disable the DSI panel. In AOS, this is fine since HWC will do a

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Fixed COS blanking issue

Hi, Thanks for the review comments. Addressing them in next version. On Thursday 04 February 2016 07:24 PM, Jani Nikula wrote: On Wed, 03 Feb 2016, Ramalingam C wrote: From: Uma Shankar During Charging OS mode, mipi display was blanking.This

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Using the bpp value wrt the pixel format

On Thursday 04 February 2016 06:43 PM, Jani Nikula wrote: On Wed, 03 Feb 2016, Ramalingam C wrote: From: Deepak M The bpp value which is used while calulating the txbyteclkhs values should be wrt the pixel format value. Currently bpp is coming

[Intel-gfx] [PATCH 3/3] drm/i915: Updating the CPU_TRANSCODER for BXT DSI

In case of BXT DSI we are updating the CPU_TRANSCODER with appropriate value. Signed-off-by: Ramalingam C Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/intel_display.c |5 + 2 files

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

Em Ter, 2016-02-09 às 12:33 +0530, Kamble, Sagar A escreveu: > Hi Paulo, > > Thanks for comments. > 1. Will make change related to #define for number of pipes and > remove  > the unnecessary ones. > 2. vrefresh is almost same as "clock/(htotal*vtotal) if we round up  > later. Will keep it

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Disable use of stolen area by User when Intel RST is present

Hi Ankitprasad, On Thu, Feb 04, 2016 at 05:43:17PM +0100, Lukas Wunner wrote: > On Thu, Feb 04, 2016 at 04:05:04PM +, Chris Wilson wrote: > > We could #define INTEL_RAPID_START "INT3392" for > > if (IS_ENABLED(CONFIG_SUSPEND) && acpi_dev_present(INTEL_RAPID_START)) > > but Anki wanted to keep

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Introduce i915_gem_object_get_dma_address()

On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote: From: Chris Wilson This utility function is a companion to i915_gem_object_get_page() that uses the same cached iterator for the scatterlist to perform fast sequential lookup of the dma address associated with

Re: [Intel-gfx] [IGT PATCH 5/6] kms_force_connector_basic: Add force-load-detect test

Op 11-02-16 om 09:59 schreef Daniel Vetter: > On Mon, Feb 01, 2016 at 02:44:01PM +0100, Maarten Lankhorst wrote: >> Signed-off-by: Maarten Lankhorst >> --- >> diff --git a/tests/kms_force_connector_basic.c >> b/tests/kms_force_connector_basic.c >> index

Re: [Intel-gfx] Video glitches E3845 ATOM, Fedora 21

On Wed, Feb 10, 2016 at 07:16:03PM +, Rogers, Martin wrote: > Hi Jani, > > I have not submitted a bug yet, because no kernel msgs were produced the > moment I recreated the issue. > I used : drm.debug=0x14 That should be drm.debug=14 or drm.debug=0xe > > Can you suggest something else ?

[Intel-gfx] [PATCH i-g-t v4 1/3] tests/gem_concurrent_blit: rename gem_concurrent_all

We'll both rename gem_concurrent_all over gem_concurrent_blit and change gem_concurrent_blit in this changeset. To make this easier to follow we first do the the rename. Signed-off-by: David Weinehall --- tests/gem_concurrent_blit.c | 1548

[Intel-gfx] [PATCH i-g-t v4 0/3] Unify slow/combinatorial test handling

Until now we've had no unified way to handle slow/combinatorial tests. Most of the time we don't want to run slow/combinatorial tests, so this should remain the default, but when we do want to run such tests, it has been handled differently in different tests. This patch adds an --all command

Re: [Intel-gfx] [PATCH v4 0/6] Check pixel clock when setting mode

> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Thursday, February 11, 2016 11:21 AM > To: Kahola, Mika > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v4 0/6] Check pixel clock

Re: [Intel-gfx] [PATCH v4 07/12] drm/i915: GEM operations need to be done under the big lock

On Tue, Feb 02, 2016 at 02:46:19PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > VMA creation and GEM list management need the big lock. > > v2: > > Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) > > Not to mention

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix some invalid requests cancellations

On 29/01/16 16:49, Chris Wilson wrote: As we add the VMA to the request early, it may be cancelled during execbuf reservation. This will leave the context object pointing to a I don't get it, request is created after the reservation. dangling request; i915_wait_request() simply skips the

[Intel-gfx] [PATCH 2/5] drm/i915: GEM operations need to be done under the big lock

From: Tvrtko Ursulin VMA creation and GEM list management need the big lock. v2: Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) Not to mention drm_gem_object_unreference was there in existing code with no mutex held. v3: Some callers of

[Intel-gfx] [PATCH 3/5] drm/i915: Fix struct mutex vs. RPS lock inversion

From: Tvrtko Ursulin RPS lock must be taken before the struct_mutex to avoid locking inversion. So stop grabbing it for the whole powersave initialization and instead only take it during the sections which need it. Also, struct_mutex is not needed any more since

[Intel-gfx] [PATCH 4/5] drm/i915/guc: Do not wait for firmware load atomically

From: Tvrtko Ursulin It does not look like this code needs to wait atomically? Higher in the call chain it calls the GEM API and I do not see that the section is under any spin locks or such. Signed-off-by: Tvrtko Ursulin Cc: Alex Dai

[Intel-gfx] [PATCH 5/5] drm/i915/ilk: Move register read under spinlock

From: Tvrtko Ursulin Code does read-modify-write but the read was outside the lock. It is fine since the caller holds struct mutex, but if we correct this we open up the opportunity for decreasing the mutex duration time since the call to ironlake_enable_drps does not

[Intel-gfx] [PATCH 0/5] Assorted reviewed patches for CI run

From: Tvrtko Ursulin As the subject says, just to trigger a CI run for some assorted patches which are all already R-Bed. Tvrtko Ursulin (5): drm/i915: Use appropriate spinlock flavour drm/i915: GEM operations need to be done under the big lock drm/i915: Fix

[Intel-gfx] [PATCH 1/5] drm/i915: Use appropriate spinlock flavour

From: Tvrtko Ursulin We know this never runs from interrupt context so don't need to use the flags variant. Signed-off-by: Tvrtko Ursulin Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c | 6 ++ 1

Re: [Intel-gfx] [PATCH V3] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

On Tue, Feb 09, 2016 at 04:28:27PM -0800, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Track VCO frequency of SKL instead of the boot CDCLK and allow modeset > to set cdclk based on the max required pixel clock based on VCO > selected. > > The vco

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

Ville, here is another dmesg: [1] I've reconnected HDMI cable three times. Forgot to note, it is HDMI monitor plugged into machine's DVI with HDMI-DVI cable. I guess this should matter as well. [1] https://gist.github.com/7057ea8512b9aa7ee5bd 11.02.2016 11:26, Ville Syrjälä написав: On

Re: [Intel-gfx] [PATCH i-g-t v4 2/3] lib/igt_core: Unify handling of slow/combinatorial tests

On Thu, Feb 11, 2016 at 01:09:33PM +0200, David Weinehall wrote: > +enum { > + /* The set of tests run if nothing else is specified */ > + SUBTEST_TYPE_NORMAL = 1 << 0, > + /* Basic Acceptance Testing set */ > + SUBTEST_TYPE_BASIC = 1 << 1, > + /* Tests that are very slow */ >

Re: [Intel-gfx] [PATCH] drm/i915: Fix hpd live status bits for g4x

On Wed, Feb 10, 2016 at 07:59:05PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Looks like g4x hpd live status bits actually agree with the spec. At > least they do on the machine I have, and apparently on Nick Bowler's > g4x as well. > >

[Intel-gfx] [RFC] drm/i915/guc: Keep the previous context pinned until the next one has been completed

From: Tvrtko Ursulin In GuC mode submitting requests is only putting them into the GuC queue with the actual submission to hardware following at some future point. This makes the per engine last context tracking insufficient for closing the premature context unpin race.

Re: [Intel-gfx] [PATCH 3/4] agp/intel-gtt: Only register fake agp driver for gen1

On Thu, Feb 11, 2016 at 12:31:45PM +0200, Ville Syrjälä wrote: > On Wed, Jan 27, 2016 at 02:38:00PM +0100, Daniel Vetter wrote: > > The fake agp driver for the intel graphics gart is only needed for ums > > support. And we ditched that a long time ago: > > > > commit

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Add support for mapping an object page by page

On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote: From: Chris Wilson Introduced a new vm specfic callback insert_page() to program a single pte in ggtt or ppgtt. This allows us to map a single page in to the mappable aperture space. This can be iterated over

Re: [Intel-gfx] [PATCH 136/190] drm/i915: Move ioremap_wc tracking onto VMA

On 11/01/16 10:45, Chris Wilson wrote: By tracking the iomapping on the VMA itself, we can share that area between multiple users. Also by only revoking the iomapping upon unbinding from the mappable portion of the GGTT, we can keep that iomap across multiple invocations (e.g. execlists

Re: [Intel-gfx] [PATCH 136/190] drm/i915: Move ioremap_wc tracking onto VMA

On 11/02/16 13:29, Chris Wilson wrote: On Thu, Feb 11, 2016 at 01:20:46PM +, Tvrtko Ursulin wrote: On 11/01/16 10:45, Chris Wilson wrote: By tracking the iomapping on the VMA itself, we can share that area between multiple users. Also by only revoking the iomapping upon unbinding from

Re: [Intel-gfx] [PATCH 136/190] drm/i915: Move ioremap_wc tracking onto VMA

On Thu, Feb 11, 2016 at 01:20:46PM +, Tvrtko Ursulin wrote: > > > On 11/01/16 10:45, Chris Wilson wrote: > >By tracking the iomapping on the VMA itself, we can share that area > >between multiple users. Also by only revoking the iomapping upon > >unbinding from the mappable portion of the

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915: tidy up initialisation failure paths (legacy)

On Mon, Feb 01, 2016 at 09:38:02AM +, Dave Gordon wrote: > On 30/01/16 10:50, Chris Wilson wrote: > >On Fri, Jan 29, 2016 at 07:19:26PM +, Dave Gordon wrote: > >>1. Fix intel_cleanup_ring_buffer() to handle the error cleanup > >>case where the ringbuffer has been allocated but

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: fix context/engine cleanup order

On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote: > On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote: > > From: Nick Hoath > > > > Swap the order of context & engine cleanup, so that contexts are cleaned > > up first, and *then* engines. This is a

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

On Thu, Feb 11, 2016 at 01:16:53PM +0200, Oleksandr Natalenko wrote: > Ville, > > here is another dmesg: [1] > > I've reconnected HDMI cable three times. > > Forgot to note, it is HDMI monitor plugged into machine's DVI with > HDMI-DVI cable. I guess this should matter as well. Shouldn't

Re: [Intel-gfx] [PATCH i-g-t v4 2/3] lib/igt_core: Unify handling of slow/combinatorial tests

On Thu, Feb 11, 2016 at 01:04:14PM +, Chris Wilson wrote: > On Thu, Feb 11, 2016 at 01:09:33PM +0200, David Weinehall wrote: > > +enum { > > + /* The set of tests run if nothing else is specified */ > > + SUBTEST_TYPE_NORMAL = 1 << 0, > > + /* Basic Acceptance Testing set */ > > +

Re: [Intel-gfx] [PATCH] drm/i915: Hide GEM shutdown in i915_gem_fini

On Thu, Feb 11, 2016 at 03:39:25PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > As we have i915_gem_init, do the reverse in new i915_gem_fini so > the fragile order of doing things is hidden from the outside and > only at one place. > > Signed-off-by: Tvrtko

[Intel-gfx] [PATCH] drm/i915: Hide GEM shutdown in i915_gem_fini

From: Tvrtko Ursulin As we have i915_gem_init, do the reverse in new i915_gem_fini so the fragile order of doing things is hidden from the outside and only at one place. Signed-off-by: Tvrtko Ursulin Cc: Nick Hoath

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

On Thu, Feb 11, 2016 at 08:05:26AM -0800, Matt Roper wrote: > On Thu, Feb 11, 2016 at 12:00:50PM +0200, Ville Syrjälä wrote: > > On Wed, Feb 10, 2016 at 06:32:59PM -0800, Matt Roper wrote: > > > Gen9 platforms allow CRTC's to be programmed with a background/canvas > > > color below the

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

On Thu, Feb 11, 2016 at 12:00:50PM +0200, Ville Syrjälä wrote: > On Wed, Feb 10, 2016 at 06:32:59PM -0800, Matt Roper wrote: > > Gen9 platforms allow CRTC's to be programmed with a background/canvas > > color below the programmable planes. Let's expose this as a property to > > allow userspace to

Re: [Intel-gfx] Video glitches E3845 ATOM, Fedora 21

Submitted bug # 94104. https://bugs.freedesktop.org/show_bug.cgi?id=94104 Thanks, Martin -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Thursday, February 11, 2016 5:34 AM To: Rogers, Martin Cc: Jani Nikula; intel-gfx@lists.freedesktop.org Subject:

[Intel-gfx] [PATCH] drm/i915: Avoid vblank counter for gen9+

Framecounter register is read-only so DMC cannot restore it after exiting DC5 and DC6. Easiest way to go is to avoid the counter and use vblank interruptions for this platform and for all the following ones since DMC came to stay. At least while we can't change this register to read-write.

Re: [Intel-gfx] [PATCH V4] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

[I'm cheating and doing this code review with the author watching over my shoulder] On 11/02/16 15:22, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Track VCO frequency of SKL instead of the boot CDCLK and allow modeset > to set cdclk based on the max

Re: [Intel-gfx] [PATCH] drm/i915: Avoid vblank counter for gen9+

Hi Rodrigo, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.5-rc3 next-20160211] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Rodrigo-Vivi/drm-i915

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Execlist irq handler micro optimisations

On Thu, Feb 11, 2016 at 06:03:10PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Assorted changes most likely without any practical effect > apart from a tiny reduction in generated code for the interrupt > handler and request submission. > > * Remove

[Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

From: Alex Dai GuC client object is always pinned during its life cycle. We cache the kmap of its first page, which includes guc_process_desc and doorbell. By doing so, we can simplify the code where we read from this page to get where GuC is progressing on work queue; and the

[Intel-gfx] [PATCH V4] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

From: Clint Taylor Track VCO frequency of SKL instead of the boot CDCLK and allow modeset to set cdclk based on the max required pixel clock based on VCO selected. The vco should be tracked at the atomic level and all CRTCs updated if the required vco is changed. At

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Do not return stale status / remove impossible WARN

On Thu, Feb 11, 2016 at 06:03:09PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Only caller to get_context_status ensures read pointer stays in > range so the WARN is impossible. Also, if the WARN would be > triggered by a hypothetical new caller stale status

Re: [Intel-gfx] [PATCH V5] drm/i915: edp resume/On time optimization.

On 1/22/2016 5:39 PM, Kumar, Abhay wrote: From: Abhay Kumar Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if this time is already spent in suspend/poweron time. v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle delay

Re: [Intel-gfx] [PATCH] drm/i915: Avoid vblank counter for gen9+

Hi Rodrigo, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.5-rc3 next-20160211] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Rodrigo-Vivi/drm-i915

Re: [Intel-gfx] [PATCH] drm/i915: Hide GEM shutdown in i915_gem_fini

Hi Tvrtko, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20160211] [cannot apply to v4.5-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Tvrtko

[Intel-gfx] [PATCH 2/2] drm/i915: Execlist irq handler micro optimisations

From: Tvrtko Ursulin Assorted changes most likely without any practical effect apart from a tiny reduction in generated code for the interrupt handler and request submission. * Remove needless initialization. * Improve cache locality by reorganizing code and/or using

[Intel-gfx] [PATCH 1/2] drm/i915: Do not return stale status / remove impossible WARN

From: Tvrtko Ursulin Only caller to get_context_status ensures read pointer stays in range so the WARN is impossible. Also, if the WARN would be triggered by a hypothetical new caller stale status would be returned to them. Maybe it is better to wrap the pointer in the

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

On Wed, Feb 10, 2016 at 06:32:59PM -0800, Matt Roper wrote: > Gen9 platforms allow CRTC's to be programmed with a background/canvas > color below the programmable planes. Let's expose this as a property to > allow userspace to program a desired value. > > This patch is based on earlier work by

Re: [Intel-gfx] [PATCH 3/4] agp/intel-gtt: Only register fake agp driver for gen1

On Wed, Jan 27, 2016 at 02:38:00PM +0100, Daniel Vetter wrote: > The fake agp driver for the intel graphics gart is only needed for ums > support. And we ditched that a long time ago: > > commit 03dae59c72d8ef6e005f48ba356c863e0587 > Author: Daniel Vetter > Date:

[Intel-gfx] [PATCH i-g-t] Use uint64_t in eviction memory subtest parameters

With large apertures we need to use uint64_t for counts and sizes. commit 0e2071411a4d4e1488a821daf522dffde2809e03 paved way for this but forgot to change the subtest parameters. v2: Pass correctly to the copy() also (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=93849

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Check for DC state mismatch

Patrik Jakobsson writes: > The DMC can incorrectly run off and allow DC states on it's own. We > don't know the root-cause for this yet but this patch makes it more > visible. > > Signed-off-by: Patrik Jakobsson Yes, we

[Intel-gfx] [PATCH i-g-t v4 2/3] lib/igt_core: Unify handling of slow/combinatorial tests

Some subtests are not run by default, for various reasons; be it because they're only for debugging, because they're slow, or because they are not of high enough quality. This patch aims to introduce a common mechanism for categorising the subtests and introduces a flag (--all) that runs/lists

[Intel-gfx] [PATCH i-g-t v4 3/3] tests/gem_concurrent_all: Remove gem_concurrent_all.c

When gem_concurrent_blit was converted to use the new common framework for choosing whether or not to include slow/combinatorial tests, gem_concurrent_all became superfluous. This patch removes it. Signed-off-by: David Weinehall --- tests/Makefile.sources |

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects

On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma This patch adds support for extending the pread/pwrite functionality for objects not backed by shmem. The access will be made through gtt interface. This will cover objects

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Don't ERROR for an expected intel_rcs_ctx_init() interruption

On 29/01/16 16:49, Chris Wilson wrote: intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait upon a full ring to advance). Don't emit an error for this. Testcase: igt/gem_concurrent_blit Signed-off-by: Chris Wilson ---