On Mon, Jan 06, 2014 at 08:05:56PM -0200, Paulo Zanoni wrote:
Hi
2014/1/6 Damien Lespiau damien.lesp...@intel.com:
Follow up of the v3:
http://lists.freedesktop.org/archives/intel-gfx/2013-December/037333.html
The main change is the removal of INTEL_INFO() from the driver (patches 1
On Tue, 07 Jan 2014, Paulo Zanoni przan...@gmail.com wrote:
- You removed INTEL_INFO, but all those IS_SOMETHING and HAS_SOMETHING
macros still accept dev as argument instead of dev_priv. Do we have
plans to change this too? I can remember many places where I had to
add a dev variable just
Jani for co-maintainer!
Jani has been a really active bug-scrubber in the past few months.
I've asked him whether he wants to do this in a more official capacity
and he agreed. I've already chatted with Dave and Jesse and they
support this.
Note that everyone can't now just relax because Jani
On Tue, 07 Jan 2014, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Jani for co-maintainer!
Jani has been a really active bug-scrubber in the past few months.
I've asked him whether he wants to do this in a more official capacity
and he agreed. I've already chatted with Dave and Jesse and they
Multiple definitions show up multiple times in modinfo output.
There's already an identical one in i915_drv.c along with other MODULE_*
definitions, so drop the lone one in intel_fbdev.c.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_fbdev.c |2 --
1 file
Check that we can hang each individual engine
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tests/gem_reset_stats.c | 54 ++-
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
On Tue, Jan 07, 2014 at 10:23:58AM +0200, Jani Nikula wrote:
On Tue, 07 Jan 2014, Paulo Zanoni przan...@gmail.com wrote:
- You removed INTEL_INFO, but all those IS_SOMETHING and HAS_SOMETHING
macros still accept dev as argument instead of dev_priv. Do we have
plans to change this too? I can
On Tue, Jan 07, 2014 at 08:10:33AM +0100, Daniel Vetter wrote:
On Sat, Dec 28, 2013 at 01:31:49PM -0800, Ben Widawsky wrote:
The initialized flag is used to specify a context has been initialized
and it's context is safe to load, ie. the 3d state is setup properly.
With full PPGTT, we emit
On Thu, 02 Jan 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
In very rare cases (such as a memory failure stress test) it is possible
to fill the entire ring without emitting a request. Under this
circumstance, the outstanding request is flushed and waited upon. After
space on the ring is
This reverts commit 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb.
As pointed out in review, this patch is nonsense.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
On Sun, Jan 05, 2014 at 10:48:18PM +0100, Thomas Richter wrote:
Dear intel-experts,
a while ago I reported that the latest kernel from intel-drm-nightly
broke operations on i830 completely. In the meantime,
I found the reason. The trouble is in intel_crtcl_init():
static void
On Fri, 2013-12-20 at 15:09 -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We're iterating over the CPU transcoders, so check for the correct
power domain.
This fixes many unclaimed register error messages.
This can be reproduced by the IGT test mentioned below,
From: Ville Syrjälä ville.syrj...@linux.intel.com
Seems I was a bit sloppy when I sent out the last set of ILK/SNB/IVB watermark
patches and I forgot to update them for BDW. And I was even sloppier before
that since I forgot to actually hook up the watermark vfuncs on BDW. This
series should fix
From: Ville Syrjälä ville.syrj...@linux.intel.com
We forgot to intialize the watermark vfuncs for BDW, and hence the
watermarks were never updated.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 11 +++
1 file changed, 11 insertions(+)
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like I forgot to update the ILK/SNB/IVB watermark patches to deal
with BDW. Add the relevant BDW checks to make sure we take the HSW
codepaths on BDW as well.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
Avoid duplicating the same piece of code several times by separating
the watemark vfunc setup from the init_clock_gating vfunc setup on PCH
platforms.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä ville.syrj...@linux.intel.com
When the pipe A force quirk is applied the code will attempt to grab
a crtc mutex during intel_modeset_setup_hw_state(). If we're already
holding all crtc mutexes this will obviously deadlock every time.
So instead of using drm_modeset_lock_all()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like I managed to break 830M in a few different ways recently. But I
recently found one for myself so hopefully that'll not happen again.
I have a few other things lined up for 830M, but these are the quick fixes
that should get us back to
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like 830M doesn't quite like it when you try to move a plane from
one pipe to another. It seems that the plane's old pipe has to be active
even if the plane is already disabled, otherwise the relevant register
just won't accept new values.
On 01/07/2014 03:15 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjäläville.syrj...@linux.intel.com
Looks like I managed to break 830M in a few different ways recently. But I
recently found one for myself so hopefully that'll not happen again.
I have a few other things lined up for
From: Ville Syrjälä ville.syrj...@linux.intel.com
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[0.00]
From: Ville Syrjälä ville.syrj...@linux.intel.com
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[0.00]
Per inquiries from Vathsala et al, here's some early code for
initializing the backlight PWM from VBT if it hasn't been initialized by
the BIOS. I didn't have the chance to test this at all yet, just wanted
to unblock others. Testing and comments welcome. Particularly the
frequency in Hz to PWM
From: Deepak S deepa...@intel.com
As per the inputs provided by hardware team we still use the DDR
Rates as 0,1=800, 2=1066, 3=1333.
This patch reverts commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6.
After the revert, Turbo freqs used on current machines matches.
---
Make it available outside of intel_dp.c.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 33 +
drivers/gpu/drm/i915/intel_dp.c | 34 --
drivers/gpu/drm/i915/intel_drv.h |1
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h|1 +
drivers/gpu/drm/i915/intel_panel.c | 197 +++-
2 files changed, 170 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
On Tue, Jan 07, 2014 at 06:01:33PM +0200, Jani Nikula wrote:
Make it available outside of intel_dp.c.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Since this only really applies to gmch platforms I wonder whether we
should give this a more platforms specific prefix. Established precedence
On Mon, Jan 06, 2014 at 04:41:43PM -0800, Kenneth Graunke wrote:
On 01/06/2014 07:02 AM, Damien Lespiau wrote:
Having one source for registers defines sounds like a good idea. These
patches,
written long ago, were a baby step towards that goal by cleaning-up the
INSTDONE definitons to be
On Tue, 07 Jan 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jan 07, 2014 at 06:01:33PM +0200, Jani Nikula wrote:
Make it available outside of intel_dp.c.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Since this only really applies to gmch platforms I wonder whether we
should give
2013/12/5 Daniel Vetter dan...@ffwll.ch:
On Thu, Dec 5, 2013 at 1:38 PM, Paulo Zanoni przan...@gmail.com wrote:
Even with that patch applied, I think we should keep this current path
as-is since it runs before the code that checks for 2 encoders.
-compute_config is called much later after
On Tue, Jan 07, 2014 at 09:07:10AM +0100, Daniel Vetter wrote:
- Quick! Merge patch 3 before it conflicts and someone needs to review
that giant thing again!
As long as topic/ppgtt is still hanging out there and not yet merged into
dinq that can't happen due to conflict galore. And since
From: Damien Lespiau damien.lesp...@intel.com
The -detect() vfunc of connectors is usually responsible for setting the
encoder type on intel_digital_ports when a hotplug event happens.
However we sometimes want to force a modeset on a specific connector:
- the user can ask the SETCRTC ioctl to
From: Paulo Zanoni paulo.r.zan...@intel.com
In some cases we have more than 1 connector associated to an encoder
(e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of
these connectors. If we only allowed modesets for connected connectors
we would never need this patch, but since we
From: Damien Lespiau damien.lesp...@intel.com
That we can use for debugging purposes.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_drv.h | 1
On Tue, Jan 07, 2014 at 04:12:06PM +0100, Thomas Richter wrote:
On 01/07/2014 03:15 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjäläville.syrj...@linux.intel.com
Looks like I managed to break 830M in a few different ways recently. But I
recently found one for myself so hopefully
Oops. We should be a bit more consistent with which verb form we're
picking. tile,tiled,tiling is even worse ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/NAMING-CONVENTION | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/NAMING-CONVENTION
On Tue, 7 Jan 2014 08:07:13 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jan 7, 2014 at 12:31 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 19 Dec 2013 10:48:01 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
When fastbooting, we read out the pipe timings early on,
On Tue, 7 Jan 2014 08:07:13 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jan 7, 2014 at 12:31 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 19 Dec 2013 10:48:01 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
When fastbooting, we read out the pipe timings early on,
On Tue, Jan 07, 2014 at 04:59:10PM +, Chris Wilson wrote:
On Tue, Jan 07, 2014 at 04:12:06PM +0100, Thomas Richter wrote:
On 01/07/2014 03:15 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjäläville.syrj...@linux.intel.com
Looks like I managed to break 830M in a few
2014/1/7 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Avoid duplicating the same piece of code several times by separating
the watemark vfunc setup from the init_clock_gating vfunc setup on PCH
platforms.
Signed-off-by: Ville Syrjälä
2014/1/6 Jesse Barnes jbar...@virtuousgeek.org:
According to Art, we don't have a way to read back the state reliably at
runtime, at least not without risking disabling it again. So drop the
readout and checking on BDW.
Based on that, we also need to:
- Replace the TODO comment at
On Tue, Jan 07, 2014 at 05:34:40PM -0200, Paulo Zanoni wrote:
2014/1/7 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Avoid duplicating the same piece of code several times by separating
the watemark vfunc setup from the init_clock_gating vfunc setup on
On Tue, Jan 7, 2014 at 7:52 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
index 4d1357a..7e46d75 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2382,6 +2382,8 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x,
int y,
On Tue, Jan 7, 2014 at 7:50 PM, Alan Stern st...@rowland.harvard.edu wrote:
After all, it's not like there's anything I can do to fix the hardware,
is there? And it doesn't look like the pipe state mismatch is going to
go away by itself. Or is this a genuine, fixable, software bug?
These are
According to Art, we don't have a way to read back the state reliably at
runtime, through the control reg or the mailbox, at least not without risking
disabling it again. So drop the readout and checking on BDW.
v2: drop TODO comment (Paulo)
move POSTING_READ of control reg under HSW branch
On Tue, 7 Jan 2014 17:49:05 -0200
Paulo Zanoni przan...@gmail.com wrote:
2014/1/6 Jesse Barnes jbar...@virtuousgeek.org:
According to Art, we don't have a way to read back the state reliably at
runtime, at least not without risking disabling it again. So drop the
readout and checking on
On Tue, Jan 07, 2014 at 05:34:40PM -0200, Paulo Zanoni wrote:
2014/1/7 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Avoid duplicating the same piece of code several times by separating
the watemark vfunc setup from the init_clock_gating vfunc setup on
Otherwise we won't check the state until the next DPMS transition, which
may never happen.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Hi,
kms does not work om my Dell XPS 8700
I have installed openSUSE 13.1 (kernel 3.11.6) and the only way to
use the system is to pass the kernel option nomodeset.
If I boot the machine without nomodeset after the kernel and initrd are
loaded the monitor goes in powersave mode and after 10-15
Sorry, I left you all off the cc list for this.
Begin forwarded message:
Date: Wed, 8 Jan 2014 12:50:55 +1100
From: Stephen Rothwell s...@canb.auug.org.au
To: Dave Airlie airl...@linux.ie
Cc: linux-n...@vger.kernel.org, linux-ker...@vger.kernel.org, Alexander van
Heukelum heuke...@fastmail.fm,
Hi Dave,
Just a revert (gen4 backlight seems a lost cause) and a tlb coherency fix
for bdw, plus the patch to sign up Jani for co-maintainer. Thanks to Ben
for taking care of -fixes while I've enjoyed a bit of vacation.
Cheers, Daniel
The following changes since commit
On Wed, Jan 8, 2014 at 2:56 AM, Ying Xue ying@windriver.com wrote:
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’:
drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used
uninitialized in this function [-Wuninitialized]
52 matches
Mail list logo
