On Tue, Mar 04, 2014 at 10:46:38AM +0530, naresh.kumar.kac...@intel.com wrote:
> From: Naresh Kumar Kachhi
>
> Based on Bspec the command parser must be stopped prior to
> issuing sync flush. Only after observing Rings Idle set in
> MI_MODE can a Sync Flush be issued. Once sync flush has
> finish
From: Naresh Kumar Kachhi
Based on Bspec the command parser must be stopped prior to
issuing sync flush. Only after observing Rings Idle set in
MI_MODE can a Sync Flush be issued. Once sync flush has
finished the command parser is re-enabled by clearing Stop Rings.
Signed-off-by: Naresh Kumar Ka
From: Mengdong Lin
A macro IS_HASWELL_PLUS(devid) is defined to cover Haswell and its successors,
for code sharing. Now it covers HSW and BDW.
Signed-off-by: Mengdong Lin
Reviewed-by: Haihao Xiang
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index faa577e..ffd8288 100644
-
From: Mengdong Lin
This patch adds support for dumping audio registers of Valleyview,
by reusing Ironlake code with a different base address and pipe number.
Signed-off-by: Mengdong Lin
Reviewed-by: Haihao Xiang
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index e36bb69..4
From: Mengdong Lin
Move these enum definitions earlier for future code sharing.
Signed-off-by: Mengdong Lin
Reviewed-by: Haihao Xiang
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 47926e4..faa577e 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@
From: Mengdong Lin
It's for future code sharing because some registers define their bit fields
according to the number of pipes.
Signed-off-by: Mengdong Lin
Reviewed-by: Haihao Xiang
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index ffd8288..8632ad3 100644
--- a/tools/int
From: Mengdong Lin
Signed-off-by: Mengdong Lin
Reviewed-by: Haihao Xiang
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index e6f6002..e36bb69 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -1344,13 +1344,13 @@ static void dump_aud_config(int index)
From: Mengdong Lin
Layout of display and audio registers can be same for different Intel GPUs.
For code sharing, this patches defines functions to
- set the base address of display and audio registers
- dump registers using the base address and an offset
Signed-off-by: Mengdong Lin
Reviewed-by:
From: Mengdong Lin
Layout of display and audio registers can be same for different Intel GPUs,
so we want maximum code sharing when adding support for VLV.
This patch set:
- support using base address plus an offset to dump registers
- share common audio dump code for Ironlake, Haswell and Broad
We allocate memory in drm_display_mode_from_vic_index() and use it
without checking the pointer is valid. Fix that.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f8
While reading some code, out of boredom, stumbled on a tiny tiny fix.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
i
This patch fixes the blank screen bug introduced in 3.14-rc1 on the
MacBook Air 6,2. The comments state that we need to force edp vdd so
lets put it back.
The regression was introduced by the following commit:
commit dff392dbd258381a6c3164f38420593f2d291e3b
Author: Paulo Zanoni
Date: Fri Dec 6
On Fri, 7 Feb 2014 18:37:01 -0200
Rodrigo Vivi wrote:
> From: Jesse Barnes
>
> The intent is to get back to userspace as quickly as possible so it can
> start doing drawing or whatever. It should also allow our
> suspend/resume/init time to improve a lot.
>
> Signed-off-by: Rodrigo Vivi
> -
On Mon, 3 Mar 2014 11:14:09 -0800
Jesse Barnes wrote:
> On Thu, 27 Feb 2014 11:01:08 +0200
> Jani Nikula wrote:
>
> > On Thu, 27 Feb 2014, Jani Nikula wrote:
> > > On Wed, 26 Feb 2014, Jesse Barnes wrote:
> > >> On Mon, 13 Jan 2014 16:25:21 +0530
> > >> akash.g...@intel.com wrote:
> > >>
>
On 14-02-28 11:28 AM, Matt Roper wrote:
On Fri, Feb 28, 2014 at 06:03:11PM +0200, Ville Syrjälä wrote:
On Thu, Feb 27, 2014 at 03:44:04PM -0800, Matt Roper wrote:
On Thu, Feb 27, 2014 at 02:36:06PM -0800, Yu Dai wrote:
On 14-02-25 04:19 PM, Matt Roper wrote:
On Thu, Feb 20, 2014 at 04:11:14
So don't try to allocate and program it, we're only fooling ourselves.
Reported-by: "Chang, Junxiao"
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index
From: "Yu(Alex) Dai"
Add "zorder" property to crtc to control Z-order of sprite and
primary planes. The alpha channel of the planes can be enabled
or disabled during Z-order change.
Signed-off-by: Yu(Alex) Dai
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h
On Mon, Mar 03, 2014 at 05:31:43PM +, Damien Lespiau wrote:
> Follow up of:
> http://lists.freedesktop.org/archives/intel-gfx/2014-February/040789.html
>
> With a couple of changes:
>
> - Fix up the poor style when initializing the per-pipe num_sprites
> - Added more for_each_pipe(pipe)
On Fri, Feb 14, 2014 at 05:41:01PM -0500, Steven Rostedt wrote:
> I get the following splat in my tests running 3.14-rc2:
>
> [3.955123] WARNING: CPU: 0 PID: 1 at
> /work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_display.c:857
> intel_wait_for_pipe_off+0x17a/0x2d0()
> [
On Thu, 27 Feb 2014 11:01:08 +0200
Jani Nikula wrote:
> On Thu, 27 Feb 2014, Jani Nikula wrote:
> > On Wed, 26 Feb 2014, Jesse Barnes wrote:
> >> On Mon, 13 Jan 2014 16:25:21 +0530
> >> akash.g...@intel.com wrote:
> >>
> >>> From: Akash Goel
> >>>
> >>> There is a conflict seen when requestin
That macro was only ever used to convert ring->private into a gem object
(hence the forceful cast). ring->private doesn't even exist anymore as
it was transmogrified by Chris in:
commit 0d1aacac36530fce058d7a0db3da7befd5765417
Author: Chris Wilson
Date: Mon Aug 26 20:58:11 2013 +0100
Its last usage outside of i915_gem.c was removed in:
commit 1f70999f9052f5a1b0ce1a55aff3808f2ec9fe42
Author: Chris Wilson
Date: Mon Jan 27 22:43:07 2014 +
drm/i915: Prevent recursion by retiring requests when the ring is full
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/
This function was removed by Imre's power well work.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a4ffc02..a0cfc62 100644
--- a/drivers/gpu/drm/i915/
I have a script around that catches a few things otherwise hard to find
(because you'd need analysis beyond a single compilation unit). The last run
returned 3 hits.
HTH,
--
Damien
Damien Lespiau (3):
drm/i915: Make i915_gem_retire_requests_ring() static
drm/i915: Remove unused to_gem_objec
Hi Dave,
drm-intel-next-2014-02-14:
- Fix the execbuf rebind performance regression due to topic/ppgtt (Chris).
- Fix up the connector cleanup ordering for sdvod i2c and dp aux devices (Imre).
- Try to preserve the firmware modeset config on driver load. And a bit of prep
work for smooth takeove
Consistency throughout the code base is good and remove some room for
mistakes (as explained in the "drm/i915: Use a pipe variable to cycle
through the pipes" commit)
So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe)
when it's reasonable and practical to do so (eg. when ther
'i' is already defined in the function scope and used elsewhere. Let's
use it instead.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d90a707
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_dma.c | 8 ++--
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gp
This macro is similar to for_each_pipe() we already have. Convert the
two call sites we have at the same time.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 16
2 files changed, 9 insertions(+), 8 deletions(
Follow up of:
http://lists.freedesktop.org/archives/intel-gfx/2014-February/040789.html
With a couple of changes:
- Fix up the poor style when initializing the per-pipe num_sprites
- Added more for_each_pipe(pipe) conversion
- Added a small cleanup patch spotted when doing the previous pa
I recently fumbled a patch because I wrote twice num_sprites[i], and it
was the right thing to do in only 50% of the cases.
This patch ensures I need to write num_sprites[pipe], ie it should be
self-documented that it's per-pipe number of sprites without having to
look at what is 'i' this time aro
On Mon, 03 Mar 2014, Daniel Martin wrote:
> PS: Should I open a fdo bug for drm/intel?
FYI everyone, tracked at
https://bugs.freedesktop.org/show_bug.cgi?id=75710
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing li
Hi,
I'm having a bug here, where the loaded hda (snd_hda_intel) module
causes some (timing?) problem resulting in a monitor connected to the DP
not to get active. I can reproduce this on a Lenovo X201 and T410
(Ironlake) sitting on a docking station, which has a monitor (Dell
U2410) connected to a
On Mon, 3 Mar 2014 11:18:10 +0100
Daniel Vetter wrote:
> ... it's this time of the year again. Originally we've frobbed this to
> fix up some regressions, but maybe our DP code improved sufficiently
> now that we can dare to do again what the spec recommends.
>
> This reverts
>
> commit 2514bc
On Sat, Mar 1, 2014 at 6:10 PM, Chris Wilson wrote:
> On Sat, Mar 01, 2014 at 03:29:41PM -0300, Rodrigo Vivi wrote:
>> On Sat, Mar 1, 2014 at 5:45 AM, Chris Wilson
>> wrote:
>> > On Fri, Feb 28, 2014 at 08:44:45PM -0300, Rodrigo Vivi wrote:
>> >> Baytrail cannot easily detect screen updates and
On Mon, Mar 03, 2014 at 02:49:36PM +, Damien Lespiau wrote:
> On Fri, Feb 28, 2014 at 05:49:20PM +, Chris Wilson wrote:
> > On Fri, Feb 28, 2014 at 05:37:39PM +, Damien Lespiau wrote:
> > > On Fri, Feb 28, 2014 at 05:30:02PM +, Chris Wilson wrote:
> > > > On Fri, Feb 28, 2014 at 04:
On Mon, Mar 03, 2014 at 04:46:20PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 28, 2014 at 06:44:03PM +, Chris Wilson wrote:
> > @@ -405,9 +403,8 @@ void gen6_gt_force_wake_put(struct drm_i915_private
> > *dev_priv, int fw_engine)
> > spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> >
On Fri, Feb 28, 2014 at 05:49:20PM +, Chris Wilson wrote:
> On Fri, Feb 28, 2014 at 05:37:39PM +, Damien Lespiau wrote:
> > On Fri, Feb 28, 2014 at 05:30:02PM +, Chris Wilson wrote:
> > > On Fri, Feb 28, 2014 at 04:42:15PM +, Damien Lespiau wrote:
> > > > In the future, we need to b
On Fri, Feb 28, 2014 at 06:44:03PM +, Chris Wilson wrote:
> We don't want to suffer scheduling delay when turning off the GPU after
> waking it up to touch registers. Ideally, we only want to keep the GPU
> awake for the register access sequence, with a single forcewake dance on
> the first acc
On Mon, 03 Mar 2014, Daniel Vetter wrote:
> ... it's this time of the year again. Originally we've frobbed this to
> fix up some regressions, but maybe our DP code improved sufficiently
> now that we can dare to do again what the spec recommends.
>
> This reverts
>
> commit 2514bc510d0c3aadcc52040
On Mon, Mar 03, 2014 at 11:36:14AM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> We are adding a module paramter to control rps boost. By default, we
> enable the boost for better performace. Based on the need (perf/power)
> we can either enable/disable.
>
> Signed-off-by: Deepak S
> --
On Sun, Mar 02, 2014 at 09:20:56PM +0100, Daniel Vetter wrote:
> Apparently we've missed a few more than what Fengguang's 0-day tester
> recently reported in i915_irq.c ... Makes sparse happy again (ignore
> some spurious stuff about ksyms of exported functions).
>
> Cc: kbuild test robot
> Cc: I
From: Ville Syrjälä
Currently we allow encoders to indicate whether they can be part of a
cloned set with just one flag. That's not flexible enough to describe
the actual hardware capabilities. Instead make it a bitmask of encoder
types with which the current encoder can be cloned.
For now we se
From: Ville Syrjälä
HDMI+VGA cloning should be supported on all platforms. The only real
obstacle is the 1.5x clock adjustment for 12bpc HDMI, but that is now
taken care of, so we can allow HDMI+VGA cloning.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73850
Signed-off-by: Ville Syrjäl
From: Ville Syrjälä
The hardware allows a lot more cloning options than what the driver
currently allows. There are certain easy cloning cases like VGA+HDMI
and HDMI+HDMI which can be enabled very easily, so let's just do it.
LVDS+VGA would be another combination that should be generally availab
From: Ville Syrjälä
BSpec is a bit unclear whether HDMI+HDMI cloning should work on g4x.
Tests on real hardware say that it does. Since g4x can't send
infoframes to more than one HDMI port anyway, we don't lose anything
by allow it.
For PCH platforms BSpec explicitly forbids HDMI+HDMI cloning.
From: Ville Syrjälä
When cloning HDMI with other output types, we can't use 12bpc since the
clocks for the other encoder types would be off. So have
intel_hdmi_compute_config() check if there are other encoders besides
HDMI being fed from the same pipe, and if so, pick 8bpc insted if 12bpc.
Sign
On Mon, 03 Mar 2014, deepa...@intel.com wrote:
> From: Deepak S
>
> We are adding a module paramter to control rps boost. By default, we
> enable the boost for better performace. Based on the need (perf/power)
> we can either enable/disable.
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i9
On Mon, 03 Mar 2014, Jani Nikula wrote:
> From: Ville Syrjälä
>
> Single-link DVI max dotclock is 165MHz. Filter out modes with higher
> dotclock when the monitor doesn't support HDMI.
>
> Modes higher than 165 MHz were allowed in
>
> commit 7d148ef51a657fd04036c3ed7803da600dd0d451
> Author: Dani
... it's this time of the year again. Originally we've frobbed this to
fix up some regressions, but maybe our DP code improved sufficiently
now that we can dare to do again what the spec recommends.
This reverts
commit 2514bc510d0c3aadcc5204056bb440fa36845147
Author: Jesse Barnes
Date: Thu Jun
On Fri, Feb 28, 2014 at 07:09:51PM -0300, Paulo Zanoni wrote:
> 2014-02-27 9:23 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > On DDI there's no PLL as such to generate the pixel clock for VGA.
> > Instead we derive the pixel clock from the FDI link frequency. So
> > to make .compute_config match wh
On Fri, Feb 28, 2014 at 06:40:22PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2014-02-27 9:23 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Write some theoretical SPLL sharing support for DDI. Currently that will
> > never happens since we never use SPLL for anything but FDI. But having
> > the code ther
From: Ville Syrjälä
Single-link DVI max dotclock is 165MHz. Filter out modes with higher
dotclock when the monitor doesn't support HDMI.
Modes higher than 165 MHz were allowed in
commit 7d148ef51a657fd04036c3ed7803da600dd0d451
Author: Daniel Vetter
Date: Mon Jul 22 18:02:39 2013 +0200
d
On Fri, 28 Feb 2014, Matthew Thode wrote:
> Hardware is a T520 with a i5-2520M (intel only).
>
> Booting via uefi stub, kernel config is attached.
>
> This is broken on 3.13.x the video shows hardened kernel being booted,
> but I've tested kernel.org sources as well with the same effect.
>
> I can
54 matches
Mail list logo
