Re: [Intel-gfx] [PATCH] drm/i915/guc: Move GuC wq_reserve_space to ring_reserve_space

On Tue, Dec 08, 2015 at 05:04:50PM -0800, yu@intel.com wrote: > From: Alex Dai > > Split GuC work queue space reserve and submission and move the space > reserve to where ring space is reserved. The reason is that failure > in intel_logical_ring_advance_and_submit won't be

[Intel-gfx] [PATCH] drm/i915: dual link pipe selection for bxt

Pipe is assigned based on the port, but it should be based on current crtc. Correcting the same in this patch. v2: Use macro BXT_PIPE_SELECT(pipe) (Daniel) Signed-off-by: Deepak M --- drivers/gpu/drm/i915/i915_reg.h | 4 +--- drivers/gpu/drm/i915/intel_dsi.c | 15

Re: [Intel-gfx] [BXT MIPI PATCH 2/2] drm/i915: dual link pipe selection for bxt

> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Wednesday, December 9, 2015 1:50 PM > To: Deepak, M > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [BXT MIPI PATCH 2/2] drm/i915: dual

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

On Wed, Dec 09, 2015 at 11:41:31AM +0100, Daniel Vetter wrote: > Every time I type or review docs this seems a bit different. Try to > document the common style so we can try to unify at least new docs. > > v2: Spelling fixes from Pierre, Laurent and Jani. > > Cc: Pierre Moreau

Re: [Intel-gfx] [BXT MIPI PATCH 2/2] drm/i915: dual link pipe selection for bxt

On Wed, Dec 09, 2015 at 05:29:58PM +0530, Deepak M wrote: > Pipe is assigned based on the port, but it should be > based on current crtc. Correcting the same in this patch. > > Signed-off-by: Deepak M > --- > drivers/gpu/drm/i915/intel_dsi.c | 23 ++- > 1

Re: [Intel-gfx] [PATCH v7] drm/i915: Add soft-pinning API for execbuffer

On 08/12/15 18:49, Michel Thierry wrote: On 12/8/2015 11:55 AM, Thomas Daniel wrote: From: Chris Wilson Userspace can pass in an offset that it presumes the object is located at. The kernel will then do its utmost to fit the object into that location. The assumption

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Give encoders useful names

On Tue, 08 Dec 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rather than let the core generate usless encoder names, let's pass in > something that actually identifies the piece of hardware we're dealing > with. > > Signed-off-by: Ville

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

On 08/12/15 12:16, Tvrtko Ursulin wrote: On 08/12/15 11:57, Michel Thierry wrote: From: Vinay Belgaumkar These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple

Re: [Intel-gfx] [PATCH v2 01/14] drm: Pass 'name' to drm_crtc_init_with_planes()

On Tue, 08 Dec 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Done with coccinelle for the most part. However, it thinks '...' is > part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder > in its place and got rid of it with sed

Re: [Intel-gfx] [PATCH v4 00/14] drm: Give crtcs and planes actual names (v4)

On Tue, 08 Dec 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I've done some more modeset log staring recently and again got > fed up with the noise. So here's another attempt at making the > logs make some sense. > > This time I pass a printf

Re: [Intel-gfx] [PATCH] drm/i915: Suspend resume timing optimization.

On 12/08/2015 02:22 AM, Paulo Zanoni wrote: 2015-12-07 18:28 GMT-02:00 : From: Abhay Kumar Moving 250ms from T12 timing to suspend path so that resume path will be faster. Can you please elaborate more on your motivation for this patch? I'm a

Re: [Intel-gfx] [PATCH 04/14] drm: Use driver specified encoder name

On Wed, Dec 09, 2015 at 08:32:45AM +0100, Daniel Vetter wrote: > On Tue, Dec 08, 2015 at 06:41:52PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Use the encoder name passed by the driver if non-NULL, otherwise fall > > back to the old

Re: [Intel-gfx] [PATCH v2 01/14] drm: Pass 'name' to drm_crtc_init_with_planes()

On Wed, Dec 09, 2015 at 10:21:25AM +0200, Jani Nikula wrote: > On Tue, 08 Dec 2015, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Done with coccinelle for the most part. However, it thinks '...' is > > part of the semantic patch, so I put an

