Hi
2013/8/19 Furquan Shaikh :
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c
On Mon, Aug 19, 2013 at 01:20:02PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This test chekcs our code that enables Package C8+. The environment
> requirements for this test are quite complicated:
> - The machine needs to be properly configured to reach PC8+ when
> possible, which
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf even
On Fri, Aug 16, 2013 at 12:22:14PM -0600, Alex Williamson wrote:
> On Fri, 2013-08-16 at 13:20 +0300, Ville Syrjälä wrote:
> > On Thu, Aug 15, 2013 at 04:54:15PM -0600, Alex Williamson wrote:
> > > On Fri, 2013-08-16 at 08:49 +1000, Dave Airlie wrote:
> > > > On Fri, Aug 16, 2013 at 8:43 AM, Alex W
Signed-off-by: Rodrigo Vivi
---
tests/Makefile.am | 1 +
tests/ddx_intel_after_fbdev | 73 +
2 files changed, 74 insertions(+)
create mode 100755 tests/ddx_intel_after_fbdev
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 9e46cac..
On Fri, Aug 16, 2013 at 03:35:57PM +0300, Jani Nikula wrote:
> From: ymohanma
>
> v2:
> - Grab dpio_lock mutex in vlv_enable_dsi_pll().
> - Add and call vlv_disable_dsi_pll().
>
> Signed-off-by: ymohanma
> Signed-off-by: Shobhit Kumar
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i9
I see lots of warning like this with 3.11-rc5 on my thinkpad t40.
[197481.739272] [drm:intel_pipe_config_compare] *ERROR* mismatch in
adjusted_mode.flags (expected 1, found 0)
[197481.739283] [ cut here ]
[197481.739352] WARNING: CPU: 0 PID: 556 at
drivers/gpu/drm/i915/in
2013/8/20 Daniel Vetter :
> On Tue, Aug 20, 2013 at 11:43:46AM -0300, Paulo Zanoni wrote:
>> 2013/8/20 Daniel Vetter :
>> > On Tue, Aug 06, 2013 at 06:57:16PM -0300, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> If the error interrupts are already disabled, don't disable and
>> >> reena
On Mon, 12 Aug 2013 10:33:37 -0700
Stéphane Marchesin wrote:
> On Fri, Aug 9, 2013 at 9:55 PM, Ben Widawsky wrote:
> > On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
> >> This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> >> (drm/i915: load boot context a
On Tue, Aug 20, 2013 at 11:43:46AM -0300, Paulo Zanoni wrote:
> 2013/8/20 Daniel Vetter :
> > On Tue, Aug 06, 2013 at 06:57:16PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> If the error interrupts are already disabled, don't disable and
> >> reenable them. This is going to be need
2013/8/20 Daniel Vetter :
> On Tue, Aug 06, 2013 at 06:57:16PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If the error interrupts are already disabled, don't disable and
>> reenable them. This is going to be needed when we're in PC8+, where
>> all the interrupts are disabled so we won'
On Thu, Aug 15, 2013 at 11:51:32AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because hsw_pm_irq_handler does exactly what gen6_rps_irq_handler does
> and also processes the 2 additional VEBOX bits. So merge those
> functions and wrap the VEBOX bits on a HAS_VEBOX check. This
> check isn
2013/8/19 Ben Widawsky :
> On Mon, Aug 19, 2013 at 04:01:13PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If LCPLL is disabled, there's a chance we might be in package C8 state
>> or deeper, and we'll get a hard hang when restoring LCPLL (also, a red
>> led lights up on my motherboard).
On Fri, Aug 09, 2013 at 05:04:36PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> It seems we've been doing this ever since we started processing the
> RPS events on a work queue, on commit "drm/i915: move gen6 rps
> handling to workqueue", 4912d04193733a825216b926ffd290fada88ab07.
>
> The
On Fri, Aug 16, 2013 at 03:35:56PM +0300, Jani Nikula wrote:
> This does not include any panel specific sub-encoders yet.
>
> v2: Fix fixed mode handling (Daniel)
>
> Signed-off-by: Jani Nikula
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/Makefile|1 +
> drivers/gpu/drm/
On Tue, Aug 06, 2013 at 06:57:16PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If the error interrupts are already disabled, don't disable and
> reenable them. This is going to be needed when we're in PC8+, where
> all the interrupts are disabled so we won't risk re-enabling
> DE_ERR_INT_
On Wed, Aug 07, 2013 at 03:14:51PM +0100, Chris Wilson wrote:
> On Wed, Aug 07, 2013 at 10:34:11AM -0300, Paulo Zanoni wrote:
> > 2013/8/6 Chris Wilson :
> > > On Tue, Aug 06, 2013 at 06:57:14PM -0300, Paulo Zanoni wrote:
> > >> From: Paulo Zanoni
> > >>
> > >> I did some brief tests and the "new_
On Fri, Aug 16, 2013 at 03:35:55PM +0300, Jani Nikula wrote:
> v2: Rebase due to register bit definition change.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/Makefile|1 +
> drivers/gpu/drm/i915/intel_dsi_cmd.c | 442
> ++
> drivers/gp
On Fri, Aug 16, 2013 at 03:35:51PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b417a8c..2f8e341 100644
> --- a/
On Thu, Aug 15, 2013 at 02:47:47PM -0700, Ben Widawsky wrote:
> I forgot to reword... but I had meant to. Already pushed, feel free to
> fix up. Sorry.
Done! Hopefully slighty better.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Tue, Aug 20, 2013 at 12:56:40PM +0100, Chris Wilson wrote:
> The execbuffer handle and exec_link were moved from the object into the
> vma. As the vma may be unbound and destroyed whilst attempting to
> reserve the execbuffer objects (either through a forced unbind to fix up
> a misalignment or
On Tue, Aug 20, 2013 at 10:29:23AM +0100, Chris Wilson wrote:
> From: Jesse Barnes
>
> On SNB and IVB, there's an MSR (also exposed through MCHBAR) we can use
> to read out the amount of energy used over time. Expose this in sysfs
> to make it easy to do power comparisons with different configur
The dimension 1024x786 works, wonderful, fist step is done.
How can I convince the chipset to drive a external monitor and not
a projector, that make maximum 1024x786?
Same behaviour with Win7!! So it MUST be a chipset programming fault.
Or a broken/ crashed chipset?
__
On Tue, Aug 20, 2013 at 2:41 PM, Chris Wilson wrote:
>> The DERRMR is overwritten by each before use. I thought that was
>> self-explanatory.
>
> The not-so-self-explanatory part is that there is a implicit
> synchronisation point in userspace between switching between flips and
> scanlines.
I wa
On Tue, Aug 20, 2013 at 01:39:02PM +0100, Chris Wilson wrote:
> On Tue, Aug 20, 2013 at 02:31:03PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 20, 2013 at 10:34 AM, Chris Wilson
> > wrote:
> > > RCS flips do work on Iybridge+ so long as we can unmask the messages
> > > through DERRMR. However, th
On Tue, Aug 20, 2013 at 02:31:03PM +0200, Daniel Vetter wrote:
> On Tue, Aug 20, 2013 at 10:34 AM, Chris Wilson
> wrote:
> > RCS flips do work on Iybridge+ so long as we can unmask the messages
> > through DERRMR. However, there are quite a few workarounds mentioned
> > regarding unmasking more t
On Tue, Aug 20, 2013 at 10:34 AM, Chris Wilson wrote:
> RCS flips do work on Iybridge+ so long as we can unmask the messages
> through DERRMR. However, there are quite a few workarounds mentioned
> regarding unmasking more than one event or triggering more than one
> message through DERRMR. Those
On Tue, Aug 20, 2013 at 3:33 AM, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
This is missing a hunk to enable the pipe_config consistency checks:
On Tue, Aug 20, 2013 at 1:26 PM, Damien Lespiau
wrote:
> On Mon, Aug 19, 2013 at 05:25:34PM -0700, Ben Widawsky wrote:
>> > > runtime with the module option i915.preliminary_hw_support=1; this
>> > > option changes the default for that module option.
>> > >
>> > > + If in doubt, say "N".
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..dc279f4 100644
---
The execbuffer handle and exec_link were moved from the object into the
vma. As the vma may be unbound and destroyed whilst attempting to
reserve the execbuffer objects (either through a forced unbind to fix up
a misalignment or through an evict-everything call) we need to prevent
the free of the i
On Mon, Aug 19, 2013 at 05:25:34PM -0700, Ben Widawsky wrote:
> > > runtime with the module option i915.preliminary_hw_support=1; this
> > > option changes the default for that module option.
> > >
> > > + If in doubt, say "N".
> > > +
>
> Heh. You didn't comment on the one part I real
From: Jesse Barnes
On SNB and IVB, there's an MSR (also exposed through MCHBAR) we can use
to read out the amount of energy used over time. Expose this in sysfs
to make it easy to do power comparisons with different configurations.
If the platform supports it, the file will show up under the
dr
RCS flips do work on Iybridge+ so long as we can unmask the messages
through DERRMR. However, there are quite a few workarounds mentioned
regarding unmasking more than one event or triggering more than one
message through DERRMR. Those workarounds in principle prevent us from
performing pipelined f
Hi,
I need help urgently, my external monitor 22" doesn't
get a signal since I bootet my laptop Lenovo B560
with closed lid an set the 1680x1050 manually. I worked
fine that whole day. But after rebooting after
that event the VGA interface denys to give any
signal to VGA. The VGA interface with th
On Mon, Aug 19, 2013 at 11:14:15PM -0700, Ben Widawsky wrote:
> In order to avoid confusion, and corruption as observed (in code review)
> by Chris - remove the VMA from the exec_list at destroy.
This should be BUG_ON(!list_empty(&vma->exec_list));
-Chris
--
Chris Wilson, Intel Open Source Techn
The exec_list is a somewhat fragile list containing all the VMAs we've
looked up. It does processing in a multi-stage approach where elements
on the list are expected to not be removed for the duration of the
stages.
The next patch will fix an oversight where destroying a VMA does not
remove it fr
The code has at least one place currently, and maybe more in the future
where we want to only unbind a VMA, but not destroy it. There are two
reasons for this, correctness and optimization. Using the one actual
case as an example:
1. Correctness: When doing the execbuf sequence we end up traversin
In order to avoid confusion, and corruption as observed (in code review)
by Chris - remove the VMA from the exec_list at destroy.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/
Hi Dave,
New pile of stuff for -next:
- Cleanup of the old crtc helper callbacks, all encoders are now converted
to the i915 modeset infrastructure.
- Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is
prep work to eventually get things going for nuclear pageflips where we
On Mon, Aug 19, 2013 at 07:31:59PM +0100, Damien Lespiau wrote:
> A small series to remove a few of those. I guess it's debatable if the
> i915_READ_* for ring registers should be removed or the code ported to always
> use those macros.
Entire series merged to dinq, thanks for the patches.
-Daniel
41 matches
Mail list logo
