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

On Wed, Oct 28, 2015 at 02:12:15PM -0200, Paulo Zanoni wrote: > 2015-10-28 9:29 GMT-02:00 David Weinehall : > > Some tests should not be run by default, due to their slow, > > and sometimes superfluous, nature. > > > > We still want to be able to run these tests in

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

On Wed, Oct 28, 2015 at 05:14:28PM +, Thomas Wood wrote: > If this is intended to be documented and used in tests, then it should > be included in the public API (i.e. without the underscore prefix). True. Will fix. > > + * > > + * This is used to skip subtests that should only be included

[Intel-gfx] [PATCH] drm/i915: Print a debug message when exceeding dotclock limit on pre-gen4

From: Ville Syrjälä Currently there's no trace in dmesg when the gen2/3 dotclock checks reject the modeset. Add some to avoid further head scratching. While at it refactor the code a bit to look nicer. Signed-off-by: Ville Syrjälä

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

On Fri, Oct 30, 2015 at 12:04:17PM +0200, Ville Syrjälä wrote: > On Thu, Oct 29, 2015 at 04:23:45PM -0700, 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

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

On Fri, Oct 30, 2015 at 01:59:22PM -0700, Rafael Antognolli wrote: > On Fri, Oct 30, 2015 at 12:04:17PM +0200, Ville Syrjälä wrote: > > On Thu, Oct 29, 2015 at 04:23:45PM -0700, Rafael Antognolli wrote: > > > This module is heavily based on i2c-dev. Once loaded, it provides one > > > dev node per

[Intel-gfx] [PATCH 1/1] drm/i915/dma: enforce pr_ consistency

One branch of the if clause uses pr_info, the other pr_err; change the 'false' branch to also use pr_info. This minor oversight has gone unfixed since the initial vga_switcheroo implementation in 6a9ee8af. Signed-off-by: Ioan-Adrian Ratiu --- drivers/gpu/drm/i915/i915_dma.c | 2

[Intel-gfx] [PATCH] Revert "drm/i915: Make prepare_plane_fb fully interruptible."

From: Ville Syrjälä This reverts commit b26a6b35581c84124bd78b68cc02d171fbd572c9. commit b26a6b35581c ("drm/i915: Make prepare_plane_fb fully interruptible.") breaks GPU reset on gen3/4 machines. Go back to to non-interruptible. Cc: Maarten Lankhorst

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

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 respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if the

[Intel-gfx] [PATCH v7 2/2] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.

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 allowing one to get the drm_device from it. Some drivers already set it to the

[Intel-gfx] [PATCH v7 0/2] Add drm_dp_aux chardev support.

This series implement support to a drm_dp_aux chardev that allows reading and writing an arbitrary amount of bytes to arbitrary dpcd register addresses using regular read, write and lseek operations. Rafael Antognolli (2): drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

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

On Thu, Oct 29, 2015 at 04:23:45PM -0700, 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

[Intel-gfx] [PATCH v2 1/1] drm/i915/gen9: Check BIOS RC6 setup before enabling RC6

RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 configuration registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control

Re: [Intel-gfx] FW: [PATCH v7 08/25] drm: Add color correction state flag

On Thu, 29 Oct 2015, "Sharma, Shashank" wrote: > HI Jani, > I am getting this warning, from kbuild, for the new flags being added in the > patch series in CRTC state. >>> include/drm/drm_crtc.h:314: warning: No description found for parameter >>>