[Intel-gfx] [PATCH 1/6] drm/i915: Clearing buffer objects via CPU/GTT

From: Ankitprasad Sharma This patch adds support for clearing buffer objects via CPU/GTT. This is particularly useful for clearing out the non shmem backed objects. Currently intend to use this only for buffers allocated from stolen region. v2: Added kernel doc

[Intel-gfx] [PATCH 4/6] drm/i915: Add support for stealing purgable stolen pages

From: Chris Wilson If we run out of stolen memory when trying to allocate an object, see if we can reap enough purgeable objects to free up enough contiguous free space for the allocation. This is in principle very much like evicting objects to free up enough contiguous space in the vma when

[Intel-gfx] [PATCH 3/6] drm/i915: Propagating correct error codes to the userspace

From: Ankitprasad Sharma Propagating correct error codes to userspace by using ERR_PTR and PTR_ERR macros for stolen memory based object allocation. We generally return -ENOMEM to the user whenever there is a failure in object allocation. This patch helps user to

[Intel-gfx] [PATCH 2/6] drm/i915: Support for creating Stolen memory backed objects

From: Ankitprasad Sharma Extend the drm_i915_gem_create structure to add support for creating Stolen memory backed objects. Added a new flag through which user can specify the preference to allocate the object from stolen memory, which if set, an attempt will be

[Intel-gfx] [PATCH 6/6] drm/i915: Migrate stolen objects before hibernation

From: Chris Wilson Ville reminded us that stolen memory is not preserved across hibernation, and a result of this was that context objects now being allocated from stolen were being corrupted on S4 and promptly hanging the GPU on resume. We want to utilise stolen for

[Intel-gfx] [PATCH v10 0/6] Support for creating/using Stolen memory backed objects

From: Ankitprasad Sharma This patch series adds support for creating/using Stolen memory backed objects. Despite being a unified memory architecture (UMA) some bits of memory are more equal than others. In particular we have the thorny issue of stolen memory,

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

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 backed by stolen memory as well as other non-shmem backed objects.

Re: [Intel-gfx] [PATCH RESEND 2/3] drm/i915: check for return value

zed > > encoder. > > > > Cc: Daniel Vetter <daniel.vet...@intel.com> > > Cc: Jani Nikula <jani.nik...@linux.intel.com> > > Signed-off-by: Sudip Mukherjee <su...@vectorindia.org> > > Queued for -next, thanks for the patch. > -Daniel Hi Daniel, It

[Intel-gfx] [PATCH] drm/i915: Wait for PP cycle delay only if panel is in power off sequence

During resume, while turning the EDP panel power on, we need not wait blindly for panel_power_cycle_delay. Check if panel power down sequence in progress and then only wait. This improves our resume time significantly. Signed-off-by: Shobhit Kumar ---

Re: [Intel-gfx] [PATCH RESEND 2/3] drm/i915: check for return value

<su...@vectorindia.org> > > > > Queued for -next, thanks for the patch. > > -Daniel > > Hi Daniel, > It is still not there in linux-next. Still applies cleanly on > next-20151209. Sorry, this must have fallen through the cracks somehow. Applied now for real. T

Re: [Intel-gfx] [PATCH v7] drm/i915: Add soft-pinning API for execbuffer

On 12/9/2015 12:34 PM, Tvrtko Ursulin wrote: On 09/12/15 10:51, Chris Wilson wrote: On Wed, Dec 09, 2015 at 10:30:41AM +, Tvrtko Ursulin wrote: On 08/12/15 18:49, Michel Thierry wrote: On 12/8/2015 11:55 AM, Thomas Daniel wrote: From: Chris Wilson Userspace

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Fix DMC load on Kabylake.

On Wed, 09 Dec 2015, Rodrigo Vivi wrote: > Kabylake A0 is based on Skylake H0. > > v2: Don't assume revid+7 and only load the one we are sure about. > > v3: Rebase on top of latest changes. > > Cc: Imre Deak > Signed-off-by: Rodrigo Vivi

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Clearing buffer objects via CPU/GTT

