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 file changed, 14 ins
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 afterwards.
>
> I didn't convert d
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 Syrjälä
> diff --git a/drivers/gpu/d
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 style format string to the init
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 handled. In the
> c
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 +++
2 files chan
> -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 link pipe
> selection f
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 is that userspace is handl
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 of stress tests which copy bu
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
Cc: Jani Nikula
Cc: Laurent Pinchart
Acked-by: Laurent Pinchart
Signed-off-by: Daniel Vet
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
> Cc: Jani Nikula
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 kernel will then do its ut
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
little confused. You're trying to make resume fa
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
> ---
> drivers/gpu/drm/i915/intel_csr.c | 18 +++
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 "these documentations use A
zed
> > encoder.
> >
> > Cc: Daniel Vetter
> > Cc: Jani Nikula
> > Signed-off-by: Sudip Mukherjee
>
> Queued for -next, thanks for the patch.
> -Daniel
Hi Daniel,
It is still not there in linux-next. Still applies cleanly on
next-20151209.
regards
sudip
>
>
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 style name.
> >
> > Signed-off
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 usless encoder names, let's pass in
> > something that actually identifies the piece of hardware we're dealing
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 'int DOTDOTDOT' placeholder
> > i
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 so that
> >> resume path will be faster.
> >
> > Can you please elaborate mo
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 i
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 object is located
at. The kern
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 from Pierre, Laurent and
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 so that
resume path will be faster.
Can you
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 for i915_gem_clear_object(), corre
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 bind
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 identify the correct reason for t
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 made to allocate
the object from s
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, memory stolen from the system by the
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.
v2: Drop locks around slow_user
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 as much as possible (nothing
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
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++
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 buffers allocated from stolen
regio
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 su
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 for buffers allocated from stolen
t; -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.
Thanks, Daniel
>
> regards
> sudip
>
> >
> > > ---
> > &
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 can pass in an offset that
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 fixes from Pierre, Laurent a
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 Wil
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 usless encoder names, let's pass in
>> > something that actual
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
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> dri
On Wed, Dec 09, 2015 at 08:14:04PM +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.
>
> v2: Use macro BXT_PIPE_SELECT(pipe) (Daniel)
>
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
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
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 intend to use this only for buff
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 buffers allocated from stolen
regi
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.
>
> Signed
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
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 the object from
stolen memory, wh
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.
>
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 the common style so we can try to unify at least new docs.
>
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, so I put an
'int DOTDOTDOT' place
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 varargs through
would mean either cpp
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 Nikula
> wrote:
>
>> On
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 drm_encoder_init(struct drm_device *dev,
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ä
---
drivers/gpu/drm/i915/intel_crt.
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 type or review docs this seems a bit different. Try to
> >> >
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 for DPI FIFO empty check
>
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 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 wai
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 of
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 of
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
Cc: Paulo Za
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
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 wrote:
> >> During resume, while turning the EDP panel power on, we need not wait
> >> blindly for panel_power_cycle_d
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 ig
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
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 BDW/SKL/BXT platforms
2. Adds Gamma co
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
>
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
Signed-off-by: Rodrigo Vivi
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 Am
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 there is a failure in object
alloc
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 ig
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
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 wrote:
>> >> During resume, while turning the EDP panel powe
On ma, 2015-12-07 at 13:53 -0800, Bob Paauwe wrote:
> When changing the sysfs GT min frequency, the kernel won't
> automatcilly drop the GT frequency to idle unless the GPU
> transitions from busy to idle.
>
> Load the GPU after increasing the GT min frequency to force
> a busy to idle transition.
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 H0 instead of put a hack
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 evictin
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 suspended (no wakelocks held
anywhe
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 a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index
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
Reported-by: Chris Wilson
Cc:
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 availab
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 regist
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 cov
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 seque
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 pressure
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.
v3: More spelling fixes from Lukas.
Cc: Pierre Moreau
Cc: Jani Nikula
Cc: Laurent Pinchart
Cc: Lukas Wunner
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ä
> >> wrote:
> >> > On Wed, Dec 09, 2015 at 06:51:48PM +0530, S
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 backed by stolen memory as well
as
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 s
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 d
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 the request/context
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.
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 leads
On 12/09/2015 01:05 AM, Chris Wilson wrote:
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_
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 promptly hanging
the GPU on re
On 12/09/2015 09:10 AM, Chris Wilson wrote:
> 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 GP
On ke, 2015-12-09 at 17:10 +, Chris Wilson wrote:
> 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 bound
Hi,
On 9 December 2015 at 05:15, Vandana Kannan wrote:
> This patch includes enabling render decompression after checking all the
> requirements (format, tiling, rotation etc.). Along with this, the WAs
> mentioned in BSpec Workaround page have been implemented.
> In case, any of the conditions f
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 was already taking care
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 wq_reserve_space to rin
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 Mes
1 - 100 of 113 matches
Mail list logo