On Fri, 28 Feb 2014, Matthew Thode prometheanf...@gentoo.org 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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Fri, Feb 28, 2014 at 06:40:22PM -0300, Paulo Zanoni wrote:
Hi
2014-02-27 9:23 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Write some theoretical SPLL sharing support for DDI. Currently that will
never happens since we never use SPLL
On Fri, Feb 28, 2014 at 07:09:51PM -0300, Paulo Zanoni wrote:
2014-02-27 9:23 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
... 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
On Mon, 03 Mar 2014, Jani Nikula jani.nik...@intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Mon, 03 Mar 2014, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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,
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
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
On Mon, Mar 03, 2014 at 11:36:14AM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
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:
On Mon, 03 Mar 2014, Daniel Vetter daniel.vet...@ffwll.ch 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
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 access
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 be able to
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);
if
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:42:15PM
On Sat, Mar 1, 2014 at 6:10 PM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk
wrote:
On Fri, Feb 28, 2014 at 08:44:45PM -0300, Rodrigo Vivi wrote:
Baytrail
On Mon, 3 Mar 2014 11:18:10 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
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
On Mon, 03 Mar 2014, Daniel Martin consume.no...@gmail.com 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
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
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
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 damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 8 ++--
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
2 files changed, 9 insertions(+), 5 deletions(-)
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 damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 16
2 files changed, 9
'i' is already defined in the function scope and used elsewhere. Let's
use it instead.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
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 there
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
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
This function was removed by Imre's power well work.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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
Its last usage outside of i915_gem.c was removed in:
commit 1f70999f9052f5a1b0ce1a55aff3808f2ec9fe42
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Jan 27 22:43:07 2014 +
drm/i915: Prevent recursion by retiring requests when the ring is full
Signed-off-by: Damien
On Thu, 27 Feb 2014 11:01:08 +0200
Jani Nikula jani.nik...@linux.intel.com wrote:
On Thu, 27 Feb 2014, Jani Nikula jani.nik...@linux.intel.com wrote:
On Wed, 26 Feb 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 13 Jan 2014 16:25:21 +0530
akash.g...@intel.com wrote:
From:
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 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)
From: Yu(Alex) Dai yu@intel.com
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 yu@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
So don't try to allocate and program it, we're only fooling ourselves.
Reported-by: Chang, Junxiao junxiao.ch...@intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git
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
On Mon, 3 Mar 2014 11:14:09 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 27 Feb 2014 11:01:08 +0200
Jani Nikula jani.nik...@linux.intel.com wrote:
On Thu, 27 Feb 2014, Jani Nikula jani.nik...@linux.intel.com wrote:
On Wed, 26 Feb 2014, Jesse Barnes
On Fri, 7 Feb 2014 18:37:01 -0200
Rodrigo Vivi rodrigo.v...@gmail.com wrote:
From: Jesse Barnes jbar...@virtuousgeek.org
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
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
While reading some code, out of boredom, stumbled on a tiny tiny fix.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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
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 damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c
From: Mengdong Lin mengdong@intel.com
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
From: Mengdong Lin mengdong@intel.com
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:
From: Mengdong Lin mengdong@intel.com
Move these enum definitions earlier for future code sharing.
Signed-off-by: Mengdong Lin mengdong@intel.com
Reviewed-by: Haihao Xiang haihao.xi...@intel.com
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 47926e4..faa577e
From: Mengdong Lin mengdong@intel.com
It's for future code sharing because some registers define their bit fields
according to the number of pipes.
Signed-off-by: Mengdong Lin mengdong@intel.com
Reviewed-by: Haihao Xiang haihao.xi...@intel.com
diff --git a/tools/intel_audio_dump.c
From: Mengdong Lin mengdong@intel.com
Signed-off-by: Mengdong Lin mengdong@intel.com
Reviewed-by: Haihao Xiang haihao.xi...@intel.com
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index e6f6002..e36bb69 100644
--- a/tools/intel_audio_dump.c
+++
From: Mengdong Lin mengdong@intel.com
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 mengdong@intel.com
Reviewed-by: Haihao Xiang haihao.xi...@intel.com
diff --git
From: Mengdong Lin mengdong@intel.com
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 mengdong@intel.com
Reviewed-by: Haihao Xiang haihao.xi...@intel.com
diff --git
From: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com
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.
On Tue, Mar 04, 2014 at 10:46:38AM +0530, naresh.kumar.kac...@intel.com wrote:
From: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com
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.
53 matches
Mail list logo
