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

On Thu, 11 Feb 2016, ville.syrj...@linux.intel.com wrote: > 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

[Intel-gfx] [PATCH i-g-t 0/4] Scheduler tests

This patch set adds scheduler tests. Patch 1 adds library code used by the tests. There are other tests under development which are planned to reuse some of these libraries. Patch 2 adds some basic tests, read dependency tests and write dependency tests. Patch 3 Is the patch previously submitted

[Intel-gfx] [PATCH i-g-t 2/4] tests/gem_scheduler: Add gem_scheduler test

This is intended to test the scheduler behaviour is correct. The subtests are -basic Tests that batch buffers of the same priority submitted to a ring execute in the order they are submitted. -read Submits a batch buffer with a read dependency to a buffer object to a ring which is held in the

[Intel-gfx] [PATCH i-g-t 1/4] lib/igt_bb_factory: Add igt_bb_factory library

Adds functions to create a number of different batch buffers to perform several functions including: Batch buffer which will run for a long duration to provide a delay on a specified ring. Function to calibrate the delay batch buffer to run for a specified period of time. Function to create a

[Intel-gfx] [PATCH i-g-t 3/4] igt/gem_ctx_param_basic: Updated to support scheduler priority interface

From: John Harrison The GPU scheduler has added an execution priority level to the context object. There is an IOCTL interface to allow user apps/libraries to set this priority. This patch updates the context paramter IOCTL test to include the new interface. For:

[Intel-gfx] [PATCH i-g-t 4/4] tests/gem_scheduler: Add subtests to test batch priority behaviour

Add subtests to test each ring to check batch buffers of a higher priority will be executed before batch buffers of a lower priority. Signed-off-by: Derek Morton --- tests/gem_scheduler.c | 34 -- 1 file changed, 28 insertions(+), 6

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

On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote: > 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

[Intel-gfx] [PATCH i-g-t v5] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

From: Mayuresh Gharpure Co-Author : Marius Vlad Co-Author : Pratik Vishwakarma So far we have had only two commit styles, COMMIT_LEGACY and COMMIT_UNIVERSAL. This patch adds another commit style

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

On Thu, Feb 11, 2016 at 03:22:08PM -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] [PATCH v10 2/4] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

On Fri, Feb 12, 2016 at 01:53:10PM +0200, Ville Syrjälä wrote: > On Thu, Jan 21, 2016 at 03:10:19PM -0800, Rafael Antognolli wrote: > > This module is heavily based on i2c-dev. Once loaded, it provides one > > dev node per DP AUX channel, named drm_dp_auxN, where N is an integer. > > > > It's

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, More drm-misc stuff: - vgaswitcheroo support for apple gmux from Lukas Wunner - checks for ->mode_fixup in non-atomic helpers from Carlos Palminha, plus removing dummy funcs from drivers. Carlos promised to follow up with more, since there's lots more silly dummy functions around. -

Re: [Intel-gfx] [PATCH i-g-t v5] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

Please fix the typo in the subject. BR, Jani. On Fri, 12 Feb 2016, Pratik Vishwakarma wrote: > From: Mayuresh Gharpure > > Co-Author : Marius Vlad > Co-Author : Pratik Vishwakarma

[Intel-gfx] [PATCH v2] 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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Add drm_dp_aux chardev support. (rev5)

On Fri, Jan 22, 2016 at 09:15:31AM -, Patchwork wrote: > == Summary == > > Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: > 2016y-01m-21d-11h-02m-42s UTC integration manifest > > Test kms_flip: > Subgroup basic-flip-vs-dpms: > pass ->

[Intel-gfx] [PATCH] drm/i915: Set invert bit for hpd based on VBT

This patch sets the invert bit for hpd detection for each port based on VBT configuration. Since each AOB can be designed to depend on invert bit or not, it is expected if an AOB requires invert bit, the user will set respective bit in VBT. v2: Separated VBT parsing from the rest of the logic.