Re: [Intel-gfx] [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We get spurious PCH FIFO underruns if we enable the reporting too soon > after enabling the crtc. Move it to be the last step, after the encoder > enable. Additionally we need an

Re: [Intel-gfx] [PATCH] drm/i915: Treat ringbuffer vaddress type properly when vmapped

On Fri, Oct 30, 2015 at 01:39:24PM +0200, Mika Kuoppala wrote: > commit def0c5f6b0cd ("drm/i915: Map the ringbuffer using WB on LLC machines") > enhanced ringbuffer access by vmapping the object instead of doing ioremap. > > The address space annotations however have been and should > remain to

[Intel-gfx] [drm-intel:topic/drm-misc 3/6] warning: (DRM_ATMEL_HLCDC && ..) selects DRM_KMS_CMA_HELPER which has unmet direct dependencies (HAS_IOMEM && ..)

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 364b19868ecd11b91d83c921b55022f70c6c64c6 commit: f68b2f3ac407ca71bd0b22a88127087e0842862a [3/6] drm/imx: Remove local fbdev emulation Kconfig option config: m68k-allyesconfig (attached as .config) reproduce: wget

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

On Fri, Oct 30, 2015 at 09:55:03AM -0200, Paulo Zanoni wrote: > 2015-10-30 5:56 GMT-02:00 David Weinehall : > > On Wed, Oct 28, 2015 at 02:12:15PM -0200, Paulo Zanoni wrote: > >> 2015-10-28 9:29 GMT-02:00 David Weinehall > >> : >

Re: [Intel-gfx] 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

On 10/29/2015 10:49 PM, Pavel Machek wrote: > On Sun 2015-10-04 18:30:14, Toralf Förster wrote: >> On 08/04/2015 02:29 PM, Toralf Förster wrote: >>> On 08/02/2015 09:43 AM, Pavel Machek wrote: Any chance to bisect it? >>> Did it. >>> >>> FWIW: the mentioned commit was introduced between 3.18

Re: [Intel-gfx] [PATCH 08/14] drm/i915: Disable FIFO underrun reporting around IBX transcoder B workaround

On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Doing the IBX transcoder B workaround causes underruns on > pipe/transcoder A. Just hide them by disabling underrun reporting for > pipe A around the workaround. > > It might be

Re: [Intel-gfx] [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

On Fri, Oct 30, 2015 at 12:06:09PM +0200, Jani Nikula wrote: > On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We get spurious PCH FIFO underruns if we enable the reporting too soon > > after enabling the crtc. Move it to be

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v4)

On Thu, Oct 29, 2015 at 06:54:38PM -0700, Vivek Kasireddy wrote: > While pinning a fb object to the display plane, only install a fence > if the object is using a normal view. This corresponds with the > behavior found in i915_gem_object_do_pin() where the fencability > criteria is determined only

Re: [Intel-gfx] [PATCH] drm/dp: add eDP DPCD backlight control bit definitions

On Thu, Oct 29, 2015 at 02:27:32PM +0200, Ander Conselvan De Oliveira wrote: > On Thu, 2015-10-29 at 11:03 +0200, Jani Nikula wrote: > > Cc: Yetunde Adebisi > > Signed-off-by: Jani Nikula > > --- > > include/drm/drm_dp_helper.h | 36

Re: [Intel-gfx] [PATCH] drm/i915: Avoid pointer arithmetic in calculating plane surface offset

On 30/10/15 11:26, Mika Kuoppala wrote: VMA offsets are 64 bits. Plane surface offsets are in ggtt and the hardware register to set this is thus 32 bits. Be explicit about these and convert carefully to from vma to final size. This will make sparse happy by not creating 32bit pointers out of

Re: [Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a subtest to validate Y-tiled obj + Y fb modifier (v5)

On 30/10/15 01:44, Vivek Kasireddy wrote: The main goal of this subtest is to trigger the following warning in the function i915_gem_object_get_fence(): if (WARN_ON(!obj->map_and_fenceable)) To trigger this warning, the subtest first creates a Y-tiled object and an associated

[Intel-gfx] [PATCH] drm/i915: Avoid pointer arithmetic in calculating plane surface offset

VMA offsets are 64 bits. Plane surface offsets are in ggtt and the hardware register to set this is thus 32 bits. Be explicit about these and convert carefully to from vma to final size. This will make sparse happy by not creating 32bit pointers out of 64bit vma offsets. Cc: Tvrtko Ursulin

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

2015-10-30 5:56 GMT-02:00 David Weinehall : > On Wed, Oct 28, 2015 at 02:12:15PM -0200, Paulo Zanoni wrote: >> 2015-10-28 9:29 GMT-02:00 David Weinehall : >> > Some tests should not be run by default, due to their slow, >> > and

Re: [Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a subtest to validate Y-tiled obj + Y fb modifier (v5)

Hi Tvrtko, On Fri, 30 Oct 2015 10:22:08 + Tvrtko Ursulin wrote: > > On 30/10/15 01:44, Vivek Kasireddy wrote: > > The main goal of this subtest is to trigger the following warning in > > the function i915_gem_object_get_fence(): > > if

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

On Fri, Oct 30, 2015 at 03:36:28PM -0700, 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

[Intel-gfx] [PATCH i-g-t 1/3 v3] Copy gem_concurrent_all to gem_concurrent_blit

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 | 1116

[Intel-gfx] [PATCH i-g-t 0/3 v3] 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

[Intel-gfx] [PATCH i-g-t 2/3 v3] 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 3/3 v3] Remove superfluous 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/.gitignore |

Re: [Intel-gfx] [PATCH v99 4/4] drm/i915: Treat ringbuffer writes as write to normal memory

Chris Wilson writes: > Ringbuffers are now being written to either through LLC or WC paths, so > treating them as simply iomem is no longer adequate. However, for the > older !llc hardware, the hardware is documentated as treating the TAIL > register update as

Re: [Intel-gfx] [PATCH 08/14] drm/i915: Disable FIFO underrun reporting around IBX transcoder B workaround

On Fri, Oct 30, 2015 at 12:11:45PM +0200, Jani Nikula wrote: > On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Doing the IBX transcoder B workaround causes underruns on > > pipe/transcoder A. Just hide them by disabling

Re: [Intel-gfx] [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

On Fri, 30 Oct 2015, Ville Syrjälä wrote: > On Fri, Oct 30, 2015 at 12:06:09PM +0200, Jani Nikula wrote: >> On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote: >> > From: Ville Syrjälä >> > >> > We get spurious PCH FIFO

Re: [Intel-gfx] [PATCH 00/14] drm/i915: FIFO underrun elimination for PCH platforms

On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > This series eliminates all spurious PCH FIFO underrun reports on my > machines during a BAT run ('-t basic -x reload -x suspend' actually). > It also eliminates the non-spurious but

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

On Fri, Oct 30, 2015 at 03:18:30PM +0200, David Weinehall wrote: > @@ -931,16 +930,20 @@ run_basic_modes(const struct access_mode *mode, > struct buffers buffers; > > for (h = hangs; h->suffix; h++) { > - if (!all && *h->suffix) > - continue; > +

[Intel-gfx] [PATCH] drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)

Reported-by: Keith Webb Suggested-by: Keith Webb Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106671 Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] drm/i915: Treat ringbuffer vaddress type properly when vmapped

Chris Wilson writes: > On Fri, Oct 30, 2015 at 01:39:24PM +0200, Mika Kuoppala wrote: >> commit def0c5f6b0cd ("drm/i915: Map the ringbuffer using WB on LLC machines") >> enhanced ringbuffer access by vmapping the object instead of doing ioremap. >> >> The address space

Re: [Intel-gfx] [PATCH] drm/i915: Allow unready gpu to be reset on gen8

On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote: > Gen9 has had demonstrated cases where forcing a not ready gpu > into reset has caused system hang [1]. > > Gen8 has never to this date demonstrated such behaviour. > > In our CI tests bsw sometimes ends up in a state where it

Re: [Intel-gfx] [PATCH] drm/i915: Allow unready gpu to be reset on gen8

Chris Wilson writes: > On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote: >> Gen9 has had demonstrated cases where forcing a not ready gpu >> into reset has caused system hang [1]. >> >> Gen8 has never to this date demonstrated such behaviour. >> >> In our

Re: [Intel-gfx] [PATCH] drm/i915: Allow unready gpu to be reset on gen8

On Fri, Oct 30, 2015 at 05:18:18PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote: > >> Gen9 has had demonstrated cases where forcing a not ready gpu > >> into reset has caused system hang [1]. > >>

[Intel-gfx] [PATCH] drm/i915: Allow unready gpu to be reset on gen8

Gen9 has had demonstrated cases where forcing a not ready gpu into reset has caused system hang [1]. Gen8 has never to this date demonstrated such behaviour. In our CI tests bsw sometimes ends up in a state where it claims it is not ready for reset, based on reset request, after gpu hang. Allow

[Intel-gfx] [PATCH 2/7] drm/i915/skl: Refuse to load outdated dmc firmware

There is known issue on GT interrupt delivery with DC6 and firmwares <1.21. There is a suspicion that this causes spurious gpu hangs on driver init and with some workloads, as upgrading the firmware to 1.21 makes these problems disappear. As of now the current version included in distribution

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote: > When accessing through the GTT from one CPU whilst concurrently updating > the GGTT PTEs in another thread, the hardware likes to return random > data. As we have strong serialisation prevent us from modifying the PTE > of an active

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

On Fri, Oct 23, 2015 at 10:17:44PM +0100, Dave Gordon wrote: > On 08/10/15 21:50, Wayne Boyer wrote: > >From: Chris Wilson > > > >A long time ago (before 3.14) we relied on a permanent pinning of the > >ifbdev to lock the fb in place inside the GGTT. However, the >

[Intel-gfx] [PATCH] drm/i915: Fall back to zero vswing/preemph if the sink doesn't like the last good values

From: Ville Syrjälä My Lenovo STM STDP3100 miniDP->VGA dongle doesn't seem to like it when we try to start link training with non-zero vswing/preemphasis. So when the initial link training DPCD write fails, retry it with zero values. Fixes a bunch of errors like

Re: [Intel-gfx] [PATCH 06/14] drm/i915: Check for FIFO underruns after modeset on IVB/HSW and CPT/PPT

On Thu, Oct 29, 2015 at 09:25:55PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not > always get an interrupt on a FIFO underrun. But we can always do an > explicit check (like

[Intel-gfx] [PATCH 4/7] drm/i915/skl: Expose DC5/DC6 entry counts

From: Damien Lespiau The CSR firmware expose two counters, handy to check if we are indeed entering DC5/DC6. v2: Rebase v3: Take RPM ref before reading (Imre) Signed-off-by: Damien Lespiau Reviewed-by: Rodrigo Vivi

Re: [Intel-gfx] [PATCH 12/14] drm/i915: Clean up eDP PLL state asserts

On Thu, Oct 29, 2015 at 09:26:01PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rewrite the eDP PLL state asserts to conform to our usual state assert > style. > > Signed-off-by: Ville Syrjälä Reviewed-by:

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/gen9: Check BIOS RC6 setup before enabling RC6

On Fri, Oct 30, 2015 at 05:00:49PM +0530, Sagar Arun Kamble wrote: > RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 > configuration registers. If those are not setup Driver should not enable RC6. > For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values > to

Re: [Intel-gfx] [PATCH] drm/i915: Allow unready gpu to be reset on gen8

Chris Wilson writes: > On Fri, Oct 30, 2015 at 05:18:18PM +0200, Mika Kuoppala wrote: >> Chris Wilson writes: >> >> > On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote: >> >> Gen9 has had demonstrated cases where forcing a not

Re: [Intel-gfx] [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

On Thu, Oct 29, 2015 at 11:21:28PM +0200, Ville Syrjälä wrote: > On Thu, Oct 29, 2015 at 05:57:57PM -0200, Paulo Zanoni wrote: > > 2015-10-29 17:25 GMT-02:00 : > > > From: Ville Syrjälä > > > > > > We get spurious PCH FIFO underruns

Re: [Intel-gfx] [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

On Fri, Oct 30, 2015 at 02:08:51PM +0200, Ville Syrjälä wrote: > On Fri, Oct 30, 2015 at 12:06:09PM +0200, Jani Nikula wrote: > > On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > We get spurious PCH FIFO underruns if we

Re: [Intel-gfx] [PATCH 10/14] drm/i915: s/DP_PLL_FREQ_160MHZ/DP_PLL_FREQ_162MHZ/

On Thu, Oct 29, 2015 at 09:25:59PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The DP link frequency is 162MHz, not 160MHz. Rename the ILK eDP PLL > defines to match. > > Signed-off-by: Ville Syrjälä ocd

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Share cdclk code for BDW and BXT

On Tue, Oct 27, 2015 at 04:31:56PM +0200, Ville Syrjälä wrote: > On Tue, Oct 27, 2015 at 03:43:03PM +0200, Jani Nikula wrote: > > On Tue, 27 Oct 2015, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > The difference betwen the BXT and BDW

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Use intel_dp->DP in eDP PLL setup

On Fri, Oct 30, 2015 at 05:00:42PM +0100, Daniel Vetter wrote: > On Thu, Oct 29, 2015 at 09:26:02PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs. > > > > To do this we need

[Intel-gfx] [PATCH 6/7] drm/i915: Add csr programming registers to dmc debugfs entry

We check these to determine firmware loading status. Include them to help to debug causes of firmware loading fails. v2: Move all CSR specific registers to i915_reg.h (Ville) v3: Rebase v4: Rebase (RPM ref) Signed-off-by: Mika Kuoppala Reviewed-by: Imre Deak

[Intel-gfx] [PATCH] tests/drv_hangman: Fix uninitialized tail usage

Tail needs to be in outer scope as it is used after loop continuation destroying its scope. Reported-by: Thomas Wood Cc: Thomas Wood Signed-off-by: Mika Kuoppala --- tests/drv_hangman.c | 2 +- 1 file changed, 1

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Use intel_dp->DP in eDP PLL setup

On Thu, Oct 29, 2015 at 09:26:02PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs. > > To do this we need to move DP_AUDIO_OUTPUT_ENABLE setup to happen later, > so that we don't

Re: [Intel-gfx] [PATCH 14/14] drm/i915: Configure eDP PLL freq from ironlake_edp_pll_on()

On Thu, Oct 29, 2015 at 09:26:03PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > ironlake_set_pll_cpu_edp() only gets called just before > ironlake_edp_pll_on(), so just pull the code into ironlake_edp_pll_on(). > > Also toss in a debug

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/gen9: Check BIOS RC6 setup before enabling RC6

On Fri, Oct 30, 2015 at 05:00:49PM +0530, Sagar Arun Kamble wrote: > RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 > configuration registers. If those are not setup Driver should not enable RC6. > For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values > to

Re: [Intel-gfx] [PATCH] drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)

On 10/30/2015 05:50 AM, Jani Nikula wrote: Reported-by: Keith Webb Suggested-by: Keith Webb Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106671 Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1

Re: [Intel-gfx] [PATCH] drm/i915: make A0 wa's applied to A1

On Mon, Oct 26, 2015 at 10:48:58AM +, tim.g...@intel.com wrote: > From: Tim Gore > > Since A1 chips use the same GPU as A0, they need all the > same wa's in the i915 driver. Update some conditionals > to do this. Neither summary nor commit message mentions that this is

[Intel-gfx] [Regression report] Weekly regression report WW44

WW44 Regression report. This week's regressions +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 92655

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

On Fri, Oct 30, 2015 at 05:14:21PM +0100, Daniel Vetter wrote: > On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote: > > When accessing through the GTT from one CPU whilst concurrently updating > > the GGTT PTEs in another thread, the hardware likes to return random > > data. As we have

[Intel-gfx] [PATCH v2 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

From: Ville Syrjälä We get spurious PCH FIFO underruns if we enable the reporting too soon after enabling the crtc. Move it to be the last step, after the encoder enable. Additionally we need an extra vblank wait, otherwise we still get the underruns. Presumably

[Intel-gfx] [PATCH v2 06/14] drm/i915: Check for FIFO underruns after modeset on IVB/HSW and CPT/PPT

From: Ville Syrjälä Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not always get an interrupt on a FIFO underrun. But we can always do an explicit check (like we do on GMCH platforms that have no underrun interrupt). v2: Drop stale kerneldoc for

[Intel-gfx] [drm-intel:drm-intel-nightly 4/8] drivers/gpu/drm/amd/amdgpu/dce_v10_0.c:3143:13: error: invalid storage class for function 'dce_v10_0_is_idle'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: fba7fdd3589b453770f28caa39064b6c0141e81a commit: b8a8f412df08b100bbb6845c50f73656d677d08a [4/8] Merge remote-tracking branch 'drm-upstream/drm-next' into drm-intel-nightly config: x86_64-randconfig-x007-10252017 (attached

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

On Fri, Oct 30, 2015 at 05:18:15PM +0100, Daniel Vetter wrote: > On Fri, Oct 23, 2015 at 10:17:44PM +0100, Dave Gordon wrote: > > On 08/10/15 21:50, Wayne Boyer wrote: > > >From: Chris Wilson > > > > > >A long time ago (before 3.14) we relied on a permanent pinning of

[Intel-gfx] [PATCH v2 05/14] drm/i915: Re-enable PCH FIO underrun reporting after pipe has been disabled

From: Ville Syrjälä Some hardware (IVB/HSW and CPT/PPT) have a shared error interrupt for all the relevant underrun bits, so in order to keep the error interrupt enabled, we need to have underrun reporting enabled on all PCH transocders. Currently we leave the

[Intel-gfx] [PATCH v2 08/14] drm/i915: Disable FIFO underrun reporting around IBX transcoder B workaround

From: Ville Syrjälä Doing the IBX transcoder B workaround causes underruns on pipe/transcoder A. Just hide them by disabling underrun reporting for pipe A around the workaround. It might be possible to avoid the underruns by moving the workaround to be applied

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Share cdclk code for BDW and BXT

On Fri, Oct 30, 2015 at 05:06:27PM +0100, Daniel Vetter wrote: > On Tue, Oct 27, 2015 at 04:31:56PM +0200, Ville Syrjälä wrote: > > On Tue, Oct 27, 2015 at 03:43:03PM +0200, Jani Nikula wrote: > > > On Tue, 27 Oct 2015, ville.syrj...@linux.intel.com wrote: > > > > From: Ville Syrjälä

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: Fix error handling in intelfb_create

On Sat, Oct 24, 2015 at 12:27:57AM +0200, Lukas Wunner wrote: > intelfb_create() is called once on driver initialization. It either > uses the fb inherited from BIOS or allocates a new one by calling > intelfb_alloc(). Afterwards, it calls two functions which can fail: > > -

Re: [Intel-gfx] [PATCH v6 3/4] drm/i915: Fix failure paths around initial fbdev allocation

On Tue, Jun 30, 2015 at 10:06:27AM +0100, Lukas Wunner wrote: > From: Tvrtko Ursulin > > We had two failure modes here: > > 1. > Deadlock in intelfb_alloc failure path where it calls > drm_framebuffer_remove, which grabs the struct mutex and intelfb_create > (caller of

Re: [Intel-gfx] [PATCH v6 2/4] drm/i915: Fix double unref in intelfb_alloc failure path

On Thu, Oct 22, 2015 at 01:37:18PM +0200, Lukas Wunner wrote: > In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails, > the bo is unrefed twice: By drm_framebuffer_remove() and once more by > drm_gem_object_unreference(). Fix it. > > Reported-by: Ville Syrjälä