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. Does this bother anyone?
The only down side I can see is we waste 2k of cpu unmappable space
(unless we have something else that
(Sent to dri-devel and intel-gfx lists.)
Dear Linux graphics folks,
coreboot has been accepted to participate in Google Summer of Code 2013
[1]. coreboot is a Free Software project aimed at replacing the
proprietary BIOS (firmware) found in most computers.
Please find more information about
On Wed, 2013-04-10 at 07:52 +1000, Dave Airlie wrote:
Since atm we don't take a reference on the dma buf pointer when we add
it to the import lookup table the dma buf can vanish leaving the stale
pointer behind. This can in turn lead to returning stale GEM handles
when userspace imports a
Hi Egbert -
Up front, I haven't been following this series or read any of the
previous review comments. Please bear with me, and feel free to direct
me to earlier comments if I'm in contradiction.
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
Add
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Egbert Eich e...@suse.de
---
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
On Thu, Apr 11, 2013 at 11:32 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Okay, this is
commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584
Author: Ben Widawsky b...@bwidawsk.net
Date: Fri Apr 5 14:29:22 2013 -0700
drm/i915: Better overclock support
changed the sysfs read semantics for 'gt_max_freq_mhz'. By
always returning overclock max instead of stored value.
Fix this by
Make sure that debugfs entry works as expected by reading
back the sequence number that was written.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tests/gem_seqno_wrap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c
On Thu, Apr 11, 2013 at 01:44:51PM +0300, Jani Nikula wrote:
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ for (i = (HPD_NONE + 1); i HPD_NUM_PINS; i++) {
+ struct drm_connector *connector;
+
+ if (dev_priv-hpd_stats[i].hpd_mark != HPD_MARK_DISABLED)
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
This way it is possible to limit 're'-detect() of displays to connectors
which have received an HPD event.
I'd like you to be more explicit that this patch doesn't in fact add
such stuff in itself.
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it
On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote:
From: Egbert Eich e...@suse.de
Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.
Thanks, we've all been waiting
On Thu, Apr 11, 2013 at 04:21:54PM +0300, Jani Nikula wrote:
}
+ if (hpd_event_bits (1 intel_encoder-hpd_pin)) {
+ DRM_DEBUG_KMS(Connector %s (pin %i) received hotplug
event.\n,
+
This way it is possible to limit 're'-detect() of displays to connectors
which have received an HPD event.
v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.
v3: Fixed merge conflicts with previous patches.
Signed-off-by: Egbert Eich e...@suse.de
---
Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula jani.nik...@intel.com
v2: Resolved conflicts with changes in
This allows to add code which limits 're'-detect() of displays to connectors
that have received an HPD event.
v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.
v3: Fixed merge conflicts with previous patches, removed some noisy debug
logging as suggested by Jani
On Thu, 11 Apr 2013, Egbert Eich e...@suse.de wrote:
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the
Driver's and -fill_modes functions are allowed to grab crtc mutexes
(for e.g. load detect). Hence we need to first only grab the general
kms mutex, and only in a second step grab all locks to do the
modesets.
This prevents a deadlock on my gm45 in the tv load detect code called
by
When adding the pipe config computation step I've accidentally moved
this a bit away. Which momentarily confused me since the pipe config
step rejected some modesetting operations I expected and so left me
looking in vain for that debug output.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
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 - intel_modeset_affected_pipes figured out that pipe 2 should
be restored, but since pipe 1
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 16:35:37 2013 +0200
drm/i915: disable shared panel fitter for pipe
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
---
drivers/gpu/drm/i915/intel_display.c |2 --
1 file changed, 2 deletions(-)
diff --git
Just blows through 50ms for naught, since the pipe is off.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
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).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
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
lvds output.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
On Thu, 11 Apr 2013, Egbert Eich e...@suse.de wrote:
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at
On Tue, Apr 9, 2013 at 7:59 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Apr 9, 2013 at 7:51 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote:
/* pipesrc and dspsize control the size that is scaled from,
* which should always be the user's requested size.
*/
When adding the pipe config computation step I've accidentally moved
this a bit away. Which momentarily confused me since the pipe config
step rejected some modesetting operations I expected and so left me
looking in vain for that debug output.
v2: Move the debug output into the right function to
On Thu, 11 Apr 2013, Egbert Eich e...@suse.de wrote:
This allows to add code which limits 're'-detect() of displays to connectors
that have received an HPD event.
v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.
v3: Fixed merge conflicts with previous patches,
On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
v2: Try harder not to create a big patch (Chris).
Tested the patch applied to 3.9-rc6. Atleast on my machine that
helped, although once I managed to get the error (but not warning and
call trace as before):
On Wed, Apr 10, 2013 at 9:32 PM, Tomas Melin tomas.me...@iki.fi wrote:
On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
v2: Try harder not to create a big patch (Chris).
Tested the patch applied to 3.9-rc6. Atleast on my machine that
helped, although once I managed
On Thu, 11 Apr 2013, Egbert Eich e...@suse.de wrote:
Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula
Mika Kuoppala mika.kuopp...@linux.intel.com writes:
If context has recently submitted a faulty batchbuffers guilty of
gpu hang and decides to keep submitting more crap, ban it permanently.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c|
On Thu, Apr 11, 2013 at 03:07:59PM +0300, Mika Kuoppala wrote:
commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584
Author: Ben Widawsky b...@bwidawsk.net
Date: Fri Apr 5 14:29:22 2013 -0700
drm/i915: Better overclock support
changed the sysfs read semantics for 'gt_max_freq_mhz'. By
On Thu, Apr 11, 2013 at 04:11:28PM +0300, Mika Kuoppala wrote:
Make sure that debugfs entry works as expected by reading
back the sequence number that was written.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
Merged, thanks.
-Daniel
---
tests/gem_seqno_wrap.c | 10 ++
1
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. Does this bother anyone?
The only down side I can see is we
On Thu, Apr 11, 2013 at 6:22 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
Kees Cook keesc...@chromium.org writes:
On Thu, Apr 11, 2013 at 6:22 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
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
^
is disabled or something?
with a neat assert.
Also check whether the pfit is off before enabling it - if not we've
On Thu, Apr 11, 2013 at 6:37 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
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
^
is disabled or something?
Indeed.
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 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook
On Thu, Apr 11, 2013 at 04:39:53PM +0200, Daniel Vetter wrote:
When adding the pipe config computation step I've accidentally moved
this a bit away. Which momentarily confused me since the pipe config
step rejected some modesetting operations I expected and so left me
looking in vain for that
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the kernel returns EDEADLK when the number of fences is
exceeded for gen2-3. For gen4+ the test makes sure the kernel ignores
the EXEC_OBJECT_NEEDS_FENCE flag.
Note that I changed the code not to round the num_fences to an even
number.
Hi
2013/4/11 Daniel Vetter daniel.vet...@ffwll.ch:
Just blows through 50ms for naught, since the pipe is off.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Looks correct, but can you also please add some WARNs in case the pipe
is actually on? Check haswell_crtc_mode_set for examples:
-
When adding the pipe config computation step I've accidentally moved
this a bit away. Which momentarily confused me since the pipe config
step rejected some modesetting operations I expected and so left me
looking in vain for that debug output.
v2: Move the debug output into the right function to
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
That patch should crash at all, so this is not expected. Can you pls
check whether plain drm-intel-nightly is broken, too?
I did try drm-intel-nightly just now (1dd83e3), and it also freezes
the machine. I first verified that the
On 04/11/2013 04:34 PM, Daniel Vetter wrote:
On Tue, Apr 9, 2013 at 7:59 PM, Daniel Vetter dan...@ffwll.ch wrote:
...
Ok, I guess that was just a comment to say that the current bug isn't
quite a match with the old bug. Anyway, I think I've tracked down this
regression here, but since I
On Thu, Apr 11, 2013 at 02:47:05PM -0300, Paulo Zanoni wrote:
Hi
2013/4/11 Daniel Vetter daniel.vet...@ffwll.ch:
Just blows through 50ms for naught, since the pipe is off.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Looks correct, but can you also please add some WARNs in case
On Thu, Apr 11, 2013 at 7:52 PM, Richard Cochran
richardcoch...@gmail.com wrote:
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
That patch should crash at all, so this is not expected. Can you pls
check whether plain drm-intel-nightly is broken, too?
I did try
On Thu, Apr 11, 2013 at 08:43:40PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the kernel returns EDEADLK when the number of fences is
exceeded for gen2-3. For gen4+ the test makes sure the kernel ignores
the EXEC_OBJECT_NEEDS_FENCE
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the
On Tue, Apr 09, 2013 at 01:02:47PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.
Increasing the number of fences was
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):
2013/3/17 Chris Wilson ch...@chris-wilson.co.uk:
On Mon, Mar 18, 2013 at 07:42:58AM +1000, Dave Airlie wrote:
On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
On Sat, Mar 16, 2013 at 11:19 AM, Chris
On Thu, Apr 11, 2013 at 08:22:50PM +0200, Daniel Vetter wrote:
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that
On Thu, Apr 11, 2013 at 08:17:42PM +0100, Chris Wilson wrote:
On Thu, Apr 11, 2013 at 08:22:50PM +0200, Daniel Vetter wrote:
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable
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 -
On Thu, 11 Apr 2013, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
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
^
obeyed or something?
62 matches
Mail list logo