[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices

This patch adds new fields that are not yet added in drm code in child devices struct Signed-off-by: Sivakumar Thulasimani Signed-off-by: Durgadoss R Signed-off-by: Shubhangi Shrivastava ---

[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

This patch sets the invert bit for hpd detection for each port based on VBT configuration. Since each AOB can be designed to depend on invert bit or not, it is expected if an AOB requires invert bit, the user will set respective bit in VBT. v2: Separated VBT parsing from the rest of the logic.

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

On Thu, Feb 11, 2016 at 05:11:52PM -0800, Marc Herbert wrote: > [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

Re: [Intel-gfx] [PATCH v10 2/4] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

On Thu, Jan 21, 2016 at 03:10:19PM -0800, Rafael Antognolli wrote: > This module is heavily based on i2c-dev. Once loaded, it provides one > dev node per DP AUX channel, named drm_dp_auxN, where N is an integer. > > It's possible to know which connector owns this aux channel by looking > at the

Re: [Intel-gfx] [PATCH v10 1/4] drm/kms_helper: Add a common place to call init and exit functions.

On Thu, Jan 21, 2016 at 03:10:18PM -0800, Rafael Antognolli wrote: > The module_init and module_exit functions will start here, and call the > subsequent init's and exit's. > > v10: > - Keep __init on drm_fb_helper init function. > - Move MODULE_* macros to the common file. > > Signed-off-by:

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

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > intel_post_plane_update did an extra vblank wait that's no longer > needed when enabling ips. > > Signed-off-by: Maarten Lankhorst > --- >  drivers/gpu/drm/i915/intel_display.c | 3 --- >  1 file

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

On 11/02/16 23:09, yu@intel.com wrote: 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

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

On 12/02/16 10:21, Chris Wilson wrote: On Fri, Feb 12, 2016 at 10:05:58AM +, Tvrtko Ursulin wrote: On 11/02/16 21:00, Chris Wilson wrote: On Thu, Feb 11, 2016 at 06:03:09PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Only caller to get_context_status

Re: [Intel-gfx] [PATCH] drm/i915: Set invert bit for hpd based on VBT

Hi Shubhangi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160212] [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/Shubhangi

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

On Fri, Feb 12, 2016 at 12:00:40PM +, 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 i-g-t] tests/prime_mmap: Encapsulate check_for_dma_buf_mmap() in igt_fixture.

This unbreaks distcheck target that in turn runs each test with --list-subtests. Signed-off-by: Marius Vlad --- tests/prime_mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c index 29a0cfd..1ea61c2 100644

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

On Fri, Feb 12, 2016 at 06:39:44PM +0530, Shubhangi Shrivastava wrote: > This patch sets the invert bit for hpd detection for each port > based on VBT configuration. Since each AOB can be designed to > depend on invert bit or not, it is expected if an AOB requires > invert bit, the user will set

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

On Fri, Feb 12, 2016 at 01:46:35PM +, Tvrtko Ursulin wrote: > > > On 12/02/16 12:00, 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 >

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

On Fri, Feb 12, 2016 at 05:06:07PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or > up to 675 MHz on ULT, bu only if extra cooling is provided. There > don't seem to be any

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

Hi Shubhangi, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20160212] [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

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

On 12/02/16 12:00, 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 needless initialization. * Improve

[Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

From: Ville Syrjälä Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or up to 675 MHz on ULT, bu only if extra cooling is provided. There don't seem to be any strap or VBT bits to tells us this however. But I did spot something potentially relevant

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

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > Factor out intel_fbc_supports_rotation ^ not anymore > and use it in > pre_plane_update as well. This leaves intel_crtc->atomic > empty, so remove it too. > > Changes since v1: > - Add a intel_fbc_supports_rotation helper.

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

On 11/02/16 21:00, Chris Wilson wrote: > 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 >>

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

On Fri, Feb 12, 2016 at 10:05:58AM +, Tvrtko Ursulin wrote: > > On 11/02/16 21:00, Chris Wilson wrote: > > On Thu, Feb 11, 2016 at 06:03:09PM +, Tvrtko Ursulin wrote: > >> From: Tvrtko Ursulin > >> > >> Only caller to get_context_status ensures read pointer

Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote: > To support USB type C alternate DP mode, the display driver needs to > know the number of lanes required by the DP panel as well as number > of lanes that can be supported by the type-C cable. Sometimes, the > type-C cable may limit the

[Intel-gfx] [PATCH] drm/i915: Split bxt_ddi_pll_select()

Split out of bxt_ddi_pll_select() the logic that calculates the pll dividers and dpll_hw_state into a new function that doesn't depend on crtc state. This will be used for enabling the port pll when doing upfront link training. Signed-off-by: Ander Conselvan de Oliveira

Re: [Intel-gfx] [PATCH 7/7] sna: add an assert in the lengthy sna_drawable_use_bo

On Fri, Feb 12, 2016 at 06:31:29PM +0200, Martin Peres wrote: > I got lost in all the changes done on priv->flush and gpu_bo enough > not to be able to guarantee that if flush is non-null, so is gpu_bo. > > Caught by Klockwork. Nope, impossible. -Chris -- Chris Wilson, Intel Open Source

Re: [Intel-gfx] [PATCH 6/7] sna_video_sprite: add asserts to catch invalid pipe#

On Fri, Feb 12, 2016 at 06:31:28PM +0200, Martin Peres wrote: > Caught by Klockwork. This will be enough to catch those issues during > bringup. But you just said that klockwork didn't find a bug... :-p I did contemplate having this stored on the CRTC instead. Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCHv2 2/4] drm/i915: Make finding unused crtc as a generic function

On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote: > Looping over the crtc list and finding an unused crtc > has users other than load_detect(). Which other users? If there are other users they should be converted in this patch. If the use will only come in a future patch, please make that

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Cleaning up intel_dp_hpd_pulse

On Wed, 2016-02-10 at 14:34 +0530, Shubhangi Shrivastava wrote: > Current DP detection has DPCD operations split across > intel_dp_hpd_pulse and intel_dp_detect which contains > duplicates as well. Also intel_dp_detect is called > during modes enumeration as well which will result > in multiple

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Save sink_count for tracking changes to it and read sink_count dpcd always

I think I mentioned something about the patch summary (the title) being too big before. The kernel documentation on submitting patches [1] says: "the "summary" must be no more than 70-75 characters". [1] https://www.kernel.org/doc/Documentation/SubmittingPatches Cheers, Ander On Wed, 2016-02-10

[Intel-gfx] kernel crash in snd_hda_intel

!!! This caused a regression in the i-g-t drv_module_reload_basic test. Reproducible easily on HSW (i5-4460) with: #rmmod snd_hda_intel The bisect shows this as the offending commit: commit 25e4abb33df3aafa7d1efba8f82f9178268efab1 Author: Libin Yang Date: Tue

Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd

On Fri, Feb 12, 2016 at 06:31:23PM +0200, Martin Peres wrote: > This is not a big issue to return -1 since the only codepath that uses > it is for display purposes. Impossible. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx

[Intel-gfx] [PATCH 00/12] drm/i915: add missing display power refs

This patchset adds missing display power domain references during modeset HW readout, which I noticed via wakeref warnings the corresponding HW accesses triggered. The crt and ddi patches have a concrete bugzilla reference they fix, I don't know of reports that would be fixed by the rest of the

[Intel-gfx] [PATCH 01/12] drm/i915: add helper to get a display power ref if it was already enabled

We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always

[Intel-gfx] [PATCH 08/12] drm/i915: ensure the HW is powered when accessing the CRC HW block

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 09/12] drm/i915/dp: ensure the HW is powered during HW state readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 04/12] drm/i915: ensure the HW is powered when disabling VGA

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 05/12] drm/i915: ensure the HW is powered during HW access in assert_pipe

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

