On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
I've just tracked down and fixed an bug which can lead to a hard-hang
in the crtc restore code (which is used both in the lid handler when
opening and on resume). If you could please test this patch (on top of
drm-intel-nightly):
Hi Greg,
Please consider
9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
the per-process entries, 2012-08-24
for application to the 3.4.y tree.
Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
The problem is reproducible on
* Debian's
On Thu, Apr 11, 2013 at 11:09:00PM +0200, Daniel Vetter wrote:
On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote:
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
This time things blew up when
commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook keesc...@chromium.org
Date: Sun Mar 10 14:10:06 2013 -0700
drm/i915: use simple attribute in debugfs routines
made i915_next_seqno debugfs entry to crop it's output
if returned value was large enough. Using simple_attr
will
Kees Cook keesc...@chromium.org writes:
On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
mika.kuopp...@linux.intel.com wrote:
Kees Cook keesc...@chromium.org writes:
On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
mika.kuopp...@linux.intel.com wrote:
commit
On Thu, Apr 11, 2013 at 08:36:26AM -0700, Ben Widawsky wrote:
On Thu, Apr 11, 2013 at 07:10:50AM +0100, Chris Wilson wrote:
On Wed, Apr 10, 2013 at 07:43:39PM -0700, Ben Widawsky wrote:
I think this is a nice generalization on it's own, but it's primarily
prep work for my PPGTT support.
On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote:
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
This time things blew up when restoring modes in the switchless resume
code -
Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_panel.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 5d3e9d7..0362f5c 100644
---
Patches 1-2 are for locking, 3-4 are related only by being backlight fixes.
I haven't tested these much...
BR,
Jani.
Jani Nikula (4):
drm/i915: keep max backlight internal to intel_panel.c
drm/i915: protect backlight registers and data with a spinlock
drm/i915: ensure single
In preparation of adding locking to backlight, make max backlight value
(the modulation frequency the PWM duty cycle value must not exceed)
internal to intel_panel.c.
Have intel_panel_set_backlight() accept a caller defined range for level,
and scale input to max backlight value internally.
Backlight data and registers are fiddled through LVDS/eDP modeset
enable/disable hooks, backlight sysfs files, asle interrupts, and register
save/restore. Protect the backlight related registers and driver private
fields using a spinlock.
The locking in register save/restore covers a little more
With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_irq.c |4 ++--
There's still stuff to do on opregion cleanup, but here are some potentially
risky and/or controversial ones...
Jani Nikula (3):
drm/i915: don't pretend we support ASLE ALS, PFIT, or PFMB
drm/i915/opregion: don't pretend we did something when we didn't
drm/i915: drop code duplication in
In theory, the BIOS should not even request these from us now that we
aren't claiming we support these, but when it does anyway, don't pretend it
succeeded. It should be the right thing to do, but might confuse the BIOS.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
In theory, this should prevent the BIOS from requesting them from us, and
this should be the right thing.
In practice, this is not always the case, and might surprise the BIOS.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_opregion.c |4 +---
1 file
On Fri, Apr 12, 2013 at 03:18:36PM +0300, Jani Nikula wrote:
In preparation of adding locking to backlight, make max backlight value
(the modulation frequency the PWM duty cycle value must not exceed)
internal to intel_panel.c.
Have intel_panel_set_backlight() accept a caller defined range
On Thu, Apr 11, 2013 at 04:29:06PM +0200, Daniel Vetter wrote:
The recent rework of the pfit handling didn't take into account that
the panel fitter is fixed to pipe B:
commit 24a1f16de97c4cf0029d9acd04be06db32208726
Author: Mika Kuoppala mika.kuopp...@linux.intel.com
Date: Fri Feb 8
On Thu, Apr 11, 2013 at 04:29:10PM +0200, Daniel Vetter wrote:
We can only enable the pfit if the pipe. Ensure that this is obied
with a neat assert.
Also check whether the pfit is off before enabling it - if not we've
lost track of things somewhere since the pfit is only ever used by the
On Thu, Apr 11, 2013 at 04:29:09PM +0200, Daniel Vetter wrote:
The i9xx modeset sequence is currently pretty fishy, so tight it all
up with some good assert-sprinkling.
We already have good coverage on the disable side, but the enable side
is spotty (since until recently it was wrong).
On Thu, Apr 11, 2013 at 04:29:08PM +0200, Daniel Vetter wrote:
Just blows through 50ms for naught, since the pipe is off.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Apr 11, 2013 at 04:29:07PM +0200, Daniel Vetter wrote:
This is horrible lore and we should be able to get rid of it now
that the lvds/pfit handling code actually does the right thing.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
I'd prefer 4 5 squashed, specially as 5 will
Thanks for concrete answer. I rebuilt my xf86-video-intel driver with
glamor, SNA and UXA support enabled but unfortunately it did not help. My
815 E
chipset still works slow. I think it is because glamor, SNA and UXA does not
support my chipset, right ?
If so, is it going to be supported in the
On Fri, Apr 12, 2013 at 04:13:47PM +0200, j j wrote:
Thanks for concrete answer. I rebuilt my xf86-video-intel driver with
glamor, SNA and UXA support enabled but unfortunately it did not help. My
quot;815 Equot;
chipset still works slow. I think it is because glamor, SNA and UXA does not
On Fri, Apr 12, 2013 at 11:46 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote:
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
This time things blew up
Summary
We finished a new round of kernel testing. Generally, in this circle, 2 new
bugs are filed, 23 bugs are still opened,1 Resolved fixed bugs(we are busy in
doing our testing, sorry that we are slow to response this bug, we will retest
this bug ASAP), 6 bugs are closed.
Test Environment
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes compares the current state with where we
want to go to (which is carefully
On Fri, Apr 12, 2013 at 06:48:43PM +0200, Daniel Vetter wrote:
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq
When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
On Fri, Apr 12, 2013 at 2:15 AM, Mika Kuoppala
mika.kuopp...@linux.intel.com wrote:
Kees Cook keesc...@chromium.org writes:
On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
mika.kuopp...@linux.intel.com wrote:
Kees Cook keesc...@chromium.org writes:
On Thu, Apr 11, 2013 at 6:22 AM, Mika
On Fri, Apr 12, 2013 at 2:10 AM, Mika Kuoppala
mika.kuopp...@linux.intel.com wrote:
commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook keesc...@chromium.org
Date: Sun Mar 10 14:10:06 2013 -0700
drm/i915: use simple attribute in debugfs routines
made i915_next_seqno
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we
On Fri, Apr 12, 2013 at 10:50:44AM -0700, Jesse Barnes wrote:
When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
Hi Greg,
Please consider
9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
the per-process entries, 2012-08-24
for application to the 3.4.y tree.
Without this patch, Geoff Crompton's iMac
Hi
2013/3/28 Daniel Vetter dan...@ffwll.ch:
On Fri, Feb 22, 2013 at 05:05:29PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
- after we receive one
On Fri, Apr 12, 2013 at 10:50:45AM -0700, Jesse Barnes wrote:
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
On Fri, Mar 22, 2013 at 02:16:38PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This solves some unclaimed register messages when booting the
machine with eDP attached.
V2: Rebase and add the comment requested by Daniel.
Signed-off-by: Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com
This is bad news and shouldn't be happening.
V2: Rebase.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 13 +++--
drivers/gpu/drm/i915/i915_reg.h |2 ++
2 files changed, 13 insertions(+), 2
From: Paulo Zanoni paulo.r.zan...@intel.com
We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |1 -
1 file
From: Paulo Zanoni paulo.r.zan...@intel.com
We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..3d3803a 100644
---
43 matches
Mail list logo