Hi, On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma This patch adds support for clearing buffer objects via CPU/GTT. This is particularly useful for clearing out the non shmem backed objects. Currently intend to use this only

Re: [Intel-gfx] [PATCH v7] drm/i915: Add soft-pinning API for execbuffer

On Wed, Dec 09, 2015 at 10:30:41AM +, Tvrtko Ursulin wrote: > > On 08/12/15 18:49, Michel Thierry wrote: > >On 12/8/2015 11:55 AM, Thomas Daniel wrote: > >>From: Chris Wilson > >> > >>Userspace can pass in an offset that it presumes the object is located > >>at. The

[Intel-gfx] [PATCH] RFC: drm/i915: Take runtime pm wakelock during hangcheck

During hangcheck we access the hardware registers, for which we must hold a runtime pm reference. Hangcheck also should only be running whilst the GPU is active, and we hold a runtime pm whilst the GPU is busy. Therefore, if the runtime pm is suspended (no wakelocks held anywhere) we know the GPU

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

On Wednesday 09 December 2015 13:21:09 Jani Nikula wrote: > On Wed, 09 Dec 2015, Daniel Vetter wrote: > > Every time I type or review docs this seems a bit different. Try to > > document the common style so we can try to unify at least new docs. > > > > v2: Spelling fixes

Re: [Intel-gfx] [PATCH v7] drm/i915: Add soft-pinning API for execbuffer

On 09/12/15 10:51, Chris Wilson wrote: On Wed, Dec 09, 2015 at 10:30:41AM +, Tvrtko Ursulin wrote: On 08/12/15 18:49, Michel Thierry wrote: On 12/8/2015 11:55 AM, Thomas Daniel wrote: From: Chris Wilson Userspace can pass in an offset that it presumes the

Re: [Intel-gfx] [PATCH v7] drm/i915: Add soft-pinning API for execbuffer

On 09/12/15 13:33, Michel Thierry wrote: On 12/9/2015 12:34 PM, Tvrtko Ursulin wrote: On 09/12/15 10:51, Chris Wilson wrote: On Wed, Dec 09, 2015 at 10:30:41AM +, Tvrtko Ursulin wrote: On 08/12/15 18:49, Michel Thierry wrote: On 12/8/2015 11:55 AM, Thomas Daniel wrote: From: Chris

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

On Wed, Dec 09, 2015 at 01:21:09PM +0200, Jani Nikula wrote: > On Wed, 09 Dec 2015, Daniel Vetter wrote: > > Every time I type or review docs this seems a bit different. Try to > > document the common style so we can try to unify at least new docs. > > > > v2: Spelling

Re: [Intel-gfx] [PATCH] drm/i915: Suspend resume timing optimization.

On 12/09/2015 05:42 PM, Ville Syrjälä wrote: On Wed, Dec 09, 2015 at 04:25:41PM +0530, Kumar, Shobhit wrote: On 12/08/2015 02:22 AM, Paulo Zanoni wrote: 2015-12-07 18:28 GMT-02:00 : From: Abhay Kumar Moving 250ms from T12 timing to suspend path

Re: [Intel-gfx] [PATCH] drm/i915: Wait for PP cycle delay only if panel is in power off sequence

On 12/09/2015 06:51 PM, Shobhit Kumar wrote: During resume, while turning the EDP panel power on, we need not wait blindly for panel_power_cycle_delay. Check if panel power down sequence in progress and then only wait. This improves our resume time significantly. With this in case of actual

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

On Wed, 09 Dec 2015, Daniel Vetter wrote: > Every time I type or review docs this seems a bit different. Try to > document the common style so we can try to unify at least new docs. > > v2: Spelling fixes from Pierre, Laurent and Jani. Nah, you ignored my comment about

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Clearing buffer objects via CPU/GTT

On Wed, Dec 09, 2015 at 06:16:17PM +0530, ankitprasad.r.sha...@intel.com wrote: > From: Ankitprasad Sharma > > This patch adds support for clearing buffer objects via CPU/GTT. This > is particularly useful for clearing out the non shmem backed objects. > Currently

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Clearing buffer objects via CPU/GTT