On Mon, Feb 01, 2016 at 07:27:53PM +0530, Durgadoss R wrote: > To support USB type C alternate DP mode, the display driver needs to > know the number of lanes required by the DP panel as well as number > of lanes that can be supported by the type-C cable. Sometimes, the > type-C cable may limit

Re: [Intel-gfx] [PATCH 2/7] display: prevent a NULL pointer dereference in intel_set_scanout_pixmap

On Fri, Feb 12, 2016 at 06:31:24PM +0200, Martin Peres wrote: > Caught by Klockwork. > > Signed-off-by: Martin Peres > --- > src/uxa/intel_display.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c >

Re: [Intel-gfx] [PATCH 5/7] sna/cursor: add an assert on cursor->image

On Fri, Feb 12, 2016 at 06:31:27PM +0200, Martin Peres wrote: > Caught by Klockwork, but it was a false positive. However, better safe > than sorry. No. cursor->image can be NULL for old gen/kernels. -Chris -- Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH 06/12] drm/i915/crt: ensure the HW is powered during HW state readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 11/12] drm/i915/hdmi: ensure the HW is powered during HW state readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 03/12] drm/i915/ibx: ensure the HW is powered during PLL HW readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 02/12] drm/i915: ensure the HW is powered during display pipe HW readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 12/12] drm/i915/lvds: ensure the HW is powered during HW state readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 10/12] drm/i915/dsi: ensure the HW is powered during HW state readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

