> drm/i915: add DP 1.2 MST support (v0.7)
>
> This adds DP 1.2 MST support on Haswell systems.
>
I've attached a patch that might fix this, please test and let me know.
Dave.
From d407c946fbf5c48f30160591f5bd71fbe158aeb4 Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date: Mon, 1 Sep 2014 16:
On Mon, 2014-09-01 at 17:02 +1000, Dave Airlie wrote:
> > drm/i915: add DP 1.2 MST support (v0.7)
> >
> > This adds DP 1.2 MST support on Haswell systems.
> >
> I've attached a patch that might fix this, please test and let me know.
Lappy hasn't exploded in 20 boot cycles, which judging b
From: Ville Syrjälä
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ä
Date: Mon Aug 11 13:15:35 2014 +0300
dr
On Thu, Jul 10, 2014 at 08:31:21PM +0100, Chris Wilson wrote:
> Rewrite commit 31685c258e0b0ad6aa486c5ec001382cf8a64212
> Author: Deepak S
> 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
On Thursday 28 August 2014 11:00 AM, Daniel Vetter wrote:
On Fri, Aug 29, 2014 at 08:45:21AM +0530, Deepak S wrote:
On Tuesday 26 August 2014 07:24 PM, Daniel Vetter wrote:
On Fri, Aug 22, 2014 at 08:32:40AM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
Programing GT IER interrupts
On Mon, Sep 01, 2014 at 11:23:20AM +0300, Ville Syrjälä wrote:
> On Thu, Jul 10, 2014 at 08:31:21PM +0100, Chris Wilson wrote:
> > Rewrite commit 31685c258e0b0ad6aa486c5ec001382cf8a64212
> > Author: Deepak S
> > Date: Thu Jul 3 17:33:01 2014 -0400
> >
> > drm/i915/vlv: WA for Turbo and RC6
On Fri, Aug 15, 2014 at 01:22:03AM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> In my earlier rewrite I missed a few important registers. Thomas Richter
> noticed that they're needed to make his machine resume correctly.
>
> Looks like IEGD does a one time init of these
On Fri, Aug 15, 2014 at 01:22:05AM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The spec says:
> "For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata,
> GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31
> (DPLL VCO Enable) and Bit 30 (2X Clock E
Hi Dave,
drm-intel-next-2014-08-22:
- basic code for execlist, which is the fancy new cmd submission on gen8. Still
disabled by default (Ben, Oscar Mateo, Thomas Daniel et al)
- remove the useless usage of console_lock for I915_FBDEV=n (Chris)
- clean up relations between ctx and ppgtt
- clean u
On Mon, Sep 01, 2014 at 11:09:46AM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 208bf9fdcd3575aa4a5
On Fri, Aug 15, 2014 at 10:57:21AM +0300, Ville Syrjälä wrote:
> On Fri, Aug 15, 2014 at 01:21:52AM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Thomas asked me to repost my 830/ns2501 patches. So here they are. I added
> > a few more patches (trickle feed and unuse
On Sun, Aug 31, 2014 at 08:32:55PM +0100, Siluvery, Arun wrote:
> On 30/08/2014 16:50, Damien Lespiau wrote:
> >Hi Arun,
> >
> >I've compiled a few patches that I think solve some small-ish issues around
> >your wa_regs series. Could you please have a look at them and comment/give
> >your
> >r-b t
On Mon, Sep 01, 2014 at 05:02:51PM +1000, Dave Airlie wrote:
> > drm/i915: add DP 1.2 MST support (v0.7)
> >
> > This adds DP 1.2 MST support on Haswell systems.
> >
> I've attached a patch that might fix this, please test and let me know.
>
> Dave.
> From d407c946fbf5c48f30160591f5bd71fb
On 01/09/2014 10:08, Daniel Vetter wrote:
On Sun, Aug 31, 2014 at 08:32:55PM +0100, Siluvery, Arun wrote:
On 30/08/2014 16:50, Damien Lespiau wrote:
Hi Arun,
I've compiled a few patches that I think solve some small-ish issues around
your wa_regs series. Could you please have a look at them an
On Mon, Sep 01, 2014 at 09:50:22AM +0100, Chris Wilson wrote:
> On Mon, Sep 01, 2014 at 11:09:46AM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When intel_tv_detect() fails to do load detection it would forget to
> > drop the locks and clean up the acquire context.
On Mon, Sep 01, 2014 at 12:45:56PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 01, 2014 at 09:50:22AM +0100, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index 32186a6..a109b7b 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++
From: Ville Syrjälä
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ä
Date: Mon Aug 11 13:15:35 2014 +0300
dr
On Mon, Sep 01, 2014 at 01:07:40PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 208bf9fdcd3575aa4a5
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 Syrjälä
> >
> > When intel_tv_detect() fails to do load detection it would forget to
> > drop the locks and clean up the acquire context.
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 Syrjälä
> > >
> > > When intel_tv_detect() fails to do load dete
On 30/08/2014 16:50, Damien Lespiau wrote:
Those debugfs files are prefixed by i915, the name of the kernel module,
presumably to make the difference with files exposed by core DRM.
Also, add a ',' at the end of the last entry. This is to ease the
conflict resolution when rebasing internal patch
There is no need to use hex_dump_to_buffer() since we have a kernel helper to
dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
Reviewed-by: Antti Koskipaa
--
- Antti
On 08/18/2014 10:16 PM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VLV/CHV have a per-pipe panel power sequencer which locks onto the
> port once used. We need to keep track wich power sequencers are
> locked to which ports.
>
> Sign
I tried building the xorg intel ddx driver with only DRI3 support,
with DRI1 and DRI2 disabled.
glxinfo says direct rendering is enabled, but gives no core contexts*.
gnome-shell appears to be using software fallback, generally there
seems to be no hardware acceleration. I'm wondering if DRI3
On 30/08/2014 16:51, Damien Lespiau wrote:
We have CHV code that already makes the test obsolete. Besides, when
num_wa_regs is 0 (platforms not gathering that W/A data), we expose
something sensible already.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 -
1 f
On Tue, Aug 12, 2014 at 09:36:03AM +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.
My only real concern here is wh
On Mon, Sep 01, 2014 at 03:05:26PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 12, 2014 at 09:36:03AM +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 th
On Mon, 01 Sep 2014, Andy Shevchenko wrote:
> There is no need to use hex_dump_to_buffer() since we have a kernel helper to
> dump up to 64 bytes just via printk(). In our case the actual size is 15
> bytes.
Reviewed-by: Jani Nikula
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/i9
On Tue, Aug 26, 2014 at 10:11:07AM +0200, Daniel Vetter wrote:
> On Tue, Aug 26, 2014 at 10:10:09AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 19, 2014 at 02:21:21PM -0700, clinton.a.tay...@intel.com wrote:
> > > From: Clint Taylor
> > >
> > > Pixel replicated modes should be 720 horizontal pixe
On Mon, Sep 01, 2014 at 04:12:27PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 26, 2014 at 10:11:07AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 26, 2014 at 10:10:09AM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 19, 2014 at 02:21:21PM -0700, clinton.a.tay...@intel.com
> > > wrote:
> > > > From: C
On Tue, Aug 19, 2014 at 02:21:21PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Pixel replicated modes should be 720 horizontal pixel and pixel
> replicated by the HW across the HDMI cable at 2X pixel clock. Current
> horizontal resolution of 1440 does not allow pixel duplica
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 vma
which will call drm_gem_vm_close() and attempt to reacquire
th
On Mon, 2014-09-01 at 17:02 +1000, Dave Airlie wrote:
> From: Dave Airlie
> Date: Mon, 1 Sep 2014 16:58:12 +1000
> Subject: [PATCH] drm/i915: handle G45/GM45 pulse detection connected
> state.
>
> In the HPD pulse handler we check for long pulses if the port is
> actually
> connected, however we
The patches that initialize workarounds for BDW and CHV using LRIs
are already merged in the tree but I received few more comments
from Chris and Damien.
I have reworked these patches as per their comments; it fixes
some issues and the code now looks clean. we can easily add
more workarounds with
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
very clean and new w/a can be added with minimal changes.
The same array can be used when exporting them to debugfs and th
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 41 +
From: Damien Lespiau
We have CHV code that already makes the test obsolete. Besides, when
num_wa_regs is 0 (platforms not gathering that W/A data), we expose
something sensible already.
Signed-off-by: Damien Lespiau
Reviewed-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 -
From: Damien Lespiau
Those debugfs files are prefixed by i915, the name of the kernel module,
presumably to make the difference with files exposed by core DRM.
Also, add a ',' at the end of the last entry. This is to ease the
conflict resolution when rebasing internal patches that add a member a
Rework of the test as kernel patch is modified.
Arun Siluvery (1):
igt/gem_workarounds: rework igt to test workaround registers
Damien Lespiau (1):
gem_workarounds: intel_wa_registers is now prefixed with i915
tests/gem_workarounds.c | 46 --
1 fi
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; we can use this dat
From: Damien Lespiau
Signed-off-by: Damien Lespiau
---
tests/gem_workarounds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
index 6826562..32156d2 100644
--- a/tests/gem_workarounds.c
+++ b/tests/gem_workarounds.c
@@ -184,
On Mon, Sep 01, 2014 at 02:28:53PM +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: A
Hi
On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson wrote:
> 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 e
On Mon, Sep 01, 2014 at 02:29:47PM +0100, Arun Siluvery wrote:
> 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 e
On Mon, 01 Sep 2014, Imre Deak wrote:
> On Mon, 2014-09-01 at 17:02 +1000, Dave Airlie wrote:
>> From: Dave Airlie
>> Date: Mon, 1 Sep 2014 16:58:12 +1000
>> Subject: [PATCH] drm/i915: handle G45/GM45 pulse detection connected
>> state.
>>
>> In the HPD pulse handler we check for long pulses if
On Mon, Sep 01, 2014 at 04:11:43PM +0200, David Herrmann wrote:
> Hi
>
> On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson wrote:
> > 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 inclu
Hi
On Mon, Sep 1, 2014 at 4:19 PM, Chris Wilson wrote:
> On Mon, Sep 01, 2014 at 04:11:43PM +0200, David Herrmann wrote:
>> Hi
>>
>> On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson
>> wrote:
>> > Showing who is the current master is useful for trying to decypher
>> > errors when trying to acquire
On 01/09/2014 15:06, Damien Lespiau wrote:
On Mon, Sep 01, 2014 at 02:28:53PM +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 driv
On Mon, Sep 01, 2014 at 03:45:29PM +0100, Siluvery, Arun wrote:
> >>+ /*
> >>+* Most of workarounds are masked registers;
> >>+* to set a bit in lower 16-bits we set a mask bit in
> >>+* upper 16-bits so we can take either of them as mask but
> >>+
From: Ville Syrjälä
No point in calling intel_plane_restore() in .set_property() if the
value didn't change.
More importantly this papers over a bug where the current primary plane
code forgets to update the user coordinates we store under intel_plane
unless the primary plane .update_plane() hoo
On Mon, Sep 01, 2014 at 06:08:25PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No point in calling intel_plane_restore() in .set_property() if the
> value didn't change.
>
> More importantly this papers over a bug where the current primary plane
> code forgets to update
Daniel:
I'm encountering a problem with the drm-intel-nightly branch in your
drm-intel repository. The symptom is that when I boot my laptop, at
some point during the start-up procedure the screen goes totally blank,
as though the backlight were turned off, and it remains that way. I
can't tell
On Mon, Sep 01, 2014 at 04:19:23PM -0400, Alan Stern wrote:
> Daniel:
>
> I'm encountering a problem with the drm-intel-nightly branch in your
> drm-intel repository. The symptom is that when I boot my laptop, at
> some point during the start-up procedure the screen goes totally blank,
> as thoug
On Mon, 1 Sep 2014, Damien Lespiau wrote:
> On Mon, Sep 01, 2014 at 04:19:23PM -0400, Alan Stern wrote:
> > Daniel:
> >
> > I'm encountering a problem with the drm-intel-nightly branch in your
> > drm-intel repository. The symptom is that when I boot my laptop, at
> > some point during the start
54 matches
Mail list logo
