Hi Todd -
On Fri, 20 Sep 2013, Todd Previte wrote:
> On 09/20/2013 06:42 AM, Jani Nikula wrote:
>> Per DP1.2 spec.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_dp.c |7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i
Hi Daniel!
This patch is definitely needed for 3.12, but it is still missing in 3.12-rc2
...
cu,
Knut
On 10.09.2013 11:44, Daniel Vetter wrote:
The native TV encoder has it's own flags to adjust sync modes and
enabled interlaced modes which are totally irrelevant for the adjusted
mode. This
On Mon, Sep 23, 2013 at 03:00:06PM -0700, Ben Widawsky wrote:
> > I think this interface violates Rusty's rules (API should be easy to
> > use but hard to misuse).
> >
> > vma = i915_gem_object_pin(batch_obj, ggtt, 0, false, false);
> > if (IS_ERR(vm)) {
> > ret = PTR_ERR(vm);
> > goto
On Mon, Sep 23, 2013 at 09:39:31AM +0100, Chris Wilson wrote:
> On Sun, Sep 22, 2013 at 11:46:00AM -0700, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > Building on the last patch which created the new function pointers in
> > the VM for bind/unbind, here we actually put those new function po
On Tue, Sep 24, 2013 at 12:18:32AM +0300, Meelis Roos wrote:
> > Good news, testing nightly+ with patch results in machine death. Now
> > seeing just where death creeps in.
>
> I am seeing these with just stock nightly. Maybe related...
>
> [ 3405.571241] shrink_slab: i915_gem_inactive_scan+0x0/0
> Good news, testing nightly+ with patch results in machine death. Now
> seeing just where death creeps in.
I am seeing these with just stock nightly. Maybe related...
[ 3405.571241] shrink_slab: i915_gem_inactive_scan+0x0/0x70 [i915] negative
objects to delete nr=-1568632773
[ 3405.571331] shri
On Mon, Sep 23, 2013 at 05:33:30PM -0300, Rodrigo Vivi wrote:
> Slice shutdown is a power savings feature whereby parts of HW i.e. slice is
> shut off on boot or dynamically to save power.
>
> This patch introduces a sysfs interface to easily allow dynamically switch
> between full and half GT3 sl
Slice shutdown is a power savings feature whereby parts of HW i.e. slice is
shut off on boot or dynamically to save power.
This patch introduces a sysfs interface to easily allow dynamically switch
between full and half GT3 slices.
v2: remove unused variables and fix identation
Signed-off-by: Ro
Slice shutdown is a power savings feature whereby parts of HW i.e. slice is
shut off on boot or dynamically to save power.
This patch only introduces a way to disable half of Haswell GT3 slices on boot.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/
From: Chris Wilson
After applying wait-boost we often find ourselves stuck at higher clocks
than required. The current threshold value requires the GPU to be
continuously and completely idle for 313ms before it is dropped by one
bin. Conversely, we require the GPU to be busy for an average of 90%
From: Chris Wilson
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
st
From: Chris Wilson
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
v2: Rebrand it as a
From: Chris Wilson
Obtaining the forcwake requires expensive and time consuming
serialisation. And we often try to obtain the forcewake multiple times
in very quick succession. We can reduce the overhead of these sequences
by delaying the forcewake release, and so not hammer the hw quite so
hard.
From: Chris Wilson
The RPS register writing routines use the current value of min/max to
set certain limits and interrupt gating. If we set those afterwards, we
risk setting up the hw incorrectly and losing power management events,
and worse, trigger some internal assertions.
Reorder the calling
From: Chris Wilson
In order to time how long a seqno is executed by a ring, we need to
measure both its insertion and its completion. (Using the completion of
the previous seqno as an estimate for when the GPU starts, if busy.) In
order to get an exact completion timestamp, we need irqs. This is
From: Chris Wilson
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb->obj is in the display domain, which
incurs a cache flush to ensure no dirt is le
From: Chris Wilson
For unfathomable reasons this alignment appears to be required for tiled
scanouts being read from stolen memory. I can find no reference in the
w/a db to support this requirement, but the evidence of my own eyes says
this prevents many headaches.
Note that I have not tricked a
From: Chris Wilson
We missed adding a few cleanup steps for recent additions.
Reviewer: Ben Widawsky
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_dma.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/g
From: Chris Wilson
We only wish to know the value of seqno when emitting the tracepoint, so
move the query from a parameter to the macro to inside the conditional
macro body so that the query is only evaluated when required.
Reviewer: Ville Syrjälä
Signed-off-by: Chris Wilson
Signed-off-by: Ro
From: Daniel Vetter
In truly crazy circumstances shmem might give us the wrong type of
page. So be a bit paranoid and double check this.
Reviewer: Damien Lespiau
Cc: Rob Clark
References: http://lkml.org/lkml/2011/7/11/238
Signed-off-by: Daniel Vetter
Signed-off-by: Rodrigo Vivi
---
drivers
This is another drm-intel-collector push for review:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the list in order for better reviewers assignment:
Patch 01/13 - 816e102 drm/i915: check that the i965g/gm 4G limit is really
obeyed - Reviewer: Damien
Patch 0
On Mon, Sep 23, 2013 at 11:05:25PM +0300, Meelis Roos wrote:
> > It works, thank you! No more WARNING.
> >
> > However, it now keeps spamming dmesg every 10 seconds about CRT not
> > connected:
>
> No, false alarm - the current upstream of
> 3.12.0-rc1-00336-gd8524ae-dirty is doing that even wi
> It works, thank you! No more WARNING.
>
> However, it now keeps spamming dmesg every 10 seconds about CRT not
> connected:
No, false alarm - the current upstream of
3.12.0-rc1-00336-gd8524ae-dirty is doing that even without the pipe
patch.
--
Meelis Roos
__
On Fri, Sep 20, 2013 at 09:35:30AM -0700, Ben Widawsky wrote:
> Future generations will be changing these registers (thanks to design
> for giving us an early heads up). To help abstract, create the
> definition of the base of the register block, and define all registers
> relative to that.
>
> De
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
> On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
>> On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra
>> wrote:
>>> On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
>> if (!bo_tryreserve()) {
>> up_read m
2013/9/20 :
> From: Ville Syrjälä
>
> VGA registers live inside the power well on HSW, so in order to write
> the VGA MSR register we need the power well to be on.
>
> We really must write to the register to properly clear the
> VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when
On 2013-09-23 19:41 (GMT+0100) Chris Wilson composed:
On Mon, Sep 23, 2013 at 02:18:17PM -0400, Felix Miata wrote:
https://bugzilla.novell.com/show_bug.cgi?id=841696
I've not had a chance to see if this also applies to Fedora and/or
Mageia, or been able to tell whether it's an Intel bug ra
On Mon, Sep 23, 2013 at 03:57:40PM +0100, Damien Lespiau wrote:
> Some stereo modes, like frame packing, need a larger CRTC viewport than
> the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
> needs to query the adjusted mode to use the correct h/vdisplay.
>
> Signed-off-by: Damie
On Mon, Sep 23, 2013 at 02:18:17PM -0400, Felix Miata wrote:
> https://bugzilla.novell.com/show_bug.cgi?id=841696
>
> I've not had a chance to see if this also applies to Fedora and/or
> Mageia, or been able to tell whether it's an Intel bug rather than a
> Xorg bug. Maybe someone here already kno
2013/9/21 Daniel Vetter :
> It only controls the setting of the vbt.edp_support variable, which in
> turn only controls one debug output plus can also force-disable the
> lvds output.
>
> Since the value only restricted this logic to mobile ilk there's the
> slight risk that this will break lvds on
On Fri, Sep 20, 2013 at 11:29:32AM -0700, Jesse Barnes wrote:
> Calculation is a little different than other platforms.
>
> v2: update to use port_clock instead
> rebase on top of Ville's changes
> v3: update to new port_clock semantics - don't divide by
> pixel_multiplier (Ville)
>
> Ref
From: Ville Syrjälä
vlv_find_best_dpll() has several integer over/underflow issues,
includes a hand rolled DIV_ROUND_CLOSEST(), has a boat load of
variables, some slightly weird math, and it doesn't look very
nice either.
Rather than try to deal with each issue separately I just decided
to rewri
On Mon, 23 Sep 2013, Srinivas Pandruvada
wrote:
> On 09/22/2013 11:18 PM, Jani Nikula wrote:
>> On Sat, 21 Sep 2013, Ben Widawsky wrote:
>>> We've had several reports of an Asus Zenbook reporting an 18bpp eDP
>>> display, which then proceeds to not work. Using the default 24, work
>>> just fine.
https://bugzilla.novell.com/show_bug.cgi?id=841696
I've not had a chance to see if this also applies to Fedora and/or Mageia, or
been able to tell whether it's an Intel bug rather than a Xorg bug. Maybe
someone here already knows?
--
"The wise are known for their understanding, and pleasant
wo
On 2013-09-23 15:51 (GMT+0100) Chris Wilson composed:
On Mon, Sep 23, 2013 at 10:13:02AM -0400, Felix Miata wrote:
Did Adam already fix this? Will you be including this among your
next submits? Do I need to file a bug first?
You have reported the bug, I've sent the patch onwards. It would
From: Ville Syrjälä
i9xx_crtc_clock_get() no longer populates adjusted_mode.clock, so we
must get the pixel clock from port_clock in intel_crtc_mode_get().
This bug caused Chris's 845g machine to lockup during boot, and it
was introduced in:
commit 18442d08786472c63a0a80c27f92b033dffc26de
Aut
On Sun, Sep 22, 2013 at 08:51:12PM +0200, Daniel Vetter wrote:
> This regression has been introduced in
>
> commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
> Author: Daniel Vetter
> Date: Thu Jun 13 00:54:58 2013 +0200
>
> drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
>
> Vi
On Mon, Sep 23, 2013 at 11:39:11AM -0300, Paulo Zanoni wrote:
> Also, just out of curiosity: do we get any noticeable performance
> difference on any workload? Depending on the impact I'd even vote to
> disable-by-default some of the debugging features.
The tests are typically GPU bound, we are wa
I've sent this 2 patches separately from the main stereo series so we can have
the usual rounds of review without having to resend the full 20+ patches. Once
that last bit has been reviewed as well, I'll send a consolidated series that
will be a serious candidate for merging.
--
Damien
_
Both setcrtc and page_flip are checking that the framebuffer is big
enough for the defined crtc viewport (x, y, hdisplay, vdisplay). Factor
that code out in a single function.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 70 --
1 file
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
v2: Use crtc_vtotal and multiply th
On Mon, Sep 23, 2013 at 10:13:02AM -0400, Felix Miata wrote:
> On 2013-09-23 09:22 (GMT+0100) Chris Wilson composed:
>
> >On Sun, Sep 22, 2013 at 08:45:57PM -0400, Felix Miata wrote:
>
> >>82810E DC-133 (GMCH)(rev 03)
> ...
> >>*
> >>Not good (openSUSE 12.2):
> >>glamor-0.
Some stereo modes, like frame packing, need a larger CRTC viewport than
the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
needs to query the adjusted mode to use the correct h/vdisplay.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 8
1 file changed, 8
On 09/22/2013 11:18 PM, Jani Nikula wrote:
On Sat, 21 Sep 2013, Ben Widawsky wrote:
We've had several reports of an Asus Zenbook reporting an 18bpp eDP
display, which then proceeds to not work. Using the default 24, work
just fine. Since it appears this is somewhat common in the budding world
o
2013/9/23 Chris Wilson :
> On Mon, Sep 23, 2013 at 09:57:37AM -0300, Paulo Zanoni wrote:
>> 2013/9/23 Chris Wilson :
>> > Register access is particularly obnoxious on Sandybridge and later due to
>> > the extra work we must do around every read or write. The effect is
>> > magnified on Haswell, as
On 2013-09-23 09:22 (GMT+0100) Chris Wilson composed:
On Sun, Sep 22, 2013 at 08:45:57PM -0400, Felix Miata wrote:
82810E DC-133 (GMCH)(rev 03)
...
*
Not good (openSUSE 12.2):
glamor-0.4.1-2.2.2
kernel-desktop-3.4.47-2.38
libdrm2-2.4.33-2.47.33-2.3.2
libdrm_intel1-2.
On Mon, Sep 23, 2013 at 09:57:37AM -0300, Paulo Zanoni wrote:
> 2013/9/23 Chris Wilson :
> > Register access is particularly obnoxious on Sandybridge and later due to
> > the extra work we must do around every read or write. The effect is
> > magnified on Haswell, as we have per-operation sanity ch
2013/9/23 Chris Wilson :
> Register access is particularly obnoxious on Sandybridge and later due to
> the extra work we must do around every read or write. The effect is
> magnified on Haswell, as we have per-operation sanity checking
> magnifying the number of reads and writes.
>
> Interrupt hand
On Mon, Sep 23, 2013 at 11:32:40AM +, Ramakutty, SandeepX wrote:
> Hi Chris,
>
> This patch is necessary for applying pixel format changes without creating
> new frame buffer.
No, it doesn't. As pixelformat is only specified with AddFB2, it appears
there is something else required to allow c
From: Ville Syrjälä
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless, and slower.
We never populated ->get_vblank_timestamp() in the UMS case, and as that
is the only way we'd ever call ->get_scanout_position(), we can
completely i
Hi Chris,
This patch is necessary for applying pixel format changes without creating new
frame buffer. The pixel format will be changed at page flip.
Background - The present kernel code does not support applying pixel format to
the current frame buffer. Hence hardware composer needs to create
On Mon, Sep 23, 2013 at 01:02:05PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have all the information we need in the mode structure, so going and
> reading it from the hardware is pointless, and slower.
>
> For the !kms case, leave the register reads in place.
dev
Register access is particularly obnoxious on Sandybridge and later due to
the extra work we must do around every read or write. The effect is
magnified on Haswell, as we have per-operation sanity checking
magnifying the number of reads and writes.
Interrupt handling is supposed to be fast, yet due
Hi folks,
Can you please test with
Option "LinearFramebuffer" "true"?
Thanks, Daniel
Tested again. Yes, indeed, LinearFramebuffer does make a difference.
Without it, panning to the right causes flicker, with it, moving the
mouse to the right - panning right (thus scrolling the scre
From: Ville Syrjälä
The DSL register increments at the start of horizontal sync, so it
manages to miss the entire active portion of the current line.
Improve the get_scanoutpos accuracy a bit when the scanout position is
close to the start or end of vblank. We can do that by double checking
the
From: Ville Syrjälä
The reported scanout position must be relative to the end of vblank.
Currently we manage to fumble that in a few ways.
First we don't consider the case when vtotal != vbl_end. While that
isn't very common (happens maybe only w/ old panel fitting hardware),
we can fix it easil
From: Ville Syrjälä
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless, and slower.
For the !kms case, leave the register reads in place.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 51 +++
These patches make some fixes and improvements to the get_scanoutpos() code.
They've been sitting on my disk for a while now, but I haven't found
the time to really test them properly. But as the subject of eliminating
the useless register reads came up recently, I decided that it's better
to post
On Mon, Sep 23, 2013 at 10:37:02AM +0200, Daniel Vetter wrote:
> On Mon, Sep 23, 2013 at 10:17 AM, Ville Syrjälä
> wrote:
> > Hmm. Why not just this?
> >
> > pipeconf = 0;
> > if (pipe == PIPE_A && QUIRK)
> > pipeconf |= PIPECONF_ENABLE;
>
> After resume the bios might or might not have enabled
On Fri, Sep 20, 2013 at 07:56:40AM -0300, Rodrigo Vivi wrote:
> "The operation is in theory redundant, and in the case of Haswell where
> we have multiple outputs aliasing to the same encoder, actually harmful."
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
> Credits-to: Chris W
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Monday, September 23, 2013 4:57 PM
> To: Lin, Mengdong
> Cc: ville.syrj...@linux.intel.com; intel-gfx; Arora, MukeshX
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/hsw:
On Mon, Sep 23, 2013 at 10:52 AM, Lin, Mengdong wrote:
>> Also I'd really like to see the audio stuff being tracked in the pipe config
>> instead
>> of splattering these different ad-hoc state bits like intel_crtc->eld_vld
>> all over
>> the place.
>> -Daniel
>
> How about adding a flag "has_aud
Hi Daniel and Ville,
Thanks for your feedback and please see comments below ...
I'm very sorry I missed your mails for a long time.
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Thursday, September 05, 2013 2:50 AM
On Sun, Sep 22, 2013 at 11:46:00AM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> Building on the last patch which created the new function pointers in
> the VM for bind/unbind, here we actually put those new function pointers
> to use.
>
> Split out as a separate patch to aid in review. I'
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
> On 09/17/2013 10:55 PM, Daniel Vetter wrote:
> > On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley
> > wrote:
> >> On 09/11/2013 03:31 PM, Peter Hurley wrote:
> >>>
> >>> [+cc dri-devel]
> >>>
> >>> On 09/11/2013 11:38 AM, Steven Rosted
On Mon, Sep 23, 2013 at 10:17 AM, Ville Syrjälä
wrote:
> Hmm. Why not just this?
>
> pipeconf = 0;
> if (pipe == PIPE_A && QUIRK)
> pipeconf |= PIPECONF_ENABLE;
After resume the bios might or might not have enabled pipe A already.
We have a bit of magic to make sure that on resume we set up a de
Hi Daniel, hi others,
On 22.09.2013 22:03, Daniel Vetter wrote:
Hm, that sounds a bit more like the ddx is having fun with rendering.
Have you tried switching the backed from to either SNA or UXA? Also
adding relevant mailing lists ...
No, whether I use uxa or sna makes no difference, same pr
On Sun, Sep 22, 2013 at 08:45:57PM -0400, Felix Miata wrote:
> 82810E DC-133 (GMCH)(rev 03)
>
> Everything seems to be OK with these (openSUSE 12.1):
> glamor (no such package)
> kernel-desktop-3.1.10-1.29
> libdrm-2.4.26-15.1.2
> (no Plymouth)
> xorg-x11-driver-video-intel-legacy-2.9.1-13.1.2
> x
On Sun, Sep 22, 2013 at 08:51:12PM +0200, Daniel Vetter wrote:
> This regression has been introduced in
>
> commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
> Author: Daniel Vetter
> Date: Thu Jun 13 00:54:58 2013 +0200
>
> drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
>
> Vi
On Mon, Sep 23, 2013 at 12:33:04AM +0200, Thomas Richter wrote:
> On 22.09.2013 22:03, Daniel Vetter wrote:
> >Hm, that sounds a bit more like the ddx is having fun with rendering.
> >Have you tried switching the backed from to either SNA or UXA? Also
> >adding relevant mailing lists ...
> >
> No,
On Mon, Sep 23, 2013 at 08:59:43AM +0300, Jani Nikula wrote:
> On Fri, 20 Sep 2013, Jani Nikula wrote:
> > I haven't received confirmation from various bug reporters whether these
> > actually fix any issues, but here goes anyway.
>
> These are on the series, but I bet it's patch 2/4 that does th
On Fri, Sep 20, 2013 at 03:31:42PM -0700, Todd Previte wrote:
> On 09/20/2013 01:57 PM, Paulo Zanoni wrote:
> >2013/9/20 Todd Previte :
> >>On 09/20/2013 06:42 AM, Jani Nikula wrote:
> >>>Reduce AUX transactions for non-eDP.
> >>>
> >>>Signed-off-by: Jani Nikula
> >>>---
> >>> drivers/gpu/drm/i9
72 matches
Mail list logo
