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 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-by: Ville Syrjälä
Any reason you didn't roll this out for all the encoder
On Tue, Dec 08, 2015 at 09:55:27PM +0100, Julia Lawall wrote:
> The intel_dvo_dev_ops structures are never modified, so declare them as
> const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Queued for -next, thanks for the patch.
-Daniel
>
> ---
> drivers/gpu/drm/i91
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
drivers/gpu/drm/i915/intel_dsi.c | 16 +---
2 files changed, 17 i
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 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.
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
Signed-off-by: Gaurav K Singh
Signed-off-by: Deepak M
---
drivers/gpu/d
From: Daniel Vetter
For render compression, userspace passes aux stride and offset values as an
additional entry in the fb structure. This should not be treated as garbage
and discarded as data belonging to no plane.
This patch introduces a check related to AUX plane to support the
scenario of re
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 fail, the flip will fail.
TODO:
1. Disable stereo 3D when render
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commits:
344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
6704d4552853 ("drm/i915/skl: Double RC6 WRL always on")
from the drm-intel-fixes tree and commit:
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 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
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
case timeout happens, driver can return early in order to handle the
error.
---
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.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/intel_ddi.c |2 +-
dr
We can never be passed a NULL crtc_state (and if we could there are
plenty of other places later in this function where we access it
without testing for NULL).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
In all of our various SDVO setup functions, we allocate an SDVO
connector (along with an associated connector->state) object, then
perform initialization. If that initialization fails, we need to make
sure to free the state object as well as the connector.
Signed-off-by: Matt Roper
---
drivers/
The intel_dvo_dev_ops structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/i915/dvo.h| 12 ++--
drivers/gpu/drm/i915/dvo_ch7017.c |2 +-
drivers/gpu/drm/i915/dvo_ch7xxx.c |2 +-
driv
On Tue, Dec 08, 2015 at 11:07:01PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 08, 2015 at 08:50:48PM +, Chris Wilson wrote:
> > On Tue, Dec 08, 2015 at 07:45:50PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 08, 2015 at 09:38:52AM -0800, Wayne Boyer wrote:
> > > > Do some further clean up based
On Tue, Dec 08, 2015 at 08:50:48PM +, Chris Wilson wrote:
> On Tue, Dec 08, 2015 at 07:45:50PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 08, 2015 at 09:38:52AM -0800, Wayne Boyer wrote:
> > > Do some further clean up based on the initial review of
> > > drm/i915: Separate cherryview from vall
On Tue, Dec 08, 2015 at 07:45:50PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 08, 2015 at 09:38:52AM -0800, Wayne Boyer wrote:
> > Do some further clean up based on the initial review of
> > drm/i915: Separate cherryview from valleyview.
> >
> > In this case, in i915_gem_alloc_context_obj() only ca
On ma, 2015-12-07 at 16:40 +0200, Ville Syrjälä wrote:
> On Fri, Dec 05, 2014 at 11:23:29PM +0200, Ville Syrjälä wrote:
> > On Thu, Dec 04, 2014 at 06:39:35PM +0200, Imre Deak wrote:
> > > As described in the code comment, I couldn't set the minimum RPS
> > > frequency on my BYT-M B0 to the minimum
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 .is_cherryv
2015-12-08 11:42 GMT-02:00 Ville Syrjälä :
> On Tue, Dec 08, 2015 at 10:50:39AM +0200, David Weinehall wrote:
>> Since the defaults for some external power management related settings
>> prevents us from testing our power management functionality properly,
>> we have to work around it. Currently th
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 handling its own object
locations (for example a
On 08/12/15 17:00, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 04:51:17PM +, Dave Gordon wrote:
In various places, one or more pages of a GEM object are 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
On 08/12/15 17:03, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 04:51:18PM +, Dave Gordon wrote:
This patch covers a couple more places where a GEM object is (or may be)
modified by means of CPU writes, and should therefore be marked dirty to
ensure that the changes are not lost in the evenof
Hi Ville,
[auto build test WARNING on next-20151208]
[cannot apply to drm-intel/for-linux-next v4.4-rc4 v4.4-rc3 v4.4-rc2 v4.4-rc4]
url:
https://github.com/0day-ci/linux/commits/ville-syrjala-linux-intel-com/drm-i915-Cure-DDI-from-multiple-personality-disorder/20151209-020401
config: i386
On 08/12/15 17:00, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 04:51:16PM +, Dave Gordon wrote:
In various places, a GEM object is filled with data by means of CPU
writes. In such cases, the object should be marked dirty, to ensure that
the data is not discarded if the object is evicted unde
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c47f45c0f4a2..8d8f346a9615 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/d
From: Ville Syrjälä
DDI buffer prorgramming works quite differently depending on
the mode of the DDI port (DP/eDP/FDI vs. HDMI/DVI). Let's split
the function that does the programming into two matching variants
as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c| 94
From: Ville Syrjälä
Program the 'iboost_bit' based on what the VBT says it should be for
the specific port type, rather than assume it's alwasy the same
for DP and HDMI.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-
From: Ville Syrjälä
Eliminate the troublesome role switching DDI encoder, and just register
a separate encoder for each role (DP and HDMI).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 232 +-
drivers/gpu/drm/i915/intel_display.c |
From: Ville Syrjälä
When the DDI port is in HDMI/DVI mode, it automagically uses the buffer
translations values from entry 9. Let's make that explicit in the code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
From: Ville Syrjälä
Only DDI A and E support 10 translation entries in DP mode. For the
other ports the tenth entry is reserved for HDMI..
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_d
From: Ville Syrjälä
We no longer have any need to look up the intel_digital_port based
on the passed in intel_encoder, but we still want to look up the port.
Let's just move that logic into intel_ddi_get_encoder_port() and drop
the dig_port stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/d
From: Ville Syrjälä
Move the ddi buffer translation programming to occur from the encoder
.pre_enable() hook, for just the ddi port we are enabling. Previously
we used to reprogram the translations for all ddi ports during
init and during power well enabling.
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Make the ddi buffer programming code a bit more neat by passing
around dev_priv instead of dev.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 79 +++-
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/d
From: Ville Syrjälä
Rather than having open coded checks for the DDI A/E configuration,
just store the max supported lane count in intel_digital_port.
We had an open coded check for DDI A, but not for DDI E. So we may
have been vilating the DDI E max lane count.
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
The DDI translation tables are supposed to be of certain size,
so let's add some compile time asserts to enforce that..
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i91
From: Ville Syrjälä
skl_get_buf_trans_*() don't need the 'ddi_translations' local variable
since all they with is assign and return. Just return the right thing
directly and get rid of the local variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 44 +++---
From: Ville Syrjälä
skl_get_buf_trans_edp() effectively contains another copy of
skl_get_buf_trans_dp(). Remove the duplication and just call
skl_get_buf_trans_dp() from skl_get_buf_trans_edp().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 21 +
1 fi
From: Ville Syrjälä
DDI A and E share some of the lanes, so check that we have enough
lanes for the purpose we need before registering the encoders.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 36
1 file changed, 36 insertions(+)
di
From: Ville Syrjälä
While debugging problems on DDI platforms I got tired of the crap
caused by the the dual personality DDI encoders, so I went ahead
and split them into separate HDMI and DP encoders.
As usual, the hole got a bit deeper after I noticed that I had to
kill intel_prepare_ddi() as
From: Ville Syrjälä
We're supposed to pass the primary DP encoder to intel_ddi_clk_select(),
not the fake MST encoder. Do so.
There's no real bug here though, since intel_ddi_clk_select() only
checks if the encoder type is EDP (which it isn't for either the
primary DP encoder or the fake MST enc
On Tue, Dec 08, 2015 at 09:38:52AM -0800, Wayne Boyer wrote:
> Do some further clean up based on the initial review of
> drm/i915: Separate cherryview from valleyview.
>
> In this case, in i915_gem_alloc_context_obj() only call
> i915_gem_object_set_cache_level() for Ivy Bridge devices
> since lat
On Mon, 07 Dec 2015 10:41:51 +0100,
Takashi Iwai wrote:
>
> On Mon, 07 Dec 2015 09:44:45 +0100,
> Daniel Vetter wrote:
> >
> > On Fri, Dec 04, 2015 at 06:12:47PM +0100, Takashi Iwai wrote:
> > > This patch adds a reverse mapping from a digital port number to
> > > intel_encoder object containing
Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.
In this case, in i915_gem_alloc_context_obj() only call
i915_gem_object_set_cache_level() for Ivy Bridge devices
since later platforms don't have L3 control bits in the PTE.
v2: Expand comment t
On Tue, Dec 08, 2015 at 04:51:18PM +, Dave Gordon wrote:
> This patch covers a couple more places where a GEM object is (or may be)
> modified by means of CPU writes, and should therefore be marked dirty to
> ensure that the changes are not lost in the evenof of the object is
> evicted under me
On Tue, Dec 08, 2015 at 04:51:17PM +, Dave Gordon wrote:
> In various places, one or more pages of a GEM object are 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
On Tue, Dec 08, 2015 at 04:51:16PM +, Dave Gordon wrote:
> In various places, a GEM object is filled with data by means of CPU
> writes. In such cases, the object should be marked dirty, to ensure that
> the data is not discarded if the object is evicted under memory
> pressure.
>
> This incor
In various places, a GEM object is filled with data by means of CPU
writes. In such cases, the object should be marked dirty, to ensure that
the data is not discarded if the object is evicted under memory
pressure.
This incorporates and supercedes Alex Dai's earlier patch
[PATCH v1] drm/i915/guc:
This patch covers a couple more places where a GEM object is (or may be)
modified by means of CPU writes, and should therefore be marked dirty to
ensure that the changes are not lost in the evenof of the object is
evicted under memory pressure.
It may be possible to optimise these paths later, by
In various places, one or more pages of a GEM object are 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.
Ideally, we would like
This patchset covers three variations on GEM objects being dirtied by
means of CPU writes.
The first is simple: an object has been entirely filled with data via
CPU writes, and the whole object is therefore dirty (i.e. backing store
is out-of-date w.r.t. current contents). For these cases, marking
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 55
drivers/gpu/drm/i915/intel_fbdev.c | 5 ++--
2 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/g
From: Ville Syrjälä
Call intel_plane_destroy() instead of drm_plane_cleanup() so that we
also free the plane struct itself when bailing out of the crtc init.
And make intel_plane_destroy() NULL tolerant to avoid having to check
for it in the caller.
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
v2: Fix intel_crtc leak on failure to allocate the name
Use a local 'name' variable to make things easier
v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani)
v4: Pass the printf style format string to drm_crtc_init_with_planes()
Signed-off-by: V
From: Ville Syrjälä
Deal with errors from drm_universal_plane_init() in primary and cursor
plane init paths (sprites were already covered). Also make the code
neater by using goto for error handling.
v2: Rebased due to drm_universal_plane_init() 'name' parameter
v3: Another rebase due to s/""/NU
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 38 +---
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 39ee629cb403..8
From: Ville Syrjälä
To get a better idea where exactly some error occurred during modeset,
put in some debug prints to tell us when the variuous encoder hooks are
getting called.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 58 +---
1
From: Ville Syrjälä
Let's name our planes in a way that makes sense wrt. the spec:
- skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc.
- g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc.
- pre-g4x -> "plane A", "cursor B" etc.
v2: Rebase on top of the fixed/cleaned error pa
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ä
---
drivers/gpu/drm/i915/intel_crt.c| 2 +-
drivers/gpu/drm/i915/intel_ddi.c| 2 +-
driv
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ä
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
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-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/dri
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ä
Show a sensible name for the plane in debug mesages. The driver
may supply its own name, otherwise the core genrates the name
("plane-0", "plane-1" etc.).
v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one
Signed-o
From: Ville Syrjälä
Show a sensible name for the crtc in debug mesages. The driver may
supply its own name, otherwise the core genrates the name
("crtc-0", "crtc-1" etc.).
v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one
Signed-off-
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 functions, so
that callers don't have to worry about any snprintf buff
It takes from 2 to 5 seconds to run.
Cc: Daniel Vetter
Signed-off-by: Rodrigo Vivi
---
tests/kms_psr_sink_crc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 8cd11a7..5fad9b5 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/k
Using same timeout value as kms_fronbuffer_tracking and for
same reasons exposed at 'commit 83582f9b ("kms_frontbuffer_tracking:
Increase the time we wait for PSR.")'
Signed-off-by: Rodrigo Vivi
---
tests/kms_psr_sink_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tes
On Tue, Dec 8, 2015 at 2:15 AM, Russell King - ARM Linux
wrote:
> On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote:
>> On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote:
>> > On 8 December 2015 at 08:49, Daniel Vetter wrote:
>> > > In my quest to remove all the drm_encoder
On Tue, Dec 8, 2015 at 2:45 AM, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 02:06:50AM -0800, Rodrigo Vivi wrote:
>> It takes from 2 to 5 seconds to run.
>>
>> Cc: Daniel Vetter
>> Signed-off-by: Rodrigo Vivi
>> ---
>> tests/kms_psr_sink_crc.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
Based on Chris Wilson's patch from 6 months ago, rebased and adapted.
The idea is to use ring->dev as an indicator showing which engines have
been initialised and are therefore to be included in iterations that use
for_each_ring(). This allows us to avoid multiple memory references and
a (non-inli
Based on Chris Wilson's patch from 6 months ago, rebased and adapted.
The current implementation of intel_ring_initialized() is too heavyweight;
it's a non-inlined function that chases several levels of pointers. This
wouldn't matter too much if it were rarely called, but it's used inside
the iter
On 08/12/15 14:33, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 02:03:39PM +, Tvrtko Ursulin wrote:
On 08/12/15 10:44, Chris Wilson wrote:
On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote:
Equally, why wouldn't we wake up all waiters for which the requests
have been completed?
This fixes a spurious warning from an integer overflow on 64-bits systems.
The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1.
Explicitly handling this by casting to lret fixes it.
Signed-off-by: Maarten Lankhorst
Reported-and-tested-by: Joseph Yasi
---
diff --git a/drivers/
From: Ville Syrjälä
Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
FDI RX disable both as step 13 and step 18 in the sequence. But I dug
up an old BUN mail from Art that moved the FDI RX disable to happen
before DDI_BUF_CTL disable. That BUN did not renumber the steps and jus
On Tue, Dec 08, 2015 at 02:03:39PM +, Tvrtko Ursulin wrote:
> On 08/12/15 10:44, Chris Wilson wrote:
> >On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote:
> >>Equally, why wouldn't we wake up all waiters for which the requests
> >>have been completed?
> >
> >Because we no longer tr
On Tue, Dec 01, 2015 at 03:08:31PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I was trying to get to the bottom of the FDI fails on Brix Pro, and
> thus eneded up going through the entire PCH modeset stuff for HSW.
> While I did find a bunch of stuff missing/wrong, sadl
Both patches pushed to drm-intel-next-queued, and then backported to
drm-intel-fixes with cc: stable. Thanks for the patches and review.
BR,
Jani.
On Tue, 08 Dec 2015, "Kamble, Sagar A" wrote:
> Reviewed-by: Sagar Arun Kamble
>
> On 12/7/2015 9:59 PM, Mika Kuoppala wrote:
>> There is conflict
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 is overkill.
> >
> > Signed-off-by: Maarten La
On Mon, Dec 07, 2015 at 08:57:59PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 07, 2015 at 03:51:06PM -0200, Paulo Zanoni wrote:
> > 2015-12-04 18:20 GMT-02:00 :
> > > From: Ville Syrjälä
> > >
> > > Bspec modeset sequence tells us to disable the PCH transcoder and
> > > FDI after the CRT port on L
From: Ville Syrjälä
Bspec modeset sequence tells us to disable the PCH transcoder and
FDI after the CRT port on LPT-H, so let's do that. And the CRT port
should be disabled after the pipe, as we do on other PCH platforms
too since
commit 1ea56e269e13 ("drm/i915: Disable CRT port after pipe on PCH
On 08/12/15 10:44, Chris Wilson wrote:
On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote:
Hi,
On 03/12/15 16:22, Chris Wilson wrote:
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
tran
On Tue, Dec 8, 2015 at 3:49 AM, Daniel Vetter wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
event generation?
> to implement, bu
Hello,
On Tuesday 08 December 2015 10:59:05 Pierre Moreau wrote:
> On 09:49 AM - Dec 08 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.
> >
> > Signed-off-by: Daniel Vetter
On Tue, Dec 08, 2015 at 10:50:39AM +0200, David Weinehall wrote:
> Since the defaults for some external power management related settings
> prevents us from testing our power management functionality properly,
> we have to work around it. Currently this is done from the individual
> test cases, but
All of these iterator macros require a 'temp' argument, used merely to
hold internal partial results. We can instead declare the temporary
variable inside the macro, so the caller need not provide it.
Some of the old code contained nested iterators that actually reused the
same 'temp' variable for
Way back at the beginning of October, Chris Wilson suggested that cleaning
up these macros by removing the redundant 'temp' might be worthwhile. So
here's the patch.
There's one more thing that might be cleaned up here (but for which
I don't have a patch yet), which is that gen8_for_each_pdpe() st
Em Ter, 2015-12-08 às 10:50 +0200, David Weinehall escreveu:
> Since the defaults for some external power management related
> settings
> prevents us from testing our power management functionality properly,
> we have to work around it. Currently this is done from the individual
> test cases, but t
gem_flink_race and prime_self_import have subtests which read the
number of open gem objects from debugfs to determine if objects have
leaked during the test. However the test can fail sporadically if
the number of gem objects changes due to other process activity.
This patch introduces a change to
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 buffers between
CPU and GPU. These tests rel
Hi,
On 8 December 2015 at 08:49, Daniel Vetter wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
> to implement, but userspace has a
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 buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffe
Reviewed-by: Thomas Hellstrom
On 12/04/2015 09:45 AM, Daniel Vetter wrote:
> These hooks will be gone soon.
>
> Cc: Thomas Hellstrom
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4
> drivers/gp
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 handling its own object
locations (for example along with full-ppgtt) and that the kernel will
On Tue, Dec 08, 2015 at 01:44:10PM +0200, Jani Nikula wrote:
> On Mon, 07 Dec 2015, 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 .i
On Mon, Dec 07, 2015 at 03:02:42PM -0800, Wayne Boyer wrote:
> Do some further clean up based on the initial review of
> drm/i915: Separate cherryview from valleyview.
>
> In this case remove the BUG_ON call in vlv_enable_pll().
>
> v2: Also remove the BUG_ON call in chv_enable_pll(). (Ville)
>
On Mon, Dec 07, 2015 at 10:26:15PM +, Boyer, Wayne wrote:
> On 12/7/15, 11:56 AM, "Deak, Imre" wrote:
>
>
> >On Mon, 2015-12-07 at 21:28 +0200, Ville Syrjälä wrote:
> >> On Mon, Dec 07, 2015 at 10:51:09AM -0800, Wayne Boyer wrote:
> >> > Do some further clean up based on the initial review o
On Mon, 07 Dec 2015, 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 to some confusion.
On Mon 07-12-15 14:13:46, Johannes Weiner wrote:
> On Mon, Dec 07, 2015 at 06:10:00PM +, Dave Gordon wrote:
> > Exporting random uncontrolled variables from the kernel to loaded modules is
> > not really considered best practice. It would be preferable to provide an
> > accessor function - whic
1 - 100 of 132 matches
Mail list logo
