Re: [Intel-gfx] [PATCH v3.1 08/16] drm/i915/gen9: Compute DDB allocation at atomic check time (v3)

I was facing the same issue that was reported by Lyude both on Arch Linux and ChromeOs. This patch did not help me while testing on a SKL RVP. The check for skip_intermediate_wm would not pass on gen9. sanitize_watermarks() would return immediately as dev_priv->display.optimize_watermarks is

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

Hi Dave, Ofc I promise just a few leftovers for drm-misc and somehow it's the biggest pull. But really mostly trivial stuff: - MAINTAINERS updates from Emil - rename async to nonblock in atomic_commit to avoid the confusion between nonblocking ioctl and async flip (= not vblank synced), from Maa

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Add lspcon core functions

Em Ter, 2016-05-03 às 21:44 +0530, Sharma, Shashank escreveu: > > On 5/3/2016 9:39 PM, Ville Syrjälä wrote: > > > > On Tue, May 03, 2016 at 09:18:49PM +0530, Sharma, Shashank wrote: > > > > > > Regards > > > Shashank > > > > > > On 5/2/2016 7:21 PM, Ville Syrjälä wrote: > > > > > > > > On Mon,

Re: [Intel-gfx] [PATCH i-g-t 00/17] tools/intel_bios_reader updates

Care to add this usage for it as well? Signed-off-by: Marius Vlad --- tools/intel_bios_reader.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c index de90f5d..4192919 100644 --- a/tools/intel_bios_reade

Re: [Intel-gfx] [PATCH 2/3] drm/fb_helper: Fix references to dev->mode_config.num_connector

On Wed, May 04, 2016 at 11:28:52AM -0400, Lyude wrote: > During boot, MST hotplugs are generally expected (even if no physical > hotplugging occurs) and result in DRM's connector topology changing. > This means that using num_connector from the current mode configuration > can lead to the number of

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

On Wed, May 04, 2016 at 03:51:21PM +0100, Peter Antoine wrote: > > Sorry Ville, > > What is SRM? MI_STORE_REGISTER_MEM > > Peter. > > On Wed, 4 May 2016, Ville Syrjälä wrote: > > > On Wed, May 04, 2016 at 02:23:35PM +, Antoine, Peter wrote: > >> No, It's not debug. > >> It's for syncing

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add missing condition for committing planes on crtc (rev3)

== Series Details == Series: drm/i915: add missing condition for committing planes on crtc (rev3) URL : https://patchwork.freedesktop.org/series/5467/ State : success == Summary == Series 5467v3 drm/i915: add missing condition for committing planes on crtc http://patchwork.freedesktop.org/api/

Re: [Intel-gfx] [PATCH 1/3] drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

On Wed, May 04, 2016 at 11:28:51AM -0400, Lyude wrote: > During boot time, MST devices usually send a ton of hotplug events > irregardless of whether or not any physical hotplugs actually occurred. > Hotplugs mean connectors being created/destroyed, and the number of DRM > connectors changing under

Re: [Intel-gfx] [PATCH 3/3] drm/fb_helper: Fix a few typos

On Wed, May 04, 2016 at 11:28:53AM -0400, Lyude wrote: > s/modest/modeset/ > s/aftert/after/ > > Signed-off-by: Lyude Applied to drm-misc, thanks. -Daniel > --- > drivers/gpu/drm/drm_fb_helper.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm

Re: [Intel-gfx] [PATCH] drm/i915: Report command parser version 0 if disabled

On ke, 2016-05-04 at 14:25 +0100, Chris Wilson wrote: > If the command parser is not active, then it is appropriate to report it > as operating at version 0 as no higher mode is supported. This greatly > simplifies userspace querying for the command parser as we then do not > need to second guess w

Re: [Intel-gfx] [PATCH i-g-t 04/17] tools/intel_bios_reader: add --devid parameter

On Wed, 04 May 2016, Marius Vlad wrote: > On Tue, May 03, 2016 at 05:18:54PM +0300, Jani Nikula wrote: >> Not sure it's a great idea to do platform specific parsing of the BIOS, >> but at least make it possible to pass in the devid on the command line >> and not just the environment. >> >> Signed

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Report command parser version 0 if disabled

== Series Details == Series: drm/i915: Report command parser version 0 if disabled URL : https://patchwork.freedesktop.org/series/6736/ State : failure == Summary == Series 6736v1 drm/i915: Report command parser version 0 if disabled http://patchwork.freedesktop.org/api/1.0/series/6736/revisio