[Intel-gfx] [PATCH 07/12] drm/i915/ddi: ensure the HW is powered during HW state readout

The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access.

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

ed 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-i91 > 5-Avoid-vblank-counter-for-gen9/20160212-090608 > base: git://anongit.freedesktop.org/drm-intel for-linux-next > conf

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

On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote: > 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

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

On 12/02/16 14:42, Chris Wilson wrote: On Fri, Feb 12, 2016 at 12:00:40PM +, 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

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

Oh, actually please just ignore this patch completely. More work here need to be done. This apparently helped on the issue that I was facing here but doesnt' solve completely. On Fri, 2016-02-12 at 07:58 -0800, Rodrigo Vivi wrote: > On Fri, 2016-02-12 at 11:34 +0200, David Weinehall wrote: > > On

Re: [Intel-gfx] [PATCH 4/7] sna: assert a pointer is non-NULL before dereferencing it

On Fri, Feb 12, 2016 at 06:31:26PM +0200, Martin Peres wrote: > Caught by Klockwork. Impossible. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

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

On Fri, 2016-02-12 at 11:34 +0200, David Weinehall wrote: > On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote: > > 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 > >

Re: [Intel-gfx] [PATCH v4 03/38] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

On 04/02/2016 17:01, Jesse Barnes wrote: On 01/11/2016 10:42 AM, john.c.harri...@intel.com wrote: From: John Harrison The scheduler decouples the submission of batch buffers to the driver with their submission to the hardware. This basically means splitting the

[Intel-gfx] [PATCH 3/7] sna: check for NULL before dereferencing a pointer

Caught by Klockwork and I genuinely can't tell if it is safe without it, especially since all the surrounding code is checking for NULL. Signed-off-by: Martin Peres --- src/sna/sna_accel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 7/7] sna: add an assert in the lengthy sna_drawable_use_bo

I got lost in all the changes done on priv->flush and gpu_bo enough not to be able to guarantee that if flush is non-null, so is gpu_bo. Caught by Klockwork. Signed-off-by: Martin Peres --- src/sna/sna_accel.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Intel-gfx] [PATCH 4/7] sna: assert a pointer is non-NULL before dereferencing it

Caught by Klockwork. Signed-off-by: Martin Peres --- src/sna/sna_accel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c index 8ceb1e1..f1c136a 100644 --- a/src/sna/sna_accel.c +++ b/src/sna/sna_accel.c @@ -4376,6

[Intel-gfx] [PATCH 6/7] sna_video_sprite: add asserts to catch invalid pipe#

Caught by Klockwork. This will be enough to catch those issues during bringup. Signed-off-by: Martin Peres --- src/sna/sna_video_sprite.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/sna/sna_video_sprite.c b/src/sna/sna_video_sprite.c index

[Intel-gfx] [PATCH 2/7] display: prevent a NULL pointer dereference in intel_set_scanout_pixmap

Caught by Klockwork. Signed-off-by: Martin Peres --- src/uxa/intel_display.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c index 8bf0184..44744a5 100644 --- a/src/uxa/intel_display.c +++

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

On Fri, Jan 22, 2016 at 05:39:04PM -0800, abhay.ku...@intel.com 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

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

On Fri, Feb 12, 2016 at 03:54:27PM +, Tvrtko Ursulin wrote: > > On 12/02/16 14:42, Chris Wilson wrote: > >On Fri, Feb 12, 2016 at 12:00:40PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Assorted changes most likely without any practical effect >

[Intel-gfx] [PATCH 5/7] sna/cursor: add an assert on cursor->image

Caught by Klockwork, but it was a false positive. However, better safe than sorry. Signed-off-by: Martin Peres --- src/sna/sna_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c index

[Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd

This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres --- src/intel_device.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/intel_device.c

[Intel-gfx] [PATCH DDX 0/7] Some issues found with Klockwork

The DDX clearly is making Klockwork unhappy but I found those potential issues. Let's use them as a basis for discussion on the real code that should be written. Martin Peres (7): device: prevent a NULL pointer dereference in __intel_peek_fd display: prevent a NULL pointer dereference in

Re: [Intel-gfx] [PATCH i-g-t] tests/prime_mmap: Encapsulate check_for_dma_buf_mmap() in igt_fixture.

I'm not sure this actually fix the root problem. With or without your patch applied, I'm seeing the following in lib/tests/test-suite.log: ../../tests/prime_mmap: Checking invalid option handling... Checking valid option handling... Checking subtest enumeration... (prime_mmap:24023)

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

On 02/12/2016 03:18 AM, Ville Syrjälä wrote: On Thu, Feb 11, 2016 at 03:22:08PM -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

[Intel-gfx] [PATCH 2/3] drm/i915: Enable PSR by default on Valleyview and Cherryview.

With a reliable frontbuffer tracking and all instability corner cases solved for this platform let's re-enabled PSR by default. In case a new issue is found and PSR is the main suspect, please check if i915.enable_psr=0 really makes your problem go away, please report it at bugs.freedesktop.org.

[Intel-gfx] [PATCH 0/3] Enable PSR by default in certain platforms

For a long time we are trying to enable PSR by default everwhere but we always end up in soem specific corner case in one platform or another and end up not enabling in older stable platforms that could benefit from the power saving it provides. So, let's change the approach here and try to

[Intel-gfx] [PATCH 3/3] drm/i915: Enable PSR by default on Haswell and Broadwell.

With a reliable frontbuffer tracking and all instability corner cases on Haswell and Broadwell solved let's re-enabled PSR by default on these platforms. In case a new issue is found and PSR is the main suspect, please check if i915.enable_psr=0 really makes your problem go away. If this is the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Add drm_dp_aux chardev support. (rev5)

On Fri, Feb 12, 2016 at 01:21:33PM -0800, Rafael Antognolli wrote: > On Fri, Feb 12, 2016 at 02:01:11PM +0200, Ville Syrjälä wrote: > > On Fri, Jan 22, 2016 at 09:15:31AM -, Patchwork wrote: > > > == Summary == > > > > > > Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:

Re: [Intel-gfx] [PATCH v10 4/4] drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled

On Thu, Jan 21, 2016 at 6:10 PM, Rafael Antognolli wrote: > From: Lukas Wunner > > Rafael Antognolli's new DRM_DP_AUX_CHARDEV feature causes a WARN_ON > if drm_dp_aux->dev == drm_connector->kdev and drm_dp_aux_unregister() > is called after

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

On Fri, Feb 12, 2016 at 09:52:03AM +0200, Oleksandr Natalenko wrote: > 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 :). > My life would have

Re: [Intel-gfx] [PATCH v10 3/4] drm/i915: Set aux.dev to the drm_connector device, instead of drm_device.

On Thu, 2016-01-21 at 15:10 -0800, Rafael Antognolli wrote: > So far, the i915 driver and some other drivers set it to the > drm_device, > which doesn't allow one to know which DP a given aux channel is > related > to. Changing this to be the drm_connector provides proper nesting, > still >

[Intel-gfx] [PATCH 1/3] drm/i915: Change i915.enable_psr parameter to use per platform default.

This will give us flexibility to enable PSR by default independently so issues and corner cases in one platform won't affect others were we have it working properly. Cc: Paulo Zanoni Signed-off-by: Rodrigo Vivi ---

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Add drm_dp_aux chardev support. (rev5)

On Fri, Feb 12, 2016 at 02:01:11PM +0200, Ville Syrjälä wrote: > On Fri, Jan 22, 2016 at 09:15:31AM -, Patchwork wrote: > > == Summary == > > > > Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: > > 2016y-01m-21d-11h-02m-42s UTC integration manifest > > > > Test

[Intel-gfx] 4.3.3 / skylake / dual graphics: multiple CSR errors at boot from i915 driver

I'm testing a new thinkpad skylake based P70 with dual graphics legolas:~# lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Device 191b (rev 06) 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] (rev a2) I'm getting these warnings at boot,

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

From: Clint Taylor Set cdclk based on the max required pixel clock based on VCO selected. Track boot vco instead of boot cdclk. The vco is now tracked at the atomic level and all CRTCs updated if the required vco is changed. Not tested with eDP v1.4 panels that