On Thu, 11 Apr 2013, Ville Syrjälä 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?
Jani.
>
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 - intel_modeset_affect
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 c
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 intel_modeset
2013/3/17 Chris Wilson :
> On Mon, Mar 18, 2013 at 07:42:58AM +1000, Dave Airlie wrote:
>> On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson
>> wrote:
>> > On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
>> >> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson
>> >> wrote:
>> >> > If *us
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-night
On Tue, Apr 09, 2013 at 01:02:47PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 attempted before [1], but the
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 en
On Thu, Apr 11, 2013 at 08:43:40PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 c
On Thu, Apr 11, 2013 at 7:52 PM, Richard Cochran
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 drm-intel-nightly just now (1dd8
On Thu, Apr 11, 2013 at 02:47:05PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/4/11 Daniel Vetter :
> > Just blows through 50ms for naught, since the pipe is off.
> >
> > Signed-off-by: Daniel Vetter
>
> Looks correct, but can you also please add some WARNs in case the pipe
> is actually on? Check
On 04/11/2013 04:34 PM, Daniel Vetter wrote:
On Tue, Apr 9, 2013 at 7:59 PM, Daniel Vetter 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 couldn't reproduce i
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
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
Hi
2013/4/11 Daniel Vetter :
> Just blows through 50ms for naught, since the pipe is off.
>
> Signed-off-by: Daniel Vetter
Looks correct, but can you also please add some WARNs in case the pipe
is actually on? Check haswell_crtc_mode_set for examples:
- WARN_ON(I915_READ(PIPECONF(intel_crtc->cp
From: Ville Syrjälä
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. Not sure why that was there, a
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 th
On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
wrote:
> Kees Cook writes:
>
>> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
>> wrote:
>>> commit 647416f9eefe7699754b01b9fc82758fde83248c
>>> Author: Kees Cook
>>> Date: Sun Mar 10 14:10:06 2013 -0700
>>>
>>> drm/i915: use simple attribute
On Thu, Apr 11, 2013 at 6:37 PM, Ville Syrjälä
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.
--
Daniel Vetter
Softwa
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'v
Kees Cook writes:
> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
> wrote:
>> commit 647416f9eefe7699754b01b9fc82758fde83248c
>> Author: Kees Cook
>> Date: Sun Mar 10 14:10:06 2013 -0700
>>
>> drm/i915: use simple attribute in debugfs routines
>>
>> made i915_next_seqno debugfs entry to
On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
wrote:
> commit 647416f9eefe7699754b01b9fc82758fde83248c
> Author: Kees Cook
> 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
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
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
Merged, thanks.
-Daniel
> ---
> tests/gem_seqno_wrap.c | 10 ++
> 1 file changed, 10
On Thu, Apr 11, 2013 at 03:07:59PM +0300, Mika Kuoppala wrote:
> commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584
> Author: Ben Widawsky
> 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 retur
Mika Kuoppala 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
> ---
> drivers/gpu/drm/i915/i915_drv.c| 23 ++-
> drivers/gpu/dr
On Thu, 11 Apr 2013, Egbert Eich 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
> Reviewed-by: Jani Nikula
Yup.
>
> v2: Resolved c
On Wed, Apr 10, 2013 at 9:32 PM, Tomas Melin wrote:
> On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter 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
On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter 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):
[drm:i9xx_crtc_mode_set] *ERROR*
On Thu, 11 Apr 2013, Egbert Eich 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, removed some n
On Thu, 11 Apr 2013, Egbert Eich wrote:
> 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;
>> > +
>> > +
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 Tue, Apr 9, 2013 at 7:59 PM, Daniel Vetter wrote:
> On Tue, Apr 9, 2013 at 7:51 PM, Hans de Bruin wrote:
>>> /* pipesrc and dspsize control the size that is scaled from,
>>> * which should always be the user's requested size.
>>> */
>>> I915_WRITE(DSPSIZE(
On Thu, 11 Apr 2013, Egbert Eich 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 certain char
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
---
drivers/gpu/drm/i915/i
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
---
drivers/gpu/drm/i915/intel_display.c |
Just blows through 50ms for naught, since the pipe is off.
Signed-off-by: Daniel Vetter
---
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 4f9f846..e91e01c 100644
--
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
---
drivers/gpu/drm/i915/intel_display.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/d
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
Date: Fri Feb 8 16:35:37 2013 +0200
drm/i915: disable shared panel fitter for pipe
Fix this up by properly comput
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 was
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
---
drivers/gpu/drm/i9
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 drm_helper_prob
On Thu, 11 Apr 2013, Egbert Eich 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 system load
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 Nikula
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
Reviewed-by: Jani Nikula
v2: Resolved conflicts with changes in previous commits.
Renamed functio
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
---
drivers/gpu/drm/i915/i915_drv.h |
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",
> > + drm_get_connector_
On Tue, 09 Apr 2013, Egbert Eich wrote:
> From: Egbert Eich
>
> 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 for someone(tm) to do this.
A
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 aft
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 back
On Tue, 09 Apr 2013, Egbert Eich wrote:
> From: Egbert Eich
>
> 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.
>
> v2: Reordered drm_i915_priv
commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook
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 limit the output to 24
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_MA
Make sure that debugfs entry works as expected by reading
back the sequence number that was written.
Signed-off-by: Mika Kuoppala
---
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
index 43e3851..776dedc 10
commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584
Author: Ben Widawsky
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 returning the stored v
On Thu, Apr 11, 2013 at 11:32 AM, Jani Nikula
wrote:
> On Tue, 09 Apr 2013, Egbert Eich wrote:
>> From: Egbert Eich
>>
>> Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
>> fires more than 5 times / sec).
>
> Okay, this is theoretical, but a display port sink could do more
On Tue, 09 Apr 2013, Egbert Eich wrote:
> From: Egbert Eich
>
> 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
On Tue, 09 Apr 2013, Egbert Eich wrote:
> From: Egbert Eich
>
> 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 i
On Tue, 09 Apr 2013, Egbert Eich wrote:
> From: Egbert Eich
>
> To disable previously enabled HPD IRQs we need to reset them and
> set the enabled ones individually.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 ++
> 1 file changed, 2 in
On Tue, 09 Apr 2013, Egbert Eich wrote:
> From: Egbert Eich
>
> 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 connectors,
> we want to poll the
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 wrote:
> From: Egbert Eich
>
> Add a hotplug IRQ storm detection
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 imp
(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 GS
63 matches
Mail list logo
