Showing who is the current master is useful for trying to decypher
errors when trying to acquire master (e.g. a race with X taking over
from plymouth). By including the process name as well as the pid
simplifies the task of grabbing enough information remotely at the point
of error.
v2: Add the
On Mon, Sep 01, 2014 at 04:16:59PM +0100, Damien Lespiau wrote:
Cc: Thomas Wood thomas.w...@intel.com
Cc: Sonika Jindal sonika.jin...@intel.com
Tested-by: Mika Kuoppala mika.kuopp...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Damien Lespiau
During release of the GEM object we hold the struct_mutex. As the
object may be holding onto the last reference for the task-mm,
calling mmput() may trigger exit_mmap() which close the vma
which will call drm_gem_vm_close() and attempt to reacquire
the struct_mutex. In order to avoid that
On Mon, 01 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Sep 01, 2014 at 01:36:37PM +0300, Ville Syrjälä wrote:
On Mon, Sep 01, 2014 at 11:20:09AM +0100, Chris Wilson wrote:
On Mon, Sep 01, 2014 at 01:07:40PM +0300, ville.syrj...@linux.intel.com
wrote:
From: Ville
On Tue, Sep 02, 2014 at 10:41:05AM +0300, Jani Nikula wrote:
On Mon, 01 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Sep 01, 2014 at 01:36:37PM +0300, Ville Syrjälä wrote:
On Mon, Sep 01, 2014 at 11:20:09AM +0100, Chris Wilson wrote:
On Mon, Sep 01, 2014 at 01:07:40PM
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Also hookup the force() callback for audio detection when the user
forces the connection
Both gmch and pch detection routines used the exact same routine for
eDP, so de-duplicate.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_dp.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Implement connector-force() callback so that edid is associated
with the connector for user
On Tue, Sep 02, 2014 at 11:16:12AM +0300, Ville Syrjälä wrote:
On Tue, Sep 02, 2014 at 10:41:05AM +0300, Jani Nikula wrote:
On Mon, 01 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Sep 01, 2014 at 01:36:37PM +0300, Ville Syrjälä wrote:
On Mon, Sep 01, 2014 at 11:20:09AM
This rework is based on suggestion from Chris.
Now w/a are organized in an array and all of them are emitted in
single fn instead of sending them individually. This approach is
clean and new w/a can be added with minimal changes.
The same array can be used when exporting them to debugfs and the
Now w/a are organized in an array so we know exactly how many of them
are applied; use the same array while exporting data to debugfs and
remove the temporary array we currently have in driver priv structure.
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
kernel patch that exports w/a data to debugfs is reworked so
update igt accordingly.
Address review comments from Damien.
- if kernel is not exposing w/a data instead of failing just skip instead.
- if the platform is not exposing w/a table then no of workarounds
applied are 0, use this data to
On Mon, Sep 01, 2014 at 02:23:17PM +0100, Tvrtko Ursulin wrote:
On 08/07/2014 02:20 PM, Chris Wilson wrote:
During release of the GEM object we hold the struct_mutex. As the
object may be holding onto the last reference for the task-mm,
calling mmput() may trigger exit_mmap() which close the
On Tue, Sep 02, 2014 at 11:35:00AM +0200, Daniel Vetter wrote:
On Mon, Sep 01, 2014 at 02:23:17PM +0100, Tvrtko Ursulin wrote:
On 08/07/2014 02:20 PM, Chris Wilson wrote:
During release of the GEM object we hold the struct_mutex. As the
object may be holding onto the last reference for
On Tue, Sep 02, 2014 at 10:14:17AM +0100, Arun Siluvery wrote:
This rework is based on suggestion from Chris.
Now w/a are organized in an array and all of them are emitted in
single fn instead of sending them individually. This approach is
clean and new w/a can be added with minimal changes.
On Tue, Sep 02, 2014 at 10:45:45AM +0100, Damien Lespiau wrote:
There's one case when this won't work, when several WAs for a single
'normal' register are defined. The read done here means only the last of
those W/As will end up being applied (because the last LRI to that
register will be the
On Tue, Sep 02, 2014 at 10:45:45AM +0100, Damien Lespiau wrote:
On Tue, Sep 02, 2014 at 10:14:17AM +0100, Arun Siluvery wrote:
This rework is based on suggestion from Chris.
Now w/a are organized in an array and all of them are emitted in
single fn instead of sending them individually. This
On Tue, Sep 02, 2014 at 10:15:31AM +0100, Arun Siluvery wrote:
Now w/a are organized in an array so we know exactly how many of them
are applied; use the same array while exporting data to debugfs and
remove the temporary array we currently have in driver priv structure.
Signed-off-by: Arun
From: Ville Syrjälä ville.syrj...@linux.intel.com
When intel_tv_detect() fails to do load detection it would forget to
drop the locks and clean up the acquire context. Fix it up.
This is a regression from:
commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44
Author: Ville Syrjälä
On Tue, Sep 02, 2014 at 10:18:20AM +0100, Arun Siluvery wrote:
- igt_assert(fd = 0);
+ if (fd 0)
+ igt_skip_on(No Workaround table available !!\n);
That's not quite a correct use of the API. The _on is there to signal
the first argument is an
Hello,
Is this patch going to be split up into more manageable pieces? I tried
to apply it to a tree fetched yesterday and got a very large number of
conflicts. I don't know whether that is because more execlist patches
have been merged or if it is other random changes that have broken it or
On Tue, Sep 02, 2014 at 09:24:48AM +0100, Chris Wilson wrote:
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Also hookup the force()
On Tue, Sep 02, 2014 at 10:59:06AM +0100, Damien Lespiau wrote:
On Tue, Sep 02, 2014 at 10:18:20AM +0100, Arun Siluvery wrote:
- igt_assert(fd = 0);
+ if (fd 0)
+ igt_skip_on(No Workaround table available !!\n);
That's not quite a correct use of the
On Tue, Sep 02, 2014 at 01:04:34PM +0200, Daniel Vetter wrote:
On Tue, Sep 02, 2014 at 10:59:06AM +0100, Damien Lespiau wrote:
On Tue, Sep 02, 2014 at 10:18:20AM +0100, Arun Siluvery wrote:
- igt_assert(fd = 0);
+ if (fd 0)
+ igt_skip_on(No Workaround
On Tue, 02 Sep 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When intel_tv_detect() fails to do load detection it would forget to
drop the locks and clean up the acquire context. Fix it up.
This is a regression from:
commit
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the GPU frequency isn't going to change don't spam dmesg with
debug messages about it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 13 +++--
1 file changed, 7 insertions(+), 6
On Tue, 02 Sep 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the GPU frequency isn't going to change don't spam dmesg with
debug messages about it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Oh yes please!
Reviewed-by: Jani
On Tue, Sep 02, 2014 at 03:12:17PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the GPU frequency isn't going to change don't spam dmesg with
debug messages about it.
I'd be more worried about why. gen6_rps_idle()?
-Chris
--
Chris Wilson,
On Tue, 02 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Sep 02, 2014 at 11:35:00AM +0200, Daniel Vetter wrote:
On Mon, Sep 01, 2014 at 02:23:17PM +0100, Tvrtko Ursulin wrote:
On 08/07/2014 02:20 PM, Chris Wilson wrote:
During release of the GEM object we hold the
On Tue, 2014-08-19 at 20:32 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Introduce a new mutex (pps_mutex) to protect the power sequencer
state. For now this state includes want_panel_vdd as well as the
power sequencer registers.
We need a
On Tue, Sep 02, 2014 at 01:45:29PM +0100, Chris Wilson wrote:
On Tue, Sep 02, 2014 at 03:12:17PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the GPU frequency isn't going to change don't spam dmesg with
debug messages about it.
I'd
On Tue, Sep 02, 2014 at 12:12:28PM +0100, Chris Wilson wrote:
On Tue, Sep 02, 2014 at 01:04:34PM +0200, Daniel Vetter wrote:
On Tue, Sep 02, 2014 at 10:59:06AM +0100, Damien Lespiau wrote:
On Tue, Sep 02, 2014 at 10:18:20AM +0100, Arun Siluvery wrote:
- igt_assert(fd = 0);
How about throwing this at any eDP link parameter bugs and regressions?
Does it feel too much like giving up the battle?
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d7fc2c0e9ba8..f112d7d2f8bd 100644
---
On Fri, 2014-08-22 at 17:21 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The power sequencer loses its state when the disp2d power well is down.
Clear the dev_priv-pps_pipe tracking so that the power sequencer state
gets reinitialized the next
On Tue, Sep 02, 2014 at 04:17:34PM +0300, Ville Syrjälä wrote:
On Tue, Sep 02, 2014 at 01:45:29PM +0100, Chris Wilson wrote:
On Tue, Sep 02, 2014 at 03:12:17PM +0300, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the GPU frequency isn't
On Tue, Sep 02, 2014 at 04:46:55PM +0300, Ville Syrjälä wrote:
On Tue, Sep 02, 2014 at 04:17:34PM +0300, Ville Syrjälä wrote:
On Tue, Sep 02, 2014 at 01:45:29PM +0100, Chris Wilson wrote:
On Tue, Sep 02, 2014 at 03:12:17PM +0300, ville.syrj...@linux.intel.com
wrote:
From: Ville
On Mon, 2014-08-18 at 22:16 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Try to make sure we find the power sequencer that the BIOS used
by first looking for one which has the panel power enabled, then
fall back to one with VDD force bit
When we idle, we set the GPU frequency to minimum. This should be a
safety blanket as the pcu on the GPU should be power gating itself
anyway. However, in order for us to do set the absolute minimum
frequency, we need to relax a few of our assertions that we do not
exceed the user limits.
Rewrite commit 31685c258e0b0ad6aa486c5ec001382cf8a64212
Author: Deepak S deepa...@linux.intel.com
Date: Thu Jul 3 17:33:01 2014 -0400
drm/i915/vlv: WA for Turbo and RC6 to work together.
Other than code clarity, the major improvement is to disable the extra
interrupts generated when idle.
Use both up/down manual ei calcuations for symmetry and greater
flexibility for reclocking, instead of faking the down interrupt based
on a fixed integer number of up interrupts.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to display continuously updating information 24/7, and so
some code to
If we successfully confuse the hardware, and cause it to drop a queued
pageflip, we wait for 60s and issue a warning before continuing on with
the modeset. However, this leaves the pending pageflip still stuck
indefinitely. Pretend to userspace that it does complete, and let us
start afresh
Reuse the same reclocking strategy for Baytail as on its bigger brethren,
Sandybridge and Ivybridge. In particular, this makes the device quicker
to reclock (both up and down) though the tendency now is to downclock
more aggressively to compensate for the RPS boosts.
Signed-off-by: Chris Wilson
If we hit a vblank and see that have a pageflip queue but not yet
processed, ensure that the GPU is running at maximum in order to clear
the backlog. Pageflips are only queued for the following vblank, if we
miss it, there will be a visible stutter. Boosting the GPU frequency
doesn't prevent us
Only allow each client to perform one RPS boost in each period of GPU
activity.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 8 +---
drivers/gpu/drm/i915/i915_gem.c | 18 ++
drivers/gpu/drm/i915/i915_gem_request.c
The goal is to refactor the Cherryview special casing to only be in a
single location. To do so we need to compute the desired adjustment and
then tweak it for Cherryview. This has the minor side-effect of making
sure we set adj to 0 if we directly update the target frequency.
Ensuring that the
On Mon, 2014-08-18 at 22:16 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On VLV/CHV the panel power sequencer may need to be kicked a bit to
lock onto the new port, and that needs to happen before any aux
transfers are attempted if we want the
Since this mask is only used in conjunction with RPS, move it alongside
its brethen in the i915-rps struct.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 35 +--
On Tue, Sep 02, 2014 at 02:57:36PM +0100, Chris Wilson wrote:
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to
On Tue, Sep 02, 2014 at 05:31:22PM +0300, Ville Syrjälä wrote:
On Tue, Sep 02, 2014 at 02:57:36PM +0100, Chris Wilson wrote:
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating.
On Tue, Sep 02, 2014 at 04:33:52PM +0300, Jani Nikula wrote:
Signed-off-by: Jani Nikula jani.nik...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On Tue, Sep 02, 2014 at 02:57:36PM +0100, Chris Wilson wrote:
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to
On Tue, Sep 02, 2014 at 04:52:54PM +0200, Daniel Vetter wrote:
On Tue, Sep 02, 2014 at 02:57:36PM +0100, Chris Wilson wrote:
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating.
On Tue, 02 Sep 2014, Jani Nikula jani.nik...@intel.com wrote:
How about throwing this at any eDP link parameter bugs and regressions?
Does it feel too much like giving up the battle?
Fixes at least one bug...
https://bugs.freedesktop.org/show_bug.cgi?id=79386#c15
Signed-off-by: Jani Nikula
Hi!
From: ville.syrj...@linux.intel.com Sent: Monday, September 01, 2014 at 12:07 PM
When intel_tv_detect() fails to do load detection it would forget to
drop the locks and clean up the acquire context. Fix it up.
This is a regression from:
commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44
Both gmch and pch detection routines used the exact same routine for
eDP, so de-duplicate.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: : Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 38 +-
1 file
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Implement connector-force() callback so that edid is associated
with the connector for user
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
v2: Also hookup the force() callback for audio detection when the user
forces the connection
The routines for deciding whether we have audio (depending upon
force_audio and the associated EDID) are common between detection and
set-property. Refactor the code to remove the duplication.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_hdmi.c | 60
Similar to the previous commit for HDMI, refector the common routine
for setting the audio flags between detection and set-property.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_dp.c | 47 ++---
1 file changed, 21
On Tue, Sep 02, 2014 at 08:04:02PM +0100, Chris Wilson wrote:
The routines for deciding whether we have audio (depending upon
force_audio and the associated EDID) are common between detection and
set-property. Refactor the code to remove the duplication.
Signed-off-by: Chris Wilson
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_drv.h | 20
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
From: Derek Foreman derek.fore...@collabora.co.uk
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman derek.fore...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_sprite.c | 8
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
At this point of the code the obj var is already NULL, so we don't
need to set it again to NULL.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 1 -
1 file changed, 1 deletion(-)
Hi Ville,
went through the vblank rework patch set, mostly looks good to me. I
couldn't find any bugs in the code. A first quick test-run on my old
Intel GMA-950 (Gen 3'ish i think?) also didn't show apparent problems
with the OML_sync_control functions. I'll try to test more carefully
with
From: Paulo Zanoni paulo.r.zan...@intel.com
Currently, CHV is using the same functions as HSW/BDW instead of the
same functions as VLV. This looks wrong, especially since, for
example, valleyview_modeset_global_resouces even has an IS_CHERRYVIEW
check.
This patch has the potential to fix display
On Fri, Aug 08, 2014 at 04:23:39PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Rename the defines to have levels instead of values for vswing and pre-emph
levels as the values may differ in other scenarios like low vswing of eDP 1.4
where the values are
Expose an ioctl to create Android fences based on the Android sync point
infrastructure (which in turn is based on DMA-buf fences). Just a
sketch at this point, no testing has been done.
There are a couple of goals here:
1) allow applications and libraries to create fences without an
This set includes a sketch of how we might allow fences to be emitted
directly within a batch buffer. This gets rid of the need for flushing
around fence operations, which can be a win, and lets userspace more
finely control things.
If it looks reasonable, we could drop the separate ioctl and
Use a new reloc type to allow userspace to insert sync points within
batches before they're submitted. The corresponding fence fds are
returned in the offset field of the returned reloc tree, and can be
operated on with the sync fence APIs.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
From: Clint Taylor clinton.a.tay...@intel.com
Enable 2x pixel replication for modes the mode flag DBLCLK to double
horizontal timings and pixel clock across TMDS.
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä
From: Clint Taylor clinton.a.tay...@intel.com
Split original drm_edid.c changes and intel_hdmi.c HDMI pixel
replciation changes into separate patches.
Clint Taylor (2):
drm/edid: Reduce horizontal timings for pixel replicated modes
drm/i915/hdmi: Enable pipe pixel replication for SD
From: Clint Taylor clinton.a.tay...@intel.com
Pixel replicated modes should be non-2x horizontal timings and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV.
On 08/27/2014 01:54 PM, Runyan, Arthur J wrote:
:-) We pulled most of the mobile functions from the bridge chip into the main
chip, so that same backlight code might well have been there.
From sandybridge onwards I see that hardware will override the PWM signal to
inactive (0 if backlight
From: Dave Airlie airl...@redhat.com
This adds MST support to the UXA paths in the driver.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/uxa/intel.h | 1 +
src/uxa/intel_display.c | 345 +++-
src/uxa/intel_driver.c | 4 +-
3 files
From: Dave Airlie airl...@redhat.com
This will cause problems with MST displays.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/uxa/intel_display.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/src/uxa/intel_display.c
VLV is a whole different can of worms. Some parts of display are from before
sanybridge, and it may have some special muxing on the backlight pins. I won't
be able to give any feedback on how hardware behaves there.
-Original Message-
From: Taylor, Clinton A
Sent: Tuesday, September
79 matches
Mail list logo
