On 2015.07.09 13:50:14 +0800, Zhenyu Wang wrote:
>
> GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing
> system for GT-Pin on Linux, we now have aligned kit release regularly.
>
> Please check wiki page for details and the link to download the kit.
>
> https://wiki.ith
GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing
system for GT-Pin on Linux, we now have aligned kit release regularly.
Please check wiki page for details and the link to download the kit.
https://wiki.ith.intel.com/display/OTCGFXPERF/GT-Pin+for+Linux
thanks.
--
Op
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_gtt.c
between commit:
00245266b4be ("drm/i915/ppgtt: Break loop in gen8_ppgtt_clear_range failure
path")
from Linus' tree and commit:
567047be2a7e ("drm/i915/gtt: Use macros to acces
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commits:
63fef06ada94 ("drm/i915: Check crtc->active in intel_crtc_disable_planes")
dec4f799d0a4 ("drm/i915: Use crtc_state->active in primary check_plane func")
from th
Hi folks,
I emailed the mailing list before and Chris Wilson said that (or at least
seemed to suggest) GLAMOR support is independent of xf86-video-intel drivers.
However, my experience seemed to suggest otherwise. If I just enable Glamor in
Xorg-server, the intel driver seemed to ignore the Gl
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6754
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
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.
v2: As pointed by Paulo: removed seg fault risk, used fb_he
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind.
Commit that changed this fixing set_domain case was:
commit 031b698a77a70a6c394568034437b5486a44e868
Au
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 Plymouth.
Previously PSR was being invalidated by fbdev and Plymounth
was taking
Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.
On Core platforms there is no way to disable hw tracking and
do the pure sw tracking so we simulate it by fully disable psr and
reschedule a enable back.
So a good idea is to minimize sequential disable/enable in
On Wed, Jul 08, 2015 at 05:58:55PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We were forgetting to set fbc.crtc, fbc.fb_id and fbc.y when the
> kzalloc call failed. Luckily, this is not a very common case, I hope.
That did not prepare me for the patch that lies ahead.
"Always update t
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6753
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
From: Paulo Zanoni
Reported by the kbuild test robot.
Regression introduced by:
commit de152b627eb3018de91ec5c5a50b38e17d80a88b
Author: Rodrigo Vivi
Date: Tue Jul 7 16:28:51 2015 -0700
drm/i915: Add origin to frontbuffer tracking flush
(I reviewed this commit, so it's also my fault)
Sig
From: Paulo Zanoni
Reported by the kbuild test robot.
Regression introduced by:
commit fdbff9282c0f5f61ffc87d57461b04d943250910
Author: Daniel Vetter
Date: Thu Jun 18 11:23:24 2015 +0200
drm/i915: Clear fb_tracking.busy_bits also for synchronous flips
(I reviewed this commit, so it's als
From: Paulo Zanoni
So make it static.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h | 3 ---
drivers/gpu/drm/i915/intel_frontbuffer.c | 6 +++---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/in
From: Paulo Zanoni
Keep searching in case the candidate has a NULL primary fb. This is
only relevant for the platforms that don't have the pipe_a_only
restriction.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
From: Paulo Zanoni
I could only find the restrictions for HSW+, but I think it's safe to
assume that the older platforms also can't support the configurations
HSW can't support. The older platforms probably have additional
restrictions, so we need to figure out those and implement them later.
Let
From: Paulo Zanoni
The doc is pretty clear that this register should be set to 0 on SNB.
We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --gi
From: Paulo Zanoni
I only tested this on BDW, but since the register description is the
same ever since gen4, let's assume that all gens take the same
register format. If that's not true, then hopefully someone will
bisect a bug to this patch and we'll fix it.
Notice that the wrong fence offset
From: Paulo Zanoni
We were forgetting to set fbc.crtc, fbc.fb_id and fbc.y when the
kzalloc call failed. Luckily, this is not a very common case, I hope.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 27 +--
1 file changed, 17 insertions(+), 10 dele
From: Paulo Zanoni
We used to have this bug in the past, but now that we properly track
the size of the CFB, we don't have it anymore. Still, add the WARN
just to make sure we don't go back to the bad state.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 2 ++
1 file change
From: Paulo Zanoni
Serve these while the others are still baking.
Paulo Zanoni (6):
drm/i915: make sure we're not changing the FBC CFB with FBC enabled
drm/i915: fix the FBC work allocation failure path
drm/i915: fix FBC for cases where crtc->base.y is non-zero
drm/i915: set ILK_DPFC_FEN
From: Ville Syrjälä
Currently we relesar the lane soft reset before lane stagger settings
have been programmed. I believe that means we don't actually do lane
staggering. So move the soft reset deassert to happen after lane
staggering has been programmed.
The one confusing thing in this is that
From: Ville Syrjälä
Add some checks that the state of the DPIO lanes is more or less what we
expect based on the overrides.
The hardware only provides two bits per channel indicating whether all
or some of the lanes are powered down, so we can't do an exact check.
Additionally, CL2 powering dow
From: Ville Syrjälä
We can choose to leave the display PHY CL2 powerdown up to some hardware
signals, or we can force it. The BXT code forces the nonexistent CL2 in
the x1 PHY to power down. Follow suit on CHV. Maybe it can still save
some extra power by disabling some extra logic in CL1, or some
From: Ville Syrjälä
Normmally the common lane in a PHY channel gets powered up when some
of the data lanes get powered up. But when we're driving port B with
pipe B we don't want to enabled any of the data lanes, and just want
the DPLL in the common lane to be active.
To make that happens we hav
From: Ville Syrjälä
With DPIO powergating active the DPLL can't be accessed unless
something else is keeping the common lane in the channel on.
That means the PPS kick procedure could fail to enable the PLL.
Power up some data lanes to force the common lane to power up
so that the PLL can be ena
From: Ville Syrjälä
Powergate the PHY lanes when they're not needed. For HDMI all four lanes
are needed always, but for DP we can enable only the needed lanes. To
power down the unused lanes we use some power down override bits in the
DISPLAY_PHY_CONTROL register. Without the overrides it appears
From: Ville Syrjälä
At various points when changing the DPIO lane/phy power states,
construct an expected value of the DISPLAY_PHY_STATUS register
and compare it with the real thing.
To construct the expected value we look at our shadow PHY_CONTROL
register value (which should match what we've j
From: Ville Syrjälä
When fractional m2 divider isn't used on CHV the fractional part
is ignore by the hardware. Despite that, program the fractional
value (0 in this case) to the hardware register just to keep
things a bit more consistent. Might at least make register dumps
a bit less confusing w
From: Ville Syrjälä
The docs give you the impression that the unique transition scale
value shouldn't matter when unique transition scale is enabled. But
as Imre found on BXT (and I verfied also on BSW) the value does
matter. So from now on just program the same value 0x9a always.
Cc: Imre Deak
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
From: Ville Syrjälä
Add vlv_dport_to_phy() and fix up the return values of
vlv_dport_to_channel() and vlv_pipe_to_channel() to use
the appropriate enums.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
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ä
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
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
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
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
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
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 +
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 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
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: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
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 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
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 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,
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
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
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
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
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
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;
> >
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 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 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 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 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
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
> -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
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
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
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
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
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 :
> 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
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,
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
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
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
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, 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.
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
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
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
> >>>
> >>
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+
>
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 |
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
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
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
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
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
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 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 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
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 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
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
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
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
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,
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
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 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
1 - 100 of 132 matches
Mail list logo