On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma This patch adds support for clearing buffer objects via CPU/GTT. This is particularly useful for clearing out the non shmem backed objects. Currently intend to use this only for

Re: [Intel-gfx] [PATCH] drm/i915: Wait for PP cycle delay only if panel is in power off sequence

On Wed, Dec 09, 2015 at 06:51:48PM +0530, Shobhit Kumar wrote: > During resume, while turning the EDP panel power on, we need not wait > blindly for panel_power_cycle_delay. Check if panel power down sequence > in progress and then only wait. This improves our resume time significantly. > >

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

On Wed, 09 Dec 2015, Laurent Pinchart wrote: > On Wednesday 09 December 2015 13:21:09 Jani Nikula wrote: >> On Wed, 09 Dec 2015, Daniel Vetter wrote: >> > Every time I type or review docs this seems a bit different. Try to >> > document

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

On Wednesday 09 December 2015 16:17:47 Jani Nikula wrote: > On Wed, 09 Dec 2015, Laurent Pinchart wrote: > > On Wednesday 09 December 2015 13:21:09 Jani Nikula wrote: > >> On Wed, 09 Dec 2015, Daniel Vetter wrote: > >> > Every time I

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Introduce intel_uncore_unclaimed_access

On Wed, Dec 09, 2015 at 05:01:39PM +0200, Mika Kuoppala wrote: > Currently interrupt code is the only place checking > for the unclaimed register access prior to actual register > macros using the same functionality. Rename the function > and make it return bool so that the possible error message

Re: [Intel-gfx] [BXT MIPI PATCH 1/2] drm/i915: Set the Z inversion overlap field for BXT

On Wed, Dec 09, 2015 at 05:29:57PM +0530, Deepak M wrote: > For broxton dual link Z-inversion overlap field is present > in MIPI_CTRL register unlike the other platforms, hence > setting the same in this patch. > > Signed-off-by: Deepak M > --- >

Re: [Intel-gfx] [PATCH] drm/i915: Add DPI FIFO empty status check

On Wed, Dec 09, 2015 at 05:05:52PM +0530, Deepak M wrote: > From: Gaurav K Singh > > Before sending TURN ON packet,check the DPI > FIFO empty status. > > v2: Change in commit message > Checking for FIFO empty only during TURN ON packet. > v3: Adding a new function

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Detect and clear unclaimed access on resume

On Wed, Dec 09, 2015 at 05:01:40PM +0200, Mika Kuoppala wrote: > If something, the usual suspect being bios, access hw > behind our back, dont let it slide into situation where > normal register access will detect this and spit out > a warn on into dmesg. On some bdw bioses this happens > during

[Intel-gfx] [PATCH 3/4] drm/i915: Detect and clear unclaimed access on resume

If something, the usual suspect being bios, access hw behind our back, dont let it slide into situation where normal register access will detect this and spit out a warn on into dmesg. On some bdw bioses this happens during igt/bat run always and as there is not much we can do about it, its better

[Intel-gfx] [PATCH v9 20/25] drm/i915: BDW: Pipe level Gamma correction

From: Shashank Sharma BDW/SKL/BXT platforms support various Gamma correction modes which are: 1. Legacy 8-bit mode 2. 10-bit mode 3. Split mode 4. 12-bit mode This patch does the following: 1. Adds the core function to program Gamma correction values for

Re: [Intel-gfx] [PATCH] drm: Documentation style guide

Hi, I wouldn't normally nitpick like this but since I was reading it anyway and you were asking for "OCD doc style thing". :-) This is a proofread of the force-pushed v2 in drm-intel-nightly (9a8730ddfe1d). > + > +Style Guidelines > + > + For consistency this documentation use

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Give encoders useful names

On Wed, 09 Dec 2015, Ville Syrjälä wrote: > On Wed, Dec 09, 2015 at 10:35:24AM +0200, Jani Nikula wrote: >> On Tue, 08 Dec 2015, ville.syrj...@linux.intel.com wrote: >> > From: Ville Syrjälä >> > >> > Rather than let the core generate

[Intel-gfx] [PATCH v3 02/14] drm: Pass 'name' to drm_universal_plane_init()

