On Tue, Apr 29, 2014 at 04:38:21PM +0200, Daniel Vetter wrote:
> int intel_gpu_reset(struct drm_device *dev)
> {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_ring_buffer *ring;
> + int i;
> +
> + for_each_ring(ring, dev_priv, i)
> + __inte
On Wed, 30 Apr 2014, Dave Airlie wrote:
> On 30 April 2014 00:00, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Because the docs say ULX doesn't support it on HSW.
>
> i read the exact same thing,
>
> Reviewed-by: Dave Airlie
Pushed to -fixes, thanks for the patch and review.
BR,
Jani.
>
From: Dave Airlie
this is defined in the hsw docs, for the hdmi/dvi multiplier.
Signed-off-by: Dave Airlie
---
lib/intel_reg.h | 3 +++
tools/intel_reg_dumper.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 4b3a102..82ea85f 100644
---
On Wed, Apr 30, 2014 at 01:55:37PM +1000, Dave Airlie wrote:
> The docs don't mention the regs
>
> PIPE_CLK_SEL_A->C at 0x46140-46148, is there any more info on these of
> if they exist?
Attached.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ff
On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
> Higher RC6 residency is observed using timeout mode
> instead of EI mode. This applies to Broadwell only.
> The difference is particularly noticeable with video
> playback.
>
> Issue: VIZ-3778
> Change-Id: I62bb12e21caf19651034826b45
The docs don't mention the regs
PIPE_CLK_SEL_A->C at 0x46140-46148, is there any more info on these of
if they exist?
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem_gtt.c between commitcfa7c862982b
("drm/i915: Sanitize the enable_ppgtt module option once") from the
drm-intel-fixes tree tree and commit 5db6c735ead5 ("drm/i915: dmesg
output for VT-d testing")
On Tue, Apr 29, 2014 at 11:01:10AM +0200, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 10:52:44AM +0200, Daniel Vetter wrote:
> > On Mon, Apr 28, 2014 at 06:45:50PM -0700, Ben Widawsky wrote:
> > > See the relevant kernel patch for the details. I guess this breaks
> > > support for older error st
From: Dave Airlie
Signed-off-by: Dave Airlie
---
tools/intel_reg_dumper.c | 127 ++-
1 file changed, 115 insertions(+), 12 deletions(-)
diff --git a/tools/intel_reg_dumper.c b/tools/intel_reg_dumper.c
index 4bc299c..a482b5d 100644
--- a/tools/intel_r
Gen8 has already had some differentiation with how it handles rings.
Semaphores bring yet more differences, and now is as good a time as any
to do the split.
Also, since gen8 doesn't actually use semaphores up until this point,
put the proper "NULL" values in for the mbox info.
v2: v1 had a stale
Okay, trying this again after the somewhat painful VCS2 rebase. I think I got
to all of Ville's comments, but I could have missed a few. I apologize if so.
Daniel, even if you don't merge the whole series, the first few would really
help rebase pain - though now that VCS2 is merged, there's probab
Add_request has always contained both the semaphore mailbox updates as
well as the breadcrumb writes. Since the semaphore signal is the one
which actually knows about the number of dwords it needs to emit to the
ring, we move the ring_begin to that function. This allows us to remove
the hideously s
This will be helpful in abstracting some of the code in preparation for
gen8 semaphores.
v2: Move mbox stuff to a separate struct
v3: Rebased over VCS2 work
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 10 +--
drivers/gpu/drm/i915/
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've opted for, which should
be fairly future proof. Ie. I tried to define
With the ring mask we now have an easy way to know the number of rings
in the system, and therefore can accurately predict the number of dwords
to emit for semaphore signalling. This was not possible (easily)
previously.
There should be no functional impact, simply fewer instructions emitted.
Whi
This abstraction again is in preparation for gen8. Gen8 will bring new
semantics for doing this operation.
While here, make the writes of MI_NOOPs explicit for non-existent rings.
This should have been implicit before.
NOTE: This is going to be removed in a few patches.
Reviewed-by: Ville Syrjäl
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update macros to not require the other ring's ring->id (Chris)
Signed-off-
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gpu_error.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2d81985..a7eaab2 100644
--- a/drivers/gpu
Since the semaphore information is in an object, just dump it, and let
the user parse it later.
NOTE: The page being used for the semaphores are incoherent with the
CPU. No matter what I do, I cannot figure out a way to read anything but
0s. Note that the semaphore waits are indeed working.
v2: D
As Ville points out, it's possible/probable we don't actually need this.
Potentially, this validates the letter of the spec, and not the spirit.
Ville:
> I discussed this on irc w/ Ben, and I was suggesting we don't need to
> poll. Polling apparently can be used as a workaround for certain
> hardw
From: Ben Widawsky
This is needed to implement ipehr_is_semaphore_wait
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2d76183
Simple debugfs file to display the current state of semaphores. This is
useful if you want to see the state without hanging the GPU.
NOTE: This patch is optional to the series.
NOTE2: Like the GPU error state collection, the reads are currently
incoherent.
Signed-off-by: Ben Widawsky
---
drive
This appears to not actually be needed on the current code. Just putting
it on the ML so we can point bug reports at it later.
As pointed out by Ville, the current code is "broken" since we do
FORCE_RESTORE, and RESTORE_INHIBIT on the same dword. Anecdotally, this
seems fine.
Signed-off-by: Ben W
On Mon, Feb 24, 2014 at 03:08:04PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 19, 2014 at 10:19:23PM -0800, Ben Widawsky wrote:
> > Since the semaphore information is in an object, just dump it, and let
> > the user parse it later.
> >
> > NOTE: The page being used for the semaphores are incoherent
On 30 April 2014 00:00, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because the docs say ULX doesn't support it on HSW.
i read the exact same thing,
Reviewed-by: Dave Airlie
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_dp.c |
On Tue, 29 Apr 2014, Jani Nikula wrote:
> Historically we've exposed the full backlight PWM duty cycle range to
> the userspace, in the name of "mechanism, not policy". However, it turns
> out there are both panels and board designs where there is a minimum
> duty cycle that is required for proper
Historically we've exposed the full backlight PWM duty cycle range to
the userspace, in the name of "mechanism, not policy". However, it turns
out there are both panels and board designs where there is a minimum
duty cycle that is required for proper operation. The minimum duty cycle
is available i
Somehow a few functions have been dropped in the middle of backlight
code. Move them around. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 150 ++---
1 file changed, 75 insertions(+), 75 deletions(-)
diff --git a/drive
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
> From: Chon Ming Lee
>
> Added programming PLL for CHV based on "Application note for 1273 CHV
> Display phy".
>
> v2: -Break the common lane reset into another patch.
> -Break the clock calculation into another patch
On Tue, Apr 29, 2014 at 6:07 PM, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 4:38 PM, Daniel Vetter wrote:
>> This seems to make the hard machine hangs provoked by running
>> gem_reset_stats tests a lot less likely. At least on my snb here.
>>
>> v2: Don't DRM_ERROR when a reset is in progress
On Mon, 2014-04-28 at 13:10 +0300, Jani Nikula wrote:
> This reverts the bisected regressing
>
> commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
> Author: Jani Nikula
> Date: Thu Nov 14 12:14:29 2013 +0200
>
> drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
>
> restoring QUIRK_NO_PCH_PWM_ENABLE
On Tue, Apr 29, 2014 at 4:38 PM, Daniel Vetter wrote:
> This seems to make the hard machine hangs provoked by running
> gem_reset_stats tests a lot less likely. At least on my snb here.
>
> v2: Don't DRM_ERROR when a reset is in progress in the stop_ring
> function.
>
> Bugzilla: https://bugs.free
This seems to make the hard machine hangs provoked by running
gem_reset_stats tests a lot less likely. At least on my snb here.
v2: Don't DRM_ERROR when a reset is in progress in the stop_ring
function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74100
Cc: Mika Kuoppala
Signed-off-by:
On Tue, 29 Apr 2014, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 02:23:56PM +0200, Alessandro Suardi wrote:
>> Offtopic, this email has a tiny typo (Rererences in the freedesktop
>> bug ID line), just in case git actually stores that kind of metadata :)
>
> Jani, can you please rectify this?
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
> From: Chon Ming Lee
>
> Based on the chv clock limit, find the best divisor.
>
> The divisor data has been verified with this spreadsheet.
> P1273_DPLL_Programming Spreadsheet.
>
> v2: Rebase the code and change the chv_f
On Tue, Apr 29, 2014 at 05:06:59PM +0300, Ville Syrjälä wrote:
> On Sun, Apr 20, 2014 at 04:14:18PM +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
> >
> > This patch adds a new drm crtc property for varying the Pipe Src size
> > or the Panel fitter input size. Pipe Src controls the size
Todd, can you please quickly review this one?
Thanks, Daniel
On Tue, Apr 29, 2014 at 4:00 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because the docs say ULX doesn't support it on HSW.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i91
On Sun, Apr 20, 2014 at 04:14:18PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This patch adds a new drm crtc property for varying the Pipe Src size
> or the Panel fitter input size. Pipe Src controls the size that is
> scaled from.
> This will allow to dynamically flip (without mod
On Tue, Apr 29, 2014 at 02:23:56PM +0200, Alessandro Suardi wrote:
> On Tue, Apr 29, 2014 at 12:44 PM, Chris Wilson
> wrote:
> > On Tue, Apr 29, 2014 at 11:53:58AM +0200, Daniel Vetter wrote:
> >> Otherwise we'll end up spamming dmesg on every context creation on snb
> >> with vt-d enabled. This
On Mon, Apr 28, 2014 at 06:42:50PM -0300, Paulo Zanoni wrote:
> 2014-04-28 9:58 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Becasue of the upcoming vblank interrupt driven watermark update
>
> BecaUSe.
>
> Reviewed-by: Paulo Zanoni
>
> > mechanism we will have use for vblank interrupts during
From: Paulo Zanoni
Because the docs say ULX doesn't support it on HSW.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_dp.c | 3 ++-
include/drm/i915_pciids.h | 4 ++--
3 files changed, 7 insertions(+), 3 deletions(-)
This patch is co
On Tue, Apr 08, 2014 at 09:55:45PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 07, 2014 at 05:27:41PM -0300, Paulo Zanoni wrote:
> > 2014-03-07 13:32 GMT-03:00 :
> > > From: Ville Syrjälä
> > >
> > > Rather than have a wait_for_vblank() in the primary plane enable/disable
> > > funcs, move the wait
On Tue, Apr 29, 2014 at 09:34:28AM -0300, Paulo Zanoni wrote:
> 2014-04-29 8:20 GMT-03:00 Daniel Vetter :
> > On Tue, Apr 29, 2014 at 01:18:50PM +0200, Daniel Vetter wrote:
> >> On Mon, Apr 07, 2014 at 11:14:05AM -0300, Paulo Zanoni wrote:
> >> > 2014-03-07 13:32 GMT-03:00 :
> >> > > From: Ville S
On Sun, Apr 20, 2014 at 04:22:48PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This patch changes the return type of panel fitter configuration
> functions from 'void', so that an error could be returned back to
> User space, either during the modeset time or when the 'border' prope
On Tue, 29 Apr 2014, Chris Wilson wrote:
> On Tue, Apr 29, 2014 at 11:53:58AM +0200, Daniel Vetter wrote:
>> Otherwise we'll end up spamming dmesg on every context creation on snb
>> with vt-d enabled. This regression was introduced in
>>
>> commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
>> Auth
On Wed, Apr 23, 2014 at 06:16:07PM -0300, Paulo Zanoni wrote:
> 2014-03-07 13:32 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Make sure we programmed the watermarks correctly, by reading out the
> > hardware state again after programming and comparing it with the
> > state we supposedly programmed
2014-04-29 8:20 GMT-03:00 Daniel Vetter :
> On Tue, Apr 29, 2014 at 01:18:50PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 07, 2014 at 11:14:05AM -0300, Paulo Zanoni wrote:
>> > 2014-03-07 13:32 GMT-03:00 :
>> > > From: Ville Syrjälä
>> > >
>> > > intel_pipe_wm will be used to track the state in d
On Tue, Apr 29, 2014 at 01:17:12PM +0200, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 01:35:48PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add trace points for observing the atomic pipe update mechanism.
> >
> > v2: Rebased due to earlier changes
> > v3: Pass
On Tue, Apr 29, 2014 at 01:18:50PM +0200, Daniel Vetter wrote:
> On Mon, Apr 07, 2014 at 11:14:05AM -0300, Paulo Zanoni wrote:
> > 2014-03-07 13:32 GMT-03:00 :
> > > From: Ville Syrjälä
> > >
> > > intel_pipe_wm will be used to track the state in different stages
> > > of the watermark update pro
On Mon, Apr 07, 2014 at 11:14:05AM -0300, Paulo Zanoni wrote:
> 2014-03-07 13:32 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > intel_pipe_wm will be used to track the state in different stages
> > of the watermark update process. For that we need to keep a bit
> > more state in intel_pipe_wm.
> >
>
On Tue, Apr 29, 2014 at 01:35:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add trace points for observing the atomic pipe update mechanism.
>
> v2: Rebased due to earlier changes
> v3: Pass intel_crtc instead of drm_crtc (Daniel)
> v4: Pass frame counter from the ca
On Tue, Apr 29, 2014 at 12:48 PM, Chris Wilson wrote:
> On Tue, Apr 29, 2014 at 11:01:10AM +0200, Daniel Vetter wrote:
>> On Tue, Apr 29, 2014 at 10:52:44AM +0200, Daniel Vetter wrote:
>> > On Mon, Apr 28, 2014 at 06:45:50PM -0700, Ben Widawsky wrote:
>> > > See the relevant kernel patch for the d
On Tue, Apr 29, 2014 at 10:33:00AM +0200, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 3:10 AM, Ben Widawsky wrote:
> > On Sat, Jan 25, 2014 at 08:10:06PM +0100, Daniel Vetter wrote:
> >> On Fri, Jan 24, 2014 at 12:13:44PM -0800, Ben Widawsky wrote:
> >> > ping
> >>
> >> Merged the first patch t
On Tue, Apr 29, 2014 at 11:01:10AM +0200, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 10:52:44AM +0200, Daniel Vetter wrote:
> > On Mon, Apr 28, 2014 at 06:45:50PM -0700, Ben Widawsky wrote:
> > > See the relevant kernel patch for the details. I guess this breaks
> > > support for older error st
On Tue, Apr 29, 2014 at 01:35:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Another posting of the atomic sprite series. Most things are reviewed, but
> there
> are a few patches in there for the scanline fixup that don't have r-bs.
>
> The HSW+ situation is also st
On Tue, Apr 29, 2014 at 11:53:58AM +0200, Daniel Vetter wrote:
> Otherwise we'll end up spamming dmesg on every context creation on snb
> with vt-d enabled. This regression was introduced in
>
> commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
> Author: Ben Widawsky
> Date: Fri Dec 6 14:11:14 20
From: Ville Syrjälä
On gen2 the scanline counter behaves a bit differently from the
later generations. Instead of adding one to the raw scanline
counter value, we must subtract one.
On HSW the scanline counter apparently requires a +2 adjustment
on HDMI outputs. eDP on port A however wants the +
From: Ville Syrjälä
In interlaced modes, the pixel counter counts all pixels,
so one field will have htotal more pixels. In order to avoid
the reported position from jumping backwards when the pixel
counter is beyond the length of the shorter field, just
clamp the position the length of the short
From: Ville Syrjälä
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
We do the vblank evade by che
From: Ville Syrjälä
The docs are a bit lacking when it comes to describing when certain
timing related events occur in the hardware. Draw a picture which
tries to capture the most important ones.
v2: Clarify a few details (Imre)
Acked-by: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
Add a new function intel_get_crtc_scanline() that returns the current
scanline counter for the crtc.
v2: Rebase after vblank timestamp changes.
Use intel_ prefix instead of i915_ as is more customary for
display related functions.
Include DRM_SCANOUTPOS_INVBL in t
From: Ville Syrjälä
Add trace points for observing the atomic pipe update mechanism.
v2: Rebased due to earlier changes
v3: Pass intel_crtc instead of drm_crtc (Daniel)
v4: Pass frame counter from the caller to evaded/end since
the caller now always has that ready
Reviewed-by: Jesse Barnes
From: Ville Syrjälä
Seems I've been a bit dense with regards to the start of vblank
vs. the scanline counter / pixel counter.
After staring at the pixel counter on gen4 I came to the conclusion
that the start of vblank interrupt and scanline counter increment
happen at the same time. The scanlin
From: Ville Syrjälä
Currently the logic to fix up the frame counter on gen3/4 assumes that
start of vblank occurs at vblank_start*htotal pixels, when in fact
it occurs htotal-hsync_start pixels earlier. Apply the appropriate
adjustment to make the frame counter more accurate.
Also fix the vblank
From: Ville Syrjälä
Move the primary plane enable/disable to occur atomically with the
sprite update that caused the primary plane visibility to change.
FBC and IPS enable/disable is left to happen well before or after
the primary plane change.
v2: Pass intel_crtc instead of drm_crtc (Daniel)
From: Ville Syrjälä
Another posting of the atomic sprite series. Most things are reviewed, but there
are a few patches in there for the scanline fixup that don't have r-bs.
The HSW+ situation is also still unclear. The scanline counter behaviour depends
on either the actual DDI port used (A vs.
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This regression was introduced in
commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
Author: Ben Widawsky
Date: Fri Dec 6 14:11:14 2013 -0800
drm/i915: Reorganize intel_enable_ppgtt
As the i915.enable_p
On Tue, Apr 29, 2014 at 10:52:44AM +0200, Daniel Vetter wrote:
> On Mon, Apr 28, 2014 at 06:45:50PM -0700, Ben Widawsky wrote:
> > See the relevant kernel patch for the details. I guess this breaks
> > support for older error state, I am not actually sure. Without
> > versioning our error state tho
On Mon, Apr 28, 2014 at 06:45:50PM -0700, Ben Widawsky wrote:
> See the relevant kernel patch for the details. I guess this breaks
> support for older error state, I am not actually sure. Without
> versioning our error state though, I cannot think of a better way.
> Suggestions are welcome.
Just d
On Mon, Apr 28, 2014 at 09:37:36AM -0700, Volkin, Bradley D wrote:
> Reviewed-by: Brad Volkin
>
> On Fri, Apr 18, 2014 at 02:04:29PM -0700, Rodrigo Vivi wrote:
> > From: Ben Widawsky
> >
> > It seems we need this at least for the current platforms we have, but
> > probably not later. In any eve
On Tue, Apr 29, 2014 at 3:10 AM, Ben Widawsky wrote:
> On Sat, Jan 25, 2014 at 08:10:06PM +0100, Daniel Vetter wrote:
>> On Fri, Jan 24, 2014 at 12:13:44PM -0800, Ben Widawsky wrote:
>> > ping
>>
>> Merged the first patch to topic/ppgtt, but punted on the 2nd - I think
>> with Mika's improvement t
On Tue, Apr 29, 2014 at 07:48:41AM +0100, Chris Wilson wrote:
> On Mon, Apr 28, 2014 at 07:20:17PM -0700, Ben Widawsky wrote:
> > On Mon, Apr 28, 2014 at 01:53:52PM -0700, Daisy Sun wrote:
> > > RP frequency request is affected by 2 modules: normal turbo
> > > algorithm and RPS boost algorithm. By
72 matches
Mail list logo