[Intel-gfx] [PATCH 3/3] drm/fb_helper: Fix a few typos

s/modest/modeset/ s/aftert/after/ Signed-off-by: Lyude --- drivers/gpu/drm/drm_fb_helper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 15204c0..7778a0e 100644 --- a/drivers/gpu/drm/drm_fb_helper

[Intel-gfx] [PATCH 2/3] drm/fb_helper: Fix references to dev->mode_config.num_connector

During boot, MST hotplugs are generally expected (even if no physical hotplugging occurs) and result in DRM's connector topology changing. This means that using num_connector from the current mode configuration can lead to the number of connectors changing under us. This can lead to some nasty scen

[Intel-gfx] [PATCH 1/3] drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

During boot time, MST devices usually send a ton of hotplug events irregardless of whether or not any physical hotplugs actually occurred. Hotplugs mean connectors being created/destroyed, and the number of DRM connectors changing under us. This isn't a problem if we use fb_helper->connector_count

Re: [Intel-gfx] [PATCH igt 1/2] drmtest: don't discard return value in do_ioctl()

On Wed, May 04, 2016 at 04:15:24PM +0100, Robert Bragg wrote: > In preparation for testing DRM_IOCTL_I915_PERF_OPEN which returns a file > descriptor this allows us to get the return value of ioctl called by the > do_ioctl() utility. > > Signed-off-by: Robert Bragg > --- > lib/drmtest.h | 11 +++

Re: [Intel-gfx] [PATCH i-g-t 04/17] tools/intel_bios_reader: add --devid parameter

On Tue, May 03, 2016 at 05:18:54PM +0300, Jani Nikula wrote: > Not sure it's a great idea to do platform specific parsing of the BIOS, > but at least make it possible to pass in the devid on the command line > and not just the environment. > > Signed-off-by: Jani Nikula > --- > tools/intel_bios_

Re: [Intel-gfx] [PATCH] drm/i915: Bail out of pipe config compute loop on LPT