From: Ville Syrjälä Done with coccinelle for the most part. It choked on msm/mdp/mdp5/mdp5_plane.c like so: "BAD:! enum drm_plane_type type;" No idea how to deal with that, so I just fixed that up by hand. Also it thinks '...' is part of the semantic patch,

[Intel-gfx] [PATCH v3 01/14] drm: Pass 'name' to drm_crtc_init_with_planes()

From: Ville Syrjälä Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. I didn't convert drm_crtc_init() since passing the

[Intel-gfx] [PATCH 1/4] drm/i915: Consolidate unclaimed reg detection

Access the unclaimed reg detection register through one helper which also does cleanup. Note that we now access the register only if the platform has the actual non claimed access bit. This prevents needlessly reading the register with older gens when debug_mmio > 0. Cc: Chris Wilson

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Detect and clear unclaimed access on resume

On Wed, Dec 09, 2015 at 05:13:27PM +0200, Mika Kuoppala wrote: > If something, the usual suspect being bios, access hw > behind our back, dont let it slide into situation where > normal register access will detect this and spit out > a warn on into dmesg. On some bdw bioses this happens > during

Re: [Intel-gfx] [PATCH] drm/i915: Cancel hangcheck before GPU is suspended

On ke, 2015-12-09 at 15:56 +0200, Joonas Lahtinen wrote: > In order to avoid accessing GPU registers while GPU is suspended > cancel > the hangcheck work before calling intel_suspend_complete which > actually > puts the GPU to suspend. Otherwise hangcheck might do MMIO reads to a > suspended GPU.

[Intel-gfx] [PATCH 4/4] drm/i915: Check unclaimed access per forcewake domain get/put

We do unclaimed register access check in non mmio_debug mode once per write. This adds probability of finding the exact sequence where we did the bad access, but also adds burden to each write. As we have mmio_debug available for more fine grained analysis, give up some accuracy for the benefit

[Intel-gfx] [PATCH 2/4] drm/i915: Introduce intel_uncore_unclaimed_access

Currently interrupt code is the only place checking for the unclaimed register access prior to actual register macros using the same functionality. Rename the function and make it return bool so that the possible error message context is clear in the caller side. The motivation is to allow usage

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Propagating correct error codes to the userspace

Hi, On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Propagating correct error codes to userspace by using ERR_PTR and PTR_ERR macros for stolen memory based object allocation. We generally return -ENOMEM to the user whenever

[Intel-gfx] [PATCH] drm/i915: Cancel hangcheck before GPU is suspended

In order to avoid accessing GPU registers while GPU is suspended cancel the hangcheck work before calling intel_suspend_complete which actually puts the GPU to suspend. Otherwise hangcheck might do MMIO reads to a suspended GPU. Placement before intel_guc_suspend is imitated from i915_drm_suspend

Re: [Intel-gfx] [PATCH] RFC: drm/i915: Take runtime pm wakelock during hangcheck

On ke, 2015-12-09 at 12:22 +, Chris Wilson wrote: > During hangcheck we access the hardware registers, for which we must > hold a runtime pm reference. Hangcheck also should only be running > whilst the GPU is active, and we hold a runtime pm whilst the GPU is > busy. Therefore, if the runtime

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Support for creating Stolen memory backed objects

Hi, On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Extend the drm_i915_gem_create structure to add support for creating Stolen memory backed objects. Added a new flag through which user can specify the preference to allocate

[Intel-gfx] [PATCH v2 03/14] drm: Pass 'name' to drm_encoder_init()

From: Ville Syrjälä Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. @@ identifier dev, encoder, funcs; @@ int

[Intel-gfx] [PATCH v2 13/14] drm/i915: Give encoders useful names

From: Ville Syrjälä Rather than let the core generate usless encoder names, let's pass in something that actually identifies the piece of hardware we're dealing with. v2: Use 'DSI %c' instead of 'MIPI %c' for DSI encoders (Jani) Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 3/4] drm/i915: Detect and clear unclaimed access on resume

If something, the usual suspect being bios, access hw behind our back, dont let it slide into situation where normal register access will detect this and spit out a warn on into dmesg. On some bdw bioses this happens during igt/bat run always and as there is not much we can do about it, its better

