From: Ankitprasad Sharma
This patch extends the GET_APERTURE ioctl to add support
for getting total size and available size of the stolen region
as well as single largest block available in the stolen region.
Also adds debugfs support to retieve the size information of the
stolen area.
v2: respi
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only t
From: Ankitprasad Sharma
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question
Yu Dai writes:
> On 07/07/2015 09:49 AM, Yu Dai wrote:
>> On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
>> > Pass around requests to carry context deeper in callchain.
>> >
>> > Signed-off-by: Mika Kuoppala
>> > ---
>> > drivers/gpu/drm/i915/intel_lrc.c | 30 ++
>> >
On Wed, Jul 08, 2015 at 08:40:17AM +0200, Michal Hocko wrote:
> I have just tried to boot 4.2-rc1 and cannot seem to reproduce the issue
> anymore.
>
> On Tue 07-07-15 10:43:58, Daniel Vetter wrote:
> [...]
> > Can you please
> > boot with drm.debug=0xf (lots more nois in dmesg with this) and repr
On Wed 08-07-15 09:32:18, Daniel Vetter wrote:
[...]
> Ok that's starting to get nasty. Can you please test what happens when you
> boot with drm.vblankoffdelay=0 and whether drm.vblankoffdelay=1000 has an
> effect on reproduction rate? No debug output needed.
No difference. See the kernel log fro
Op 07-07-15 om 18:43 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:10 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 0
On Tue, Jul 07, 2015 at 04:14:01PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:39 schreef Patrik Jakobsson:
> > On Tue, Jul 07, 2015 at 12:22:12PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:14AM +0200, Maarten Lankhor
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6740
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Op 07-07-15 om 12:11 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst wrote:
>> Instead of doing ad-hoc checks we already have a way of checking
>> if the state is compatible or not. Use this to force a modeset.
>>
>> Only during modesets, or with PIPE_CONFIG_QUI
On Wed, Jul 08, 2015 at 10:40:18AM +0530, Jindal, Sonika wrote:
>
>
> On 7/7/2015 6:51 PM, Ville Syrjälä wrote:
> > On Tue, Jul 07, 2015 at 02:22:20PM +0530, Sonika Jindal wrote:
> >> Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
> >> Handle it only if hpd has actually occurred
Op 08-07-15 om 10:12 schreef Patrik Jakobsson:
> On Tue, Jul 07, 2015 at 04:14:01PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:39 schreef Patrik Jakobsson:
>>> On Tue, Jul 07, 2015 at 12:22:12PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue,
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst
On Tue, Jul 07, 2015 at 08:23:46PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-07-07 at 13:24 +0200, Daniel Vetter wrote:
> > On Mon, Jul 06, 2015 at 11:19:03PM +, Vivi, Rodrigo wrote:
> > > On Mon, 2015-07-06 at 19:56 +0200, Daniel Vetter wrote:
> > > > On Mon, Jul 06, 2015 at 02:11:55PM -0300,
On Wed, Jul 08, 2015 at 10:38:33AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 12:11 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst wrote:
> >> @@ -12392,27 +12379,124 @@ static bool intel_fuzzy_clock_check(int clock1,
> >> int clock2)
> >>
Op 08-07-15 om 11:09 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 10:38:33AM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 12:11 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst wrote:
@@ -12392,27 +12379,124 @@ static bool intel_fuzzy_clock_check(
On Tue, Jul 07, 2015 at 04:02:32PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 13:16 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:18AM +0200, Maarten Lankhorst wrote:
> >> Make sure the primary plane is set up correctly. This is done by
> >> setting plane_state->src and plane_state
On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote:
> On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > When rotated and partial views were added no one spotted the resume
> > path which assumes only one GGTT VMA per object and hence is now
wa_ctx_emit() depends on the name of a local variable; if the name of that
variable is changed then we get compile errors. In this case it is unlikely
to be changed as this macro is only used in this set of functions but
Kernel coding guidelines doesn't recommend doing this. It was my mistake
as I
On Wed, Jul 08, 2015 at 11:18:27AM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 11:09 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 10:38:33AM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 12:11 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst
On Tue, Jul 07, 2015 at 03:26:06PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The poor in_dbg_master() check was the only one without a reason
> string. Give it a reason string so it won't feel excluded.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
>
On Wed, Jul 08, 2015 at 10:27:05AM +0100, Arun Siluvery wrote:
> wa_ctx_emit() depends on the name of a local variable; if the name of that
> variable is changed then we get compile errors. In this case it is unlikely
> to be changed as this macro is only used in this set of functions but
> Kernel
On Tue, Jul 07, 2015 at 08:53:23PM +0100, Chris Wilson wrote:
> On Tue, Jul 07, 2015 at 03:26:02PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Before I continue sending fixes, let's just do some small adjustments to the
> > codebase. I really think these changes make the code better
On 7/6/2015 5:14 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Since
commit e62925567c7926e78bc8ca976cde5c28ea265a49
Author: Vandana Kannan
Date: Wed Jul 1 17:02:57 2015 +0530
drm/i915/bxt: BUNs related to port PLL
BXT DPLL can now generate frequencies in the 21
On Tue, Jul 07, 2015 at 04:28:56PM -0700, Rodrigo Vivi wrote:
> fbdev_set_par is called when fbcon is taking over control, but
> frontbuffer was being invalidated only on the first time when
> moving obj to GTT domain.
> However on the following calls write domain was already GTT
> so invalidate wa
On Tue, Jul 07, 2015 at 04:28:53PM -0700, Rodrigo Vivi wrote:
> Let's do a frontbuffer flush on dirty fb.
> To be used for DIRTYFB drm ioctl.
>
> This patch solves the biggest PSR known issue, that is
> missed screen updates during boot, mainly when there is a splash
> screen involved like Plymout
On 07/08/2015 10:32 AM, Daniel Vetter wrote:
On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote:
On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When rotated and partial views were added no one spotted the resume
path which assumes only one GGTT
On Wed, Jul 08, 2015 at 11:38:02AM +0200, Daniel Vetter wrote:
> On Tue, Jul 07, 2015 at 03:26:06PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > The poor in_dbg_master() check was the only one without a reason
> > string. Give it a reason string so it won't feel excluded.
> >
> > Si
On Wed, Jul 08, 2015 at 10:45:23AM +0100, Tvrtko Ursulin wrote:
>
> On 07/08/2015 10:32 AM, Daniel Vetter wrote:
> >On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote:
> >>On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
> >>>From: Tvrtko Ursulin
> >>>
> >>>When rotated a
Op 07-07-15 om 11:15 schreef Daniel Vetter:
> Since
>
> commit 8c7b5ccb729870e606321b3703e2c2e698c49a95
> Author: Ander Conselvan de Oliveira
> Date: Tue Apr 21 17:13:19 2015 +0300
>
> drm/i915: Use atomic helpers for computing changed flags
>
> we compute the plane state for a modeset befor
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6744
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On 7/7/2015 9:08 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:44:30PM +0100, Michel Thierry wrote:
On 7/7/2015 4:27 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it
On Wed, Jul 01, 2015 at 05:23:51PM +0200, Daniel Vetter wrote:
> On Wed, Jul 1, 2015 at 2:21 PM, David Weinehall
> wrote:
> > On Tue, Jun 30, 2015 at 03:01:06PM +0100, Chris Wilson wrote:
> >> On Tue, Jun 30, 2015 at 04:36:55PM +0300, David Weinehall wrote:
> >> > On Tue, Jun 30, 2015 at 02:32:19P
Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.
v2: Make few variables local to if block (Ville)
v3: Add check for ibx/cpt both (Ville).
While at it, remove the redundant check for hotplug_trigger from
On 7/7/2015 5:50 PM, Sivakumar Thulasimani wrote:
On 7/7/2015 5:24 PM, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 02:37:46PM +0300, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 04:45:11PM +0530, Sivakumar Thulasimani wrote:
On 7/7/2015 4:40 PM, Ville Syrjälä wrote:
On Tue, Jul 07, 2015
On Wed, Jul 08, 2015 at 05:50:05PM +0530, Sivakumar Thulasimani wrote:
>
>
> On 7/7/2015 5:50 PM, Sivakumar Thulasimani wrote:
> >
> >
> > On 7/7/2015 5:24 PM, Ville Syrjälä wrote:
> >> On Tue, Jul 07, 2015 at 02:37:46PM +0300, Ville Syrjälä wrote:
> >>> On Tue, Jul 07, 2015 at 04:45:11PM +0530,
Op 08-07-15 om 11:27 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 04:02:32PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 13:16 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:18AM +0200, Maarten Lankhorst wrote:
Make sure the primary plane is set up correctly. This is done b
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6745
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -9
Chris Wilson writes:
> On Tue, Jul 07, 2015 at 10:13:01PM +0300, Francisco Jerez wrote:
>> From: Peter Antoine
>>
>> This change adds the programming of the MOCS registers to the gen 9+
>> platforms. This change set programs the MOCS register values to a set
>> of values that are defined to be
On Wed, Jul 08, 2015 at 12:24:07PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:15 schreef Daniel Vetter:
> > Since
> >
> > commit 8c7b5ccb729870e606321b3703e2c2e698c49a95
> > Author: Ander Conselvan de Oliveira
> > Date: Tue Apr 21 17:13:19 2015 +0300
> >
> > drm/i915: Use atomic hel
Hi,
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
On Wed, Jul 08, 2015 at 03:50:06PM +0300, Francisco Jerez wrote:
> Chris Wilson writes:
>
> > On Tue, Jul 07, 2015 at 10:13:01PM +0300, Francisco Jerez wrote:
> >> From: Peter Antoine
> >>
> >> This change adds the programming of the MOCS registers to the gen 9+
> >> platforms. This change set
On 7/7/2015 5:01 PM, Daniel Vetter wrote:
On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar Thulasimani wrote:
From: "Thulasimani,Sivakumar"
Update the hotplug documentation to explain that hotplug storm
is not expected for Display port panels and hence is not handled
in current code.
Sig
On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
> >From: Rodrigo Vivi
> >
> >When constructing a batchbuffer, it is sometimes crucial to know the
> >largest hole into which we can fit a fenceable buffer (fo
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragm
Watermark calculations depend on the intel_crtc->active flag to be set
properly. Suspend/resume is broken on SKL and we also get DDB mismatches
without this patch.
The regression was introduced in:
commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
Author: Maarten Lankhorst
Date: Mon Jun 15 12:33
Hi,
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch extends the GET_APERTURE ioctl to add support
for getting total size and available size of the stolen region
as well as single largest block available in the stolen region.
Also adds debugfs
On 07/08/2015 02:28 PM, Chris Wilson wrote:
On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote:
Hi,
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we c
On Wed, Jul 08, 2015 at 02:28:33PM +0100, Chris Wilson wrote:
> On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote:
> >
> > Hi,
> >
> > On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
> > >From: Rodrigo Vivi
> > >
> > >When constructing a batchbuffer, it is sometimes cr
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> This will be useful to PSR and FBC once we start making
> dirty fb calls to also flush frontbuffer.
>
> Cc: Daniel Vetter
> Cc: Paulo Zanoni
Reviewed-by: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_gem.c |
Chris Wilson writes:
> On Wed, Jul 08, 2015 at 03:50:06PM +0300, Francisco Jerez wrote:
>> Chris Wilson writes:
>>
>> > On Tue, Jul 07, 2015 at 10:13:01PM +0300, Francisco Jerez wrote:
>> >> From: Peter Antoine
>> >>
>> >> This change adds the programming of the MOCS registers to the gen 9+
>
On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote:
>
> On 07/08/2015 02:28 PM, Chris Wilson wrote:
> >On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
> >>>From: Rodrigo Vivi
> >>>
> >>
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> Since flush actually means invalidate + flush we need to force psr
> exit on PSR flush.
>
> On Core platforms there is no way to do the sw tracking so we
There is no way to do the _HW_ tracking?
> simulate it by fully disable psr and reschedule a enable
2015-07-08 6:47 GMT-03:00 Daniel Vetter :
> On Tue, Jul 07, 2015 at 04:28:53PM -0700, Rodrigo Vivi wrote:
>> Let's do a frontbuffer flush on dirty fb.
>> To be used for DIRTYFB drm ioctl.
Just a notice: this commit will also be useful for FBC, so I hope that
marking the commit title as "PSR" won't
v1: As per review comments from Daniel, removed the csr-lock
and csr-state which was used before in dmc firmware loading.
Planning to have a single async task which will responsible
for firmware loading and register programming for dc5/dc6,
so removed csr-lock and csr-state from intel_csr structure
v1: As per review comments from Daniel, prevented entering in
dc5/dc6 while firmware loading in process. Now register programming
for dc5/dc6 always will happen followed by firmware loading. Added
a async work which is responsible for both loading the firmware
and register programming for dc5/dc6.
v1: Based on review comments from Daniel following changes are done.
- More focus is given for better synchronization.
- Replaced async firmware loading by using request_firmawre() call.
- Prevented entering in dc5/dc6 while firmware loading in process.
Now register programming for dc5/dc6 always w
v1: As per review comments from Daniel, replaced async firmware
loading with request_firmware() which will load the dmc firmware and
once firmware is loaded, dc5/dc6 register programming can be done
in the same thread.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.c | 3
On 07/08/2015 02:53 PM, Chris Wilson wrote:
On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote:
On 07/08/2015 02:28 PM, Chris Wilson wrote:
On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote:
Hi,
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: R
As during disabling dc6 no need to check for csr firmware
loading status, so removed the assert call.(Requested by Damien.)
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drive
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_csr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index d600640..f515d54 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915
Firmware loading can be optimized by setting the dmc_present flag
for the first time and later internallly stored firmware data
can be used.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_csr.c | 24 +++-
2 files changed,
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> By Spec we should only mask memup and hotplug detection
> for hardware tracking cases. However we always masked
> LPSP because with power well always enabled on audio
> PSR was never being activated and residency was always
> zeroed.
>
> Apparently audio
On Wed, Jul 08, 2015 at 03:24:08PM +0100, Tvrtko Ursulin wrote:
>
> On 07/08/2015 02:53 PM, Chris Wilson wrote:
> >On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 07/08/2015 02:28 PM, Chris Wilson wrote:
> >>>On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrot
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> Idle frames the number of identical frames needed
> before panel can enter PSR.
>
> There are some panels that requires up to minimum of 4 idle
> frames available on the market. For these cases usually
> VBT should be used to configure the number of idle
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect request
From: Peter Antoine
This change adds the programming of the MOCS registers to the gen 9+
platforms. The set of MOCS configuration entries introduced by this
patch is intended to be minimal but sufficient to cover the needs of
current userspace - i.e. a good set of defaults. It is expected to be
e
On Wed, Jul 08, 2015 at 05:51:22PM +0300, Francisco Jerez wrote:
Just a few style nits, didn't look at the actual contents...
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2a29bcc..9b17260 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/g
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Saturday, July 4, 2015 1:24 PM
> To: Kristian Høgsberg
> Cc: Daniel, Thomas; Belgaumkar, Vinay; intel-gfx@lists.freedesktop.org; Michal
> Winiarsky; Goel, Akash
> Subject: Re: [Intel-gfx] [PATCH v4] drm/i915
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6749
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On 07/07/2015 20:13, Francisco Jerez wrote:
From: Peter Antoine
This change adds the programming of the MOCS registers to the gen 9+
platforms. This change set programs the MOCS register values to a set
of values that are defined to be optimal.
It creates a fixed register set that is programme
On Wed, Jul 08, 2015 at 05:07:47PM +0530, Sonika Jindal wrote:
> Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
> Handle it only if hpd has actually occurred like we handle other
> interrupts.
> v2: Make few variables local to if block (Ville)
> v3: Add check for ibx/cpt both (Vill
On Wed, Jul 08, 2015 at 06:54:06PM +0530, Sivakumar Thulasimani wrote:
>
>
> On 7/7/2015 5:01 PM, Daniel Vetter wrote:
> >On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar Thulasimani wrote:
> >>From: "Thulasimani,Sivakumar"
> >>
> >>Update the hotplug documentation to explain that hotplug sto
On Wed, Jul 08, 2015 at 12:22:58PM +0100, Michel Thierry wrote:
> On 7/7/2015 9:08 PM, Chris Wilson wrote:
> >On Tue, Jul 07, 2015 at 04:44:30PM +0100, Michel Thierry wrote:
> >>On 7/7/2015 4:27 PM, Chris Wilson wrote:
> >>>On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
> In a
On Wed, Jul 08, 2015 at 10:41:58AM -0300, Paulo Zanoni wrote:
> 2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> > This will be useful to PSR and FBC once we start making
> > dirty fb calls to also flush frontbuffer.
> >
> > Cc: Daniel Vetter
> > Cc: Paulo Zanoni
>
> Reviewed-by: Paulo Zanoni
Queue
On Wed, Jul 08, 2015 at 03:04:45PM +, Daniel, Thomas wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Saturday, July 4, 2015 1:24 PM
> > To: Kristian Høgsberg
> > Cc: Daniel, Thomas; Belgaumkar, Vinay; intel-gfx@lists.freedesktop.org;
> >
Clearing the watermarks for all pipes/planes when updating the
watermarks for a single CRTC change seems like the wrong thing to
do here. As is, this code will update any pipe/plane watermarks
that need updating and leave the remaining set to zero. Later, the
watermark checks in check_wm_state() w
We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and userptr objects
For 1. and 2. the lifetime of the DMA mapping matche
After the previous patch this flag will check always clear, as it's
never set for shmem backed and userptr objects, so we can remove it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h| 2 --
drivers/gpu/drm/i915/i915_gem.c| 3 ---
drivers/gpu/drm/i915/i915_gem_dmabu
Op 08-07-15 om 10:55 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 18:43 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 0
On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/dr
On 7/8/2015 4:22 PM, Daniel Vetter wrote:
On Wed, Jul 08, 2015 at 12:22:58PM +0100, Michel Thierry wrote:
On 7/7/2015 9:08 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:44:30PM +0100, Michel Thierry wrote:
On 7/7/2015 4:27 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:14:59PM +0100,
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: de152b627eb3018de91ec5c5a50b38e17d80a88b
commit: de152b627eb3018de91ec5c5a50b38e17d80a88b [378/378] drm/i915: Add origin
to frontbuffer tracking flush
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
On Wed, Jul 08, 2015 at 05:42:17PM +0100, Michel Thierry wrote:
> >WARN_ON(vma->node.size != obj->base.size) ? Feel free to get the casting
> >right - I suck at implicit C integer conversion rules ...
> >-Daniel
> >
> Thanks, if there's no objections, I'll change it to:
>
> if (WARN_ON(vma->no
On 08/07/15 17:40, Yu Dai wrote:
On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drive
On Wed, Jul 08, 2015 at 07:18:58PM +0300, Imre Deak wrote:
> We have 3 types of DMA mappings for GEM objects:
> 1. physically contiguous for stolen and for objects needing contiguous
>memory
> 2. DMA-buf mappings imported via a DMA-buf attach operation
> 3. SG DMA mappings for shmem backed and
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6751
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Wed, Jul 08, 2015 at 07:18:59PM +0300, Imre Deak wrote:
> After the previous patch this flag will check always clear, as it's
> never set for shmem backed and userptr objects, so we can remove it.
>
> Signed-off-by: Imre Deak
Mentioned a trivial obj->get_page bugfix for
__i915_gem_userptr_set
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst
On Wed Jul 08 2015 at 18:04:44 +0100, Dave Gordon wrote:
> On 08/07/15 17:40, Yu Dai wrote:
> >On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
> >>Pass around requests to carry context deeper in callchain.
> >>
> >>Signed-off-by: Mika Kuoppala
> >>---
> >> drivers/gpu/drm/i915/intel_lrc.c | 14 +
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> This fbdev restore mode was another corner case that was now
> calling frontbuffer flip and flush and making we miss
> screen updates with PSR enabled.
>
> So let's also add the invalidate hack here while we don't have
> a reliable dirty fbdev op.
So whe
Op 08-07-15 om 19:52 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
>> Op 08-07-15 om 10:55 schreef Daniel Vetter:
>>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
> On Tue, Jul 0
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6752
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 19:52 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> >> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> >>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst
From: Ville Syrjälä
dev_priv->chv_phy_control is protected by the power_domains->lock
elsewhere, so also grab it when initializing chv_phy_control.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i91
From: Ville Syrjälä
CHV has supports some form of automagic clock gating for the
DPIO SUS clock. We can simply enable the magic bits and the
hardware should take care of the rest.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_runt
From: Ville Syrjälä
To implement DPIO lane power gating on CHV we're going to need to access
DPIO registers from the cmn power well enable hook. That gets called
rather early, so we need to move the DPIO port IOSF sideband port
assignment earlier as well.
Signed-off-by: Ville Syrjälä
---
drive
From: Ville Syrjälä
With DPIO powergating active on CHV, we can't even access the DPIO PLL
registers until the lane power state overrides have been enabled. That
will happen from the encoder .pre_pll_enable() hook, so move
chv_prepare_pll() to happen after that point, which puts it just before
ch
From: Ville Syrjälä
Here's the new version of the CHV DPIO powergating feature. In short,
it allows us to power off unused lanes in the display PHY. So should
save some power when stuff is either disabled, or when running DP links
with less than four lanes.
My previous attempt [1] failed to actu
From: Ville Syrjälä
Move the CHV clock buffer disable from chv_disable_pll() to the new
encoder .post_pll_disable() hook. This is more symmetric since the
clock buffer enable happens from the .pre_pll_enable() hook.
We'll have more use for the new hook soon.
Signed-off-by: Ville Syrjälä
---
d
1 - 100 of 132 matches
Mail list logo