On Tue, May 03, 2016 at 11:29:21AM +0200, Maarten Lankhorst wrote: > Op 03-05-16 om 10:33 schreef Daniel Vetter: > > LPT is pch, so might run into the fdi bandwidth constraint (especially > > since it has only 2 lanes). But right now we just force pipe_bpp back > > to 24, resulting in a nice loop (

[Intel-gfx] [PATCH igt 1/2] drmtest: don't discard return value in do_ioctl()

In preparation for testing DRM_IOCTL_I915_PERF_OPEN which returns a file descriptor this allows us to get the return value of ioctl called by the do_ioctl() utility. Signed-off-by: Robert Bragg --- lib/drmtest.h | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/

[Intel-gfx] [PATCH igt 2/2] igt/perf: add i915 perf stream tests

Signed-off-by: Robert Bragg --- tests/Makefile.sources |1 + tests/perf.c | 2053 2 files changed, 2054 insertions(+) create mode 100644 tests/perf.c diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 9ea9b5b..529274

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Bail out of pipe config compute loop on LPT

On Tue, May 03, 2016 at 09:25:06AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Bail out of pipe config compute loop on LPT > URL : https://patchwork.freedesktop.org/series/6646/ > State : warning > > == Summary == > > Series 6646v1 drm/i915: Bail out of pipe config com

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

On Wed, May 04, 2016 at 05:38:41PM +0300, Ville Syrjälä wrote: > On Wed, May 04, 2016 at 02:23:35PM +, Antoine, Peter wrote: > > No, It's not debug. > > It's for syncing and aligning (and validating) the open-source userspace > > with the kernel cache policy. > > Why doesn't userspace just us

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

Sorry Ville, What is SRM? Peter. On Wed, 4 May 2016, Ville Syrjälä wrote: On Wed, May 04, 2016 at 02:23:35PM +, Antoine, Peter wrote: No, It's not debug. It's for syncing and aligning (and validating) the open-source userspace with the kernel cache policy. Why doesn't userspace just

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

No, It's not debug. It's for syncing and aligning (and validating) the open-source userspace with the kernel cache policy. As for the name being wrong, I'll change that. As for the sysfs, would you prefer the following structure: mocs/size mocs/control_state mocs/l3cc_state for the different t

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

On Wed, May 04, 2016 at 02:23:35PM +, Antoine, Peter wrote: > No, It's not debug. > It's for syncing and aligning (and validating) the open-source userspace with > the kernel cache policy. Why doesn't userspace just use SRM to read registers? The spec gives me the impression that SRM doesn't

Re: [Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

On Wed, May 04, 2016 at 02:40:34PM +0100, Lionel Landwerlin wrote: > We are currently missing the color management update condition to > commit planes on crtc. > > v2: add comment about moving the commit of color management registers > to an async worker > > v3: Commit color management regist

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/sysfs: Adding mocs_state

== Series Details == Series: drm/i915/sysfs: Adding mocs_state URL : https://patchwork.freedesktop.org/series/6735/ State : failure == Summary == Series 6735v1 drm/i915/sysfs: Adding mocs_state http://patchwork.freedesktop.org/api/1.0/series/6735/revisions/1/mbox/ Test drv_hangman: Su

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 04, 2016 at 02:24:14PM +0100, Robert Bragg wrote: > On Wed, May 4, 2016 at 1:24 PM, Daniel Vetter wrote: > > > On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote: > > > On Wed, May 4, 2016 at 10:09 AM, Martin Peres < > > martin.pe...@linux.intel.com> > > > wrote: > > > > > >

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

Reviewed-by: Shashank Sharma Regards Shashank On 5/4/2016 5:15 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 p

Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL. (v2)

On 20/04/16 13:38, Daniel Vetter wrote: On Wed, Apr 20, 2016 at 09:00:09AM +0200, Maarten Lankhorst wrote: Op 19-04-16 om 12:13 schreef Lionel Landwerlin: On 19/04/16 07:02, Maarten Lankhorst wrote: Op 18-04-16 om 18:47 schreef Bob Paauwe: The i915 driver is now using atomic properties and at

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

On 5/4/2016 5:19 PM, Ville Syrjälä wrote: On Wed, May 04, 2016 at 03:43:30PM +0530, Sharma, Shashank wrote: On 5/3/2016 12:38 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä To save a bit of power, let's try to turn off the TMDS output buffers in DP++ adaptors when we're not d

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

On Wed, May 04, 2016 at 02:32:53PM +0100, Peter Antoine wrote: > Will wait for more comments, then will respin with a different > commit message. Is the rest of the patch ok? No, you've put debug information into sysfs. (Also sysfs is one value per file.) sysfs does not match your goal of validati

[Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

We are currently missing the color management update condition to commit planes on crtc. v2: add comment about moving the commit of color management registers to an async worker v3: Commit color management register right after vblank Fixes: 20a34e78f0d7 (drm/i915: Update color management dur

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 4, 2016 at 2:24 PM, Robert Bragg wrote: > > > On Wed, May 4, 2016 at 1:24 PM, Daniel Vetter wrote: > >> On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote: >> > On Wed, May 4, 2016 at 10:09 AM, Martin Peres < >> martin.pe...@linux.intel.com> >> > wrote: >> > >> > > On 03/05

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

Will wait for more comments, then will respin with a different commit message. Is the rest of the patch ok? Peter. On Wed, 4 May 2016, Chris Wilson wrote: On Wed, May 04, 2016 at 02:16:23PM +0100, Peter Antoine wrote: The following patch adds the current MOCS state to the sysfs file system.

Re: [Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

On Wed, May 04, 2016 at 11:25:12AM +0100, Lionel Landwerlin wrote: > On 21/04/16 14:57, Ville Syrjälä wrote: > > On Thu, Apr 21, 2016 at 03:30:09PM +0200, Maarten Lankhorst wrote: > >> Hey, > >> > >> Op 18-04-16 om 13:05 schreef Lionel Landwerlin: > >>> Ping? > >>> > >> Will commit, but looks like

[Intel-gfx] [PATCH] drm/i915: Report command parser version 0 if disabled

If the command parser is not active, then it is appropriate to report it as operating at version 0 as no higher mode is supported. This greatly simplifies userspace querying for the command parser as we then do not need to second guess when it will be active (a mixture of module parameters and gene

Re: [Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

Op 04-05-16 om 12:25 schreef Lionel Landwerlin: > On 21/04/16 14:57, Ville Syrjälä wrote: >> On Thu, Apr 21, 2016 at 03:30:09PM +0200, Maarten Lankhorst wrote: >>> Hey, >>> >>> Op 18-04-16 om 13:05 schreef Lionel Landwerlin: Ping? >>> Will commit, but looks like Ville made a comment about

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 4, 2016 at 1:24 PM, Daniel Vetter wrote: > On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote: > > On Wed, May 4, 2016 at 10:09 AM, Martin Peres < > martin.pe...@linux.intel.com> > > wrote: > > > > > On 03/05/16 23:03, Robert Bragg wrote: > > > > > >> > > >> > > >> On Tue, M

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

On Wed, May 04, 2016 at 02:16:23PM +0100, Peter Antoine wrote: > The following patch adds the current MOCS state to the sysfs file > system. This patch has been added so that userspace can validate the > MOCS settings that have been programmed. These only correspond to the state the kernel may pro

[Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

The following patch adds the current MOCS state to the sysfs file system. This patch has been added so that userspace can validate the MOCS settings that have been programmed. Tracked-On: https://jira01.devtools.intel.com/browse/VIZ-7767 Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915

Re: [Intel-gfx] [PATCH] drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked

On Wed, May 4, 2016 at 8:29 AM, Daniel Vetter wrote: > Embarrassingly while fixing up the old paths for i915 I managed to > misplace a locking check for the new _unlocked paths. That's what I > get for not retesting on radeon. > > Fixes: 9f0ba539d13a ("drm/gem: support BO freeing without dev->stru

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked

== Series Details == Series: drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked URL : https://patchwork.freedesktop.org/series/6731/ State : failure == Summary == Series 6731v1 drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked http://patchwork.freedesktop.org/a

[Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impo

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add a FIXME about crtc !active vs. watermarks

Op 29-04-16 om 16:31 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > When the crtc is enabled but !active, we should still compute the > watermarks as if the planes were visible. That would make it more > likely that the we can later transition to active without errors. > > Add a

[Intel-gfx] [PATCH] drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked

Embarrassingly while fixing up the old paths for i915 I managed to misplace a locking check for the new _unlocked paths. That's what I get for not retesting on radeon. Fixes: 9f0ba539d13a ("drm/gem: support BO freeing without dev->struct_mutex") Cc: Chris Wilson Cc: Alex Deucher Cc: Lucas Stach

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote: > On Wed, May 4, 2016 at 10:09 AM, Martin Peres > wrote: > > > On 03/05/16 23:03, Robert Bragg wrote: > > > >> > >> > >> On Tue, May 3, 2016 at 8:34 PM, Robert Bragg >> > wrote: > >> > >> Sorry for the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: add missing condition for committing planes on crtc (rev2)

== Series Details == Series: drm/i915: add missing condition for committing planes on crtc (rev2) URL : https://patchwork.freedesktop.org/series/5467/ State : failure == Summary == Series 5467v2 drm/i915: add missing condition for committing planes on crtc http://patchwork.freedesktop.org/api/

[Intel-gfx] [PATCH i-g-t] tests/kms: Add test for testing rmfb framebuffer removal handling.

Add some tests to BAT to ensure rmfb/lastclose handling doesn't break again. The test will set framebuffers on each crtc, and then try rmfb or close. Afterwards it rechecks to make sure the framebuffers are removed. Signed-off-by: Maarten Lankhorst --- diff --git a/tests/Makefile.sources b/tests

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Move SKL hw stride calculation into a helper

Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Remove intel_clock_t typedef

== Series Details == Series: series starting with [1/3] drm/i915: Remove intel_clock_t typedef URL : https://patchwork.freedesktop.org/series/6718/ State : failure == Summary == Series 6718v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/6718/revisions/1/mbox/ Te

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

On Wed, May 04, 2016 at 03:43:30PM +0530, Sharma, Shashank wrote: > > On 5/3/2016 12:38 AM, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > To save a bit of power, let's try to turn off the TMDS output buffers > > in DP++ adaptors when we're not driving the port. > > > > v2:

[Intel-gfx] [PATCH v3 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

From: Ville Syrjälä DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 pin, but we have no way to do that. So as a last resort, check the VBT to see if the HDMI port is in fact a d

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Fix gen8 semaphores id for legacy mode

On Wed, May 04, 2016 at 12:35:09PM +0100, Dave Gordon wrote: >On 29/04/2016 09:49, Chris Wilson wrote: > > On Fri, Apr 29, 2016 at 09:36:37AM +0100, Tvrtko Ursulin wrote: > > On 28/04/16 17:24, Chris Wilson wrote: > > With the introduction of a distinct engine->id vs the hardware id, we n

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Fix gen8 semaphores id for legacy mode

On 29/04/2016 09:49, Chris Wilson wrote: On Fri, Apr 29, 2016 at 09:36:37AM +0100, Tvrtko Ursulin wrote: On 28/04/16 17:24, Chris Wilson wrote: With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

On Wed, May 04, 2016 at 03:54:41PM +0530, Sharma, Shashank wrote: > > > On 5/3/2016 12:38 AM, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > DP dual mode type 1 DVI adaptors aren't required to implement any > > registers, so it's a bit hard to detect them. The best way woul

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 4, 2016 at 10:04 AM, Martin Peres wrote: > On 03/05/16 22:34, Robert Bragg wrote: > >> Sorry for the delay replying to this, I missed it. >> > > No worries! > > >> On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres > > wrote: >> >> On 20/04/16 17:23, Rober

[Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

We are currently missing the color management update condition to commit planes on crtc. v2: add comment about moving the commit of color management registers to an async worker Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.) Cc: Maarten Lankhorst Cc: Jani Niku

Re: [Intel-gfx] [PATCH 19/35] drm/imx: Use lockless gem BO free callback

Am Mittwoch, den 04.05.2016, 12:28 +0200 schrieb Daniel Vetter: > On Wed, Apr 27, 2016 at 02:01:35PM +0200, Philipp Zabel wrote: > > Am Mittwoch, den 27.04.2016, 13:21 +0200 schrieb Daniel Vetter: > > > On Wed, Apr 27, 2016 at 12:29:34PM +0200, Philipp Zabel wrote: > > > > Am Dienstag, den 26.04.20

Re: [Intel-gfx] [PATCH 19/35] drm/imx: Use lockless gem BO free callback

On Wed, Apr 27, 2016 at 02:01:35PM +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.04.2016, 13:21 +0200 schrieb Daniel Vetter: > > On Wed, Apr 27, 2016 at 12:29:34PM +0200, Philipp Zabel wrote: > > > Am Dienstag, den 26.04.2016, 19:29 +0200 schrieb Daniel Vetter: > > > > No dev->struct_mutex anyw

Re: [Intel-gfx] [PATCH] drm/gem: support BO freeing without dev->struct_mutex

On Tue, May 03, 2016 at 11:59:19AM -0400, Alex Deucher wrote: > On Mon, May 2, 2016 at 4:40 AM, Daniel Vetter wrote: > > Finally all the core gem and a lot of drivers are entirely free of > > dev->struct_mutex depencies, and we can start to have an entirely > > lockless unref path. > > > > To make

Re: [Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

On 21/04/16 14:57, Ville Syrjälä wrote: On Thu, Apr 21, 2016 at 03:30:09PM +0200, Maarten Lankhorst wrote: Hey, Op 18-04-16 om 13:05 schreef Lionel Landwerlin: Ping? Will commit, but looks like Ville made a comment about double buffering. Everything in intel_pipe_update_start depends on dou

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

On 5/3/2016 12:38 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 pin, but we have no way to do that. So as a la

Re: [Intel-gfx] [PATCH 2/3] drm: Add DP port types from DP 1.3 specification

On Tue, 2016-05-03 at 10:35 -0400, Ilia Mirkin wrote: > > On May 3, 2016 9:49 AM, "Mika Kahola" wrote: > > > > DP specification 1.3 defines DP downstream ports for > > DP++ and wireless devices. Let's add these to port > > definitions. > > > > Signed-off-by: Mika Kahola > > --- > > include/drm/

Re: [Intel-gfx] [REGRESSION] Occasional Flickering with Linux 4.6.0-rc* on Scree connected to eDP

Hi, probably a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=95124 Sorry for the noise. Best regards Arnd Am 04.05.2016 um 11:45 schrieb Arnd Hannemann: > Hi, > > with 4.6.0-rc4 and -rc6 kernel I experience occasional (every 1-2 Minutes) > on my laptop (thinkpad t440s) screen. > Th

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: remove i915_gem_object_ggtt_unbind

On ti, 2016-05-03 at 17:00 +0100, Matthew Auld wrote: > > > > Test drv_module_reload_basic: > > pass   -> INCOMPLETE (skl-nuci5) > Machine seems to have hanged after reloading module, couldn't possibly > be related to this patch. Will create new bug report... > > > > > Test g

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

On 5/3/2016 12:38 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä To save a bit of power, let's try to turn off the TMDS output buffers in DP++ adaptors when we're not driving the port. v2: Let's not forget DDI, toss in a debug message while at it v3: Just do the TMDS output cont

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Respect DP++ adaptor TMDS clock limit

Reviewed-by: Shashank Sharma Regards Shashank On 5/3/2016 12:38 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Try to detect the max TMDS clock limit for the DP++ adaptor (if any) and take it into account when checking the port clock. Note that as with the sink (HDMI vs. DVI) T

Re: [Intel-gfx] [REGRESSION] Occasional Flickering with Linux 4.6.0-rc* on Scree connected to eDP

On Wed, 04 May 2016, Arnd Hannemann wrote: > Hi, > > with 4.6.0-rc4 and -rc6 kernel I experience occasional (every 1-2 Minutes) > on my laptop (thinkpad t440s) screen. > This flickering has not been there in 4.5. > Unfortunately the laptop does not boot with 4.6-rc1. > > The laptop screen is conne

[Intel-gfx] [REGRESSION] Occasional Flickering with Linux 4.6.0-rc* on Scree connected to eDP

Hi, with 4.6.0-rc4 and -rc6 kernel I experience occasional (every 1-2 Minutes) on my laptop (thinkpad t440s) screen. This flickering has not been there in 4.5. Unfortunately the laptop does not boot with 4.6-rc1. The laptop screen is connected via eDP. I have two other monitors connected to the

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 4, 2016 at 10:09 AM, Martin Peres wrote: > On 03/05/16 23:03, Robert Bragg wrote: > >> >> >> On Tue, May 3, 2016 at 8:34 PM, Robert Bragg > > wrote: >> >> Sorry for the delay replying to this, I missed it. >> >> On Sat, Apr 23, 2016 at 11:34 AM, Ma

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove intel_clock_t typedef

On Wed, May 04, 2016 at 12:11:57PM +0300, Ander Conselvan de Oliveira wrote: > Just use "struct dpll" everywhere. That's actually shorter than > intel_clock_t. I'm thinking we should probably have an intel_ prefix on the thing. > > Signed-off-by: Ander Conselvan de Oliveira > > --- > drivers/

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove intel_limit_t typedef

On Wed, 04 May 2016, Ander Conselvan de Oliveira wrote: > The coding style documentation says the following about typedefs: > > "In general, a pointer, or a struct that has elements that can > reasonably be directly accessed should _never_ be a typedef." > > intel_limit_t falls in that category,

[Intel-gfx] [PATCH 3/3] drm/i915: Remove intel_limit_t typedef

The coding style documentation says the following about typedefs: "In general, a pointer, or a struct that has elements that can reasonably be directly accessed should _never_ be a typedef." intel_limit_t falls in that category, so just use "struct intel_limit" instead. Signed-off-by: Ander Cons

[Intel-gfx] [PATCH 2/3] drm/i915: Remove intel_range_t and intel_p2_t typedefs

Those are only used for defining struct intel_limit, so use anonymous structs instead. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.

[Intel-gfx] [PATCH 1/3] drm/i915: Remove intel_clock_t typedef

Just use "struct dpll" everywhere. That's actually shorter than intel_clock_t. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 62 +-- drivers/gpu/drm/i915/intel_dpll_mgr.c | 2

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On 03/05/16 23:03, Robert Bragg wrote: On Tue, May 3, 2016 at 8:34 PM, Robert Bragg mailto:rob...@sixbynine.org>> wrote: Sorry for the delay replying to this, I missed it. On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres mailto:martin.pe...@free.fr>> wrote: On 20/04/16 17:23, R

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On 03/05/16 22:34, Robert Bragg wrote: Sorry for the delay replying to this, I missed it. No worries! On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres mailto:martin.pe...@free.fr>> wrote: On 20/04/16 17:23, Robert Bragg wrote: Gen graphics hardware can be set up to periodically w

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

On 03/05/16 20:22, Dave Gordon wrote: On 29/04/16 16:08, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal det

Re: [Intel-gfx] [PATCH] [drm-intel-fixes] drm/i915: do not enable RC6p on Sandy Bridge

reconnect ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly

On Mon, 02 May 2016, Daniel Vetter wrote: > On Fri, Apr 29, 2016 at 11:31:44AM +0200, Linus Walleij wrote: > > On Fri, Apr 22, 2016 at 9:38 PM, wrote: > > > > > From: Ville Syrjälä > > > > > > GPIO lookup tables are supposed to be zero terminated. Let's do that > > > and avoid accidentally wal