[Intel-gfx] [PATCH] drm/i915/kbl: Fix DMC load on Kabylake.

Kabylake A0 is based on Skylake H0. v2: Don't assume revid+7 and only load the one we are sure about. v3: Rebase on top of latest changes. v4: Accept cleaner solution from Jani with kbl_stepping_info starting on H0 instead of put a hack on revid. Cc: Jani Nikula

Re: [Intel-gfx] [PATCH v2] drm/i915: Do a better job at disabling primary plane in the noatomic case.

On Wed, 09 Dec 2015, Tomas M wrote: > Hello, > > Is there any special reason this has not been merged yet? No special reason. There's just the ordinary reason there is no review on the patch yet. BR, Jani. > > Regards > > Tomas > > On Tue, Dec 1, 2015 at 6:07 AM, Jani

Re: [Intel-gfx] [PATCH] drm/i915: Wait for PP cycle delay only if panel is in power off sequence

On Wed, Dec 9, 2015 at 8:34 PM, Chris Wilson wrote: > On Wed, Dec 09, 2015 at 08:07:10PM +0530, Shobhit Kumar wrote: >> On Wed, Dec 9, 2015 at 7:27 PM, Ville Syrjälä >> wrote: >> > On Wed, Dec 09, 2015 at 06:51:48PM +0530, Shobhit Kumar

[Intel-gfx] [PATCH 2/3] drm/i915: Take runtime pm wakelock during hangcheck

From: Chris Wilson During hangcheck we access the hardware registers, for which we must hold a runtime pm reference. Hangcheck also should only be running whilst the GPU is active, and we hold a runtime pm whilst the GPU is busy. Therefore, if the runtime pm is

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Remove double wait_for_vblank on broadwell.

Op 08-12-15 om 15:14 schreef Ville Syrjälä: > On Wed, Nov 25, 2015 at 11:44:48AM +0200, Ander Conselvan De Oliveira wrote: >> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote: >>> wait_vblank is already set in intel_plane_atomic_calc_changes >>> for broadwell, waiting for a double vblank

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Fix DMC load on Kabylake.

On Wed, 09 Dec 2015, Rodrigo Vivi wrote: > Kabylake A0 is based on Skylake H0. > > v2: Don't assume revid+7 and only load the one we are sure about. > > v3: Rebase on top of latest changes. > > v4: Accept cleaner solution from Jani with kbl_stepping_info > starting on

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add support for stealing purgable stolen pages

Hi, On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: From: Chris Wilson If we run out of stolen memory when trying to allocate an object, see if we can reap enough purgeable objects to free up enough contiguous free space for the allocation. This is in principle very much like

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

Hi, On 09/12/15 12:46, 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

[Intel-gfx] [PATCH 3/3] drm/i915: Do not cancel hangcheck prior to runtime suspend

Hangcheck will not touch an idle device anymore, so it does not need to be cancelled. Signed-off-by: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Check unclaimed access per forcewake domain get/put

On Wed, Dec 09, 2015 at 05:01:41PM +0200, Mika Kuoppala wrote: > We do unclaimed register access check in non mmio_debug mode > once per write. This adds probability of finding the exact > sequence where we did the bad access, but also adds burden > to each write. > > As we have mmio_debug

[Intel-gfx] [PATCH 0/2 v2] drm/i915: mark GEM objects as dirtied by CPU

This patchset covers various places where GEM objects are dirtied by means of CPU writes. The first patch covers cases where only one page is actually written; here we can mark just the specific page in the pagecache dirty. This applies to regular (shmfs-backed) objects only. The second patch

[Intel-gfx] [PATCH 1/3] PM / Runtime: Introduce pm_runtime_get_noidle

Introduce pm_runtime_get_noidle to for situations where it is not desireable to touch an idling device. One use scenario is periodic hangchecks performed by the drm/i915 driver which can be omitted on a device in a runtime idle state. Signed-off-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Consolidate unclaimed reg detection

On Wed, Dec 09, 2015 at 05:01:38PM +0200, Mika Kuoppala wrote: > Access the unclaimed reg detection register through > one helper which also does cleanup. Note that we now access > the register only if the platform has the actual non claimed access bit. > This prevents needlessly reading the

[Intel-gfx] [PATCH 1/2 v2] drm/i915: mark GEM object pages dirty when mapped & written by the CPU

In various places, a single page of a (regular) GEM object is mapped into CPU address space and updated. In each such case, either the page or the the object should be marked dirty, to ensure that the modifications are not discarded if the object is evicted under memory pressure. The typical

[Intel-gfx] [PATCH 2/2 v2] drm/i915: mark GEM objects dirty after overwriting their contents

In a few places, we fill a GEM object with data, or overwrite some portion of its contents other than a single page. In such cases, we should mark the object dirty so that its pages in the pagecache are written to backing store (rather than discarded) if the object is evicted due to memory

Re: [Intel-gfx] [PATCH] drm/i915: Cancel hangcheck before GPU is suspended

On Wed, Dec 09, 2015 at 04:10:03PM +0200, Imre Deak wrote: > On ke, 2015-12-09 at 15:56 +0200, Joonas Lahtinen wrote: > > In order to avoid accessing GPU registers while GPU is suspended > > cancel > > the hangcheck work before calling intel_suspend_complete which > > actually > > puts the GPU to

[Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle

Introduce pm_runtime_get_noidle to for situations where it is not desireable to touch an idling device. One use scenario is periodic hangchecks performed by the drm/i915 driver which can be omitted on a device in a runtime idle state. v2: - Fix inconsistent return value when !CONFIG_PM. - Update

Re: [Intel-gfx] [PATCH] drm/i915: Wait for PP cycle delay only if panel is in power off sequence

On Wed, Dec 09, 2015 at 08:59:26PM +0530, Shobhit Kumar wrote: > On Wed, Dec 9, 2015 at 8:34 PM, Chris Wilson wrote: > > On Wed, Dec 09, 2015 at 08:07:10PM +0530, Shobhit Kumar wrote: > >> On Wed, Dec 9, 2015 at 7:27 PM, Ville Syrjälä > >>

[Intel-gfx] [PATCH] drm/i915: Flush the RPS bottom-half when the GPU idles

Make sure that the RPS bottom-half is flushed before we set the idle frequency when we decide the GPU is idle. This should prevent any races with the bottom-half and setting the idle frequency, and ensures that the bottom-half is bounded by the GPU's rpm reference taken for when it is active (i.e.

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Separate cherryview from valleyview

On Tue, Dec 08, 2015 at 11:46:53AM -0800, Wayne Boyer wrote: > The cherryview device shares many characteristics with the valleyview > device. When support was added to the driver for cherryview, the > corresponding device info structure included .is_valleyview = 1. > This is not correct and

Re: [Intel-gfx] [PATCH v8] drm/i915: Extend LRC pinning to cover GPU context writeback

Reviewed-by: Alex Dai On 12/07/2015 09:10 AM, Nick Hoath wrote: Use the first retired request on a new context to unpin the old context. This ensures that the hw context remains bound until it has been written back to by the GPU. Now that the context is pinned until later in

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Migrate stolen objects before hibernation

Hi, On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: From: Chris Wilson Ville reminded us that stolen memory is not preserved across hibernation, and a result of this was that context objects now being allocated from stolen were being corrupted on S4 and

Re: [Intel-gfx] [PATCH v7] drm/i915: Add soft-pinning API for execbuffer

The stress test will need to be modified to ensure a canonical address(currently uses starting address of 0x8). The invalid_vma test takes care of the non-canonical scenario in an indirect way. Do we still need a separate test for this change then? Thanks, Vinay. -Original

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Migrate stolen objects before hibernation

On Wed, Dec 09, 2015 at 05:25:19PM +, Tvrtko Ursulin wrote: > > Hi, > > On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: > > From: Chris Wilson > > > > Ville reminded us that stolen memory is not preserved across > > hibernation, and a result of this was

Re: [Intel-gfx] [PATCH] drm/i915: Fix random aux transactions failures.

2015-12-07 10:04 GMT-02:00 Rodrigo Vivi : > Mainly aux communications on sink_crc > were failing a lot randomly on recent platforms. > The first solution was to try to use intel_dp_dpcd_read_wake, but then > it was suggested to move retries to drm level. > > Since drm level

[Intel-gfx] [PATCH v2] drm/i915/guc: Move GuC wq_reserve_space to alloc_request_extras

From: Alex Dai Split GuC work queue space reserve from submission and move it to ring_alloc_request_extras. The reason is that failure in later i915_add_request() won't be handled. In the case timeout happens, driver can return early in order to handle the error. v1: Move

Re: [Intel-gfx] [PATCH] drm/i915: Flush the RPS bottom-half when the GPU idles

On Wed, 2015-12-09 at 20:52 +, Chris Wilson wrote: > On Wed, Dec 09, 2015 at 07:47:29PM +0200, Imre Deak wrote: > > >  void gen6_rps_idle(struct drm_i915_private *dev_priv) > > >  { > > > - struct drm_device *dev = dev_priv->dev; > > > + /* Flush our bottom-half so that it does not race with >

[Intel-gfx] [PATCH 1/5] drm/i915: Separate cherryview from valleyview

The cherryview device shares many characteristics with the valleyview device. When support was added to the driver for cherryview, the corresponding device info structure included .is_valleyview = 1. This is not correct and leads to some confusion. This patch changes .is_valleyview to

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Separate cherryview from valleyview

On Wed, Dec 09, 2015 at 12:29:35PM -0800, Wayne Boyer wrote: > The cherryview device shares many characteristics with the valleyview > device. When support was added to the driver for cherryview, the > corresponding device info structure included .is_valleyview = 1. > This is not correct and

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Separate cherryview from valleyview

Thanks Ville. I'll send one more update with some of the changes. I'll leave the others for a different patch. Details below. Wayne On 12/9/15, 9:10 AM, "Ville Syrjälä" wrote: >On Tue, Dec 08, 2015 at 11:46:53AM -0800, Wayne Boyer wrote: >> The cherryview

Re: [Intel-gfx] [PATCH] drm/i915: Flush the RPS bottom-half when the GPU idles

On Wed, Dec 09, 2015 at 07:47:29PM +0200, Imre Deak wrote: > >  void gen6_rps_idle(struct drm_i915_private *dev_priv) > >  { > > - struct drm_device *dev = dev_priv->dev; > > + /* Flush our bottom-half so that it does not race with us > > +  * setting the idle frequency and so that it is

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

On Tue, Dec 08, 2015 at 04:15:05PM -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. > >

Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle

On Wednesday, December 09, 2015 06:22:19 PM Joonas Lahtinen wrote: > Introduce pm_runtime_get_noidle to for situations where it is not > desireable to touch an idling device. One use scenario is periodic > hangchecks performed by the drm/i915 driver which can be omitted > on a device in a runtime

[Intel-gfx] [PATCH 1/2] drm/i915: Call encoder hotplug for init and resume cases

Call the encoders, call the hot_plug if it is registered. This is required for connected boot and resume cases to generate fake hpd resulting in reading of edid. Removing the initial sdvo hot_plug call too so that it will be called just once from this loop. v2: Schedule a work function to call

[Intel-gfx] [PATCH] drm/i915: Add hot_plug hook for hdmi encoder

From: Shashank Sharma This patch adds a separate probe function for HDMI EDID read over DDC channel. This function has been registered as a .hot_plug handler for HDMI encoder. The current implementation of hdmi_detect() function re-sets the cached HDMI edid (in

[Intel-gfx] [PATCH 2/2] drm/i915: Add hot_plug hook for hdmi encoder

This patch adds a separate probe function for HDMI EDID read over DDC channel. This function has been registered as a .hot_plug handler for HDMI encoder. The current implementation of hdmi_detect() function re-sets the cached HDMI edid (in connector->detect_edid) in every detect call.This

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Migrate stolen objects before hibernation

On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: From: Chris Wilson Ville reminded us that stolen memory is not preserved across hibernation, and a result of this was that context objects now being allocated from stolen were being corrupted on S4 and promptly

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

On 09/12/15 16:15, Tvrtko Ursulin wrote: Hi, On 09/12/15 12:46, 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

  1   2   >