On Tue, Dec 09, 2014 at 08:48:38PM -0800, Chad Versace wrote:
>
>
> On 10/23/2014 06:23 AM, Chris Wilson wrote:
> > On Thu, Oct 23, 2014 at 12:56:46PM +0100, Chris Wilson wrote:
> >> On Thu, Oct 23, 2014 at 04:03:56PM +0530, akash.g...@intel.com wrote:
> >>> From: Akash Goel
> >>>
> >>
> >>> Thi
This added as a BUG_ON as it considered that no one would ever request
an unaligned object. However, it turns out that some BIOSes will
allocate a scanout that is offset from 0 and not aligned to a page
boundary, and we were passing this through and hitting the BUG_ON during
boot.
Quietly reject s
On Tue, 09 Dec 2014, Imre Deak wrote:
> Register a component to be used to interface with the snd_hda_intel
> driver. This is meant to replace the same interface that is currently
> based on module symbol lookup.
>
> v2:
> - change roles between the hda and i915 components (Daniel)
> - add the imp
On Tue, Dec 09, 2014 at 06:04:31PM +0200, Mika Kuoppala wrote:
> In the following commits, we want to capture the hw state
> also without any errors. Carve out the helper out from error
> capture parts.
As an aside i915_gpu_state is a better name throughout for struct
drm_i915_error_state. Afterwa
On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
> > On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
> > > On Tue, Nov 25, 2014 at 5:04 AM, Daniel Vetter wrote:
> > > > On Mon, Nov 24, 2014 at 08:29:40AM -0800, R
On Tue, Dec 09, 2014 at 03:23:35PM +, Michel Thierry wrote:
> On 12/5/2014 12:11 PM, Tvrtko Ursulin wrote:
> >From: Tvrtko Ursulin
> >
> >Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
> >to map objects into the same address space multiple times.
> >
> >Added a GGTT
On Tue, Dec 09, 2014 at 01:37:21PM +, Michel Thierry wrote:
> On 12/5/2014 2:41 PM, Daniel Vetter wrote:
> >On Thu, Dec 04, 2014 at 05:25:56PM +0200, Ville Syrjälä wrote:
> >>On Thu, Dec 04, 2014 at 03:07:52PM +, Michel Thierry wrote:
> >>>We already have it for chv, but was missing for bdw
On Tue, Dec 09, 2014 at 12:30:49PM +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, "Singh, Gaurav K" wrote:
> > On 12/7/2014 4:13 PM, Gaurav K Singh wrote:
> >> For DSI Port A & C, the seq_port value has been set to 0 now in VBT
> >> Now the sequence of DSI single link on Port A and Port C will
On Tue, Dec 09, 2014 at 12:33:21PM +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, Daniel Vetter wrote:
> > On Tue, Dec 09, 2014 at 11:41:17AM +0200, Imre Deak wrote:
> >> Register a component to be used to interface with the snd_hda_intel
> >> driver. This is meant to replace the same interface
On Tue, Dec 09, 2014 at 06:30:40PM +0100, Takashi Iwai wrote:
> At Tue, 9 Dec 2014 11:19:34 +0100,
> Daniel Vetter wrote:
> >
> > On Tue, Dec 09, 2014 at 11:41:18AM +0200, Imre Deak wrote:
> > > Register a component master to be used to interface with the i915
> > > driver. This is meant to replac
On 12/10/2014 2:50 PM, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 12:30:49PM +0200, Jani Nikula wrote:
On Tue, 09 Dec 2014, "Singh, Gaurav K" wrote:
On 12/7/2014 4:13 PM, Gaurav K Singh wrote:
For DSI Port A & C, the seq_port value has been set to 0 now in VBT
Now the sequence of DSI sing
On Tue, Dec 09, 2014 at 05:25:16PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On CHV we sometimes see not just one but two bad CRCs. No real idea
> what would cause that, but let's just throw away the second CRC as
> well to gain some stability for the tests.
>
> Signe
On Tue, Dec 09, 2014 at 05:23:22PM +, Damien Lespiau wrote:
> intel-gpu-tools now generates the render state with license headers and
> the version of i-g-t that generated the files.
>
> A similar patch was previously sent but wasn't actually generated with
> the make target so was lacking the
On Mon, 08 Dec 2014, Damien Lespiau wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
> drivers/gpu/drm/i915
We already implement this workaround, but it was missing its name.
Reviewed-by: Ville Syrjälä
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringb
On 12/10/2014 9:18 AM, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 01:37:21PM +, Michel Thierry wrote:
On 12/5/2014 2:41 PM, Daniel Vetter wrote:
On Thu, Dec 04, 2014 at 05:25:56PM +0200, Ville Syrjälä wrote:
On Thu, Dec 04, 2014 at 03:07:52PM +, Michel Thierry wrote:
We already have
On Tue, Dec 09, 2014 at 09:28:29PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add the missing CRC control register value for DP port D on CHV.
> Untested as I don't have a CHV machine with DP on port D.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i9
On Tue, Dec 09, 2014 at 09:28:32PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently i915_pipe_crc_read() will drop pipe_crc->lock for the entire
> duration of the copy_to_user() loop, which means it'll access
> pipe_crc->entries without any protection. If another th
Stupid userspace (there is no evil userspace in debugfs by assumption)
might provoke a leak since we allocate the new array without holding
any locks. Drop in an unconditional kfree to deal with this - kfree
can handle NULL.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i91
On Tue, Dec 09, 2014 at 11:53:37AM -0800, Matt Roper wrote:
> drm_plane_helper_check_update() currently uses crtc before testing whether
> we're disabling the plane (fb == NULL). Move the fb test before the first
> crtc
> usage so that crtc == NULL doesn't have to be handled by the caller.
>
> S
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
On Tue, Dec 09, 2014 at 09:01:54PM -0500, Rodrigo Vivi wrote:
> Use cmdline variable for interactive debug instead of env var.
>
> Signed-off-by: Rodrigo Vivi
Looks nice, two small comments below.
> ---
> lib/igt_aux.c | 20 ++--
> lib/igt_aux.h | 2 +-
> lib/igt_core.c | 6
On 12/10/2014 09:16 AM, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 03:23:35PM +, Michel Thierry wrote:
We also need a _vma_view version of i915_gem_obj_bound;
i915_gem_object_ggtt_unpin checks if the obj is ggtt_bound and it could be
that the normal view is gone but a different view is st
On Tue, Dec 09, 2014 at 09:01:56PM -0500, Rodrigo Vivi wrote:
> Return key pressed and allow different messages.
>
> Signed-off-by: Rodrigo Vivi
Hm, not sure how useful this really is - when the test fails I just hit ^C
and scream ;-)
What kind of use-case do you have in mind which requires suc
On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> This added as a BUG_ON as it considered that no one would ever request
> an unaligned object. However, it turns out that some BIOSes will
> allocate a scanout that is offset from 0 and not aligned to a page
> boundary, and we were pass
On Wed, Dec 10, 2014 at 09:43:37AM +, Michel Thierry wrote:
> We already implement this workaround, but it was missing its name.
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Michel Thierry
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c |
On Tue, Dec 09, 2014 at 12:59:06PM +, john.c.harri...@intel.com wrote:
> From: Dave Gordon
>
> Added various definitions that will be useful for the scheduler in general and
> pre-emptive context switching in particular.
>
> Change-Id: Ica805b94160426def51f5d520f5ce51c60864a98
> For: VIZ-158
On Tue, Dec 09, 2014 at 12:59:07PM +, john.c.harri...@intel.com wrote:
> From: Dave Gordon
>
> When querying the GTFIFOCTL register to check the FIFO space, the read value
> must be masked. The operation is repeated explicitly in several places. This
> change refactors the read-and-mask code
On Tue, Dec 09, 2014 at 12:59:08PM +, john.c.harri...@intel.com wrote:
> From: Dave Gordon
>
> There is a workaround for a hardware bug when reading the seqno from the
> status
> page. The bug does not exist on VLV however, the workaround was still being
> applied.
Given how much trouble th
On Tue, Dec 09, 2014 at 12:59:09PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler needs to track batch buffers by request without extra, non-batch
> buffer work being attached to the same request. This means that anywhere which
> adds work to the ring should expli
On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler decouples the submission of batch buffers to the driver with
> their
> submission to the hardware. This basically means splitting the execbuffer()
> function in half. This change re
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Tuesday, December 09, 2014 1:18 PM
> To: Nguyen, Michael H
> Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Impl
On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > This added as a BUG_ON as it considered that no one would ever request
> > an unaligned object. However, it turns out that some BIOSes will
> > allocate a scanout that
On Wed, Dec 10, 2014 at 11:42:13AM +0200, Jani Nikula wrote:
> Pushed to drm-intel-next-fixes, replacing the old version. Thanks for
> the patch.
>
> Now the question is, do we want [1] for 3.19 or 3.20?
>
> [1]
> http://mid.gmane.org/1418060138-5004-1-git-send-email-damien.lesp...@intel.com
I
Hi Dave,
Decided to send a pull request for my misc drm branch because of teh
memset patch from Thierry for drm_*_cleanup functions (fixes drivers using
deferred probe) and the patch from Takashi. Everything else fairly
trivial.
Cheers, Daniel
The following changes since commit e5b5341c28c66a12
Is anyone else having problems reading the PRTS logs?
It looks like I got a merge failure complaint, presumably because I need
to rebase to a newer nightly tree. However, the log file itself does not
say anything useful. There is a bit of pre-amble which finishes by
saying 'This file include 3
From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915:
Cache ringbuf pointer in
Is anyone else having problems reading the PRTS logs?
[He, Shuang] Hello, than
On Wed, 2014-12-10 at 10:22 +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, Imre Deak wrote:
> > Register a component to be used to interface with the snd_hda_intel
> > driver. This is meant to replace the same interface that is currently
> > based on module symbol lookup.
> >
> > v2:
> > - chang
From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915:
Cache ringbuf pointer in
Is anyone else having problems reading the PRTS logs?
It looks like I got a
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
On 12/08/2014 06:36 PM, Daniel Vetter wrote:
On Mon, Dec 08, 2014 at 05:21:07PM +0200, Ander Conselvan de Oliveira wrote:
There are no more users of that pointer since the new config is now
passed down the call chain during mode set. Also, when the switch to
atomic happens, the right config (sta
On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > This added as a BUG_ON as it considered that no one would ever request
> > > an unaligned object. Ho
On Wed, Dec 10, 2014 at 02:49:05PM +0100, Daniel Vetter wrote:
> Faster feedback to errors is always better. This is inspired by the
> addition to WARN_ONs to mask/enable helpers for registers to make sure
> callers have the arguments ordered correctly: Pretty much always the
> arguments are static
On Wed, Dec 10, 2014 at 12:03:20PM +, Damien Lespiau wrote:
> On Wed, Dec 10, 2014 at 11:42:13AM +0200, Jani Nikula wrote:
> > Pushed to drm-intel-next-fixes, replacing the old version. Thanks for
> > the patch.
> >
> > Now the question is, do we want [1] for 3.19 or 3.20?
> >
> > [1]
> > ht
For CHT changes are required for calculating the correct m,n & p with
minimal error +/- for the required DSI clock, so that the correct dividor
& ctrl values are written in cck regs for DSI. This patch has been tested
on CHT RVP with 1200 x 1920 panel.
Signed-off-by: Gaurav K Singh
---
drivers/g
On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> According to updated BSpec, Render/Common Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
>
> Signed-off-by: Deepak S
> ---
>
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
On Mon, 08 Dec 2014, Damien Lespiau wrote:
> We may be hidding bugs by doing that, so let remove it and have the
> actual mask value shine through, for better or worse.
>
> Signed-off-by: Damien Lespiau
Pushed these two to drm-intel-next-fixes, thanks for the patches.
BR,
Jani.
> ---
> driv
On Wed, Dec 10, 2014 at 11:02:20AM +0100, Daniel Vetter wrote:
> Stupid userspace (there is no evil userspace in debugfs by assumption)
> might provoke a leak since we allocate the new array without holding
> any locks. Drop in an unconditional kfree to deal with this - kfree
> can handle NULL.
>
Signed-off-by: Thomas Wood
---
README | 46 +-
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/README b/README
index 8bdaebd..f1aab58 100644
--- a/README
+++ b/README
@@ -1,17 +1,22 @@
-This is a collection of tools for development and t
Signed-off-by: Thomas Wood
---
CONTRIBUTING | 9 +++--
MAINTAINERS | 2 ++
2 files changed, 5 insertions(+), 6 deletions(-)
create mode 100644 MAINTAINERS
diff --git a/CONTRIBUTING b/CONTRIBUTING
index 0ad0c3a..a2ddf09 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -33,12 +33,9 @@ A short
Signed-off-by: Thomas Wood
---
tools/ddi_compute_wrpll.c | 23 +++
tools/intel_l3_udev_listener.c| 23 +++
tools/quick_dump/chipset_macro_wrap.c | 23 +++
tools/skl_ddb_allocation.c| 23 +++
Signed-off-by: Thomas Wood
---
NEWS | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 103c7cd..447ba77 100644
--- a/NEWS
+++ b/NEWS
@@ -1,18 +1,30 @@
Release 1.9 (-XX-XX)
-- As usual piles of new testcases and
On Wed, Dec 10, 2014 at 02:53:01PM +0100, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> > On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > > This added as a BUG_ON as it
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance(). Historically some (display) code
didn't use be
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submis
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
On Wed, 10 Dec 2014, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
> ---
> CONTRIBUTING | 9 +++--
> MAINTAINERS | 2 ++
> 2 files changed, 5 insertions(+), 6 deletions(-)
> create mode 100644 MAINTAINERS
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 0ad0c3a..a2ddf09 100644
> ---
On Wed, Dec 10, 2014 at 03:07:08PM +, Dave Gordon wrote:
> @@ -401,11 +406,59 @@ static inline void intel_ring_emit(struct
> intel_engine_cs *ring,
> iowrite32(data, ringbuf->virtual_start + ringbuf->tail);
> ringbuf->tail += 4;
> }
> +
> +static inline void __intel_ringbuffer_beg
On 10/12/14 09:11, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
>> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
>>> On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
On Wednesday 10 December 2014 08:01 PM, Ville Syrjälä wrote:
On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
According to updated BSpec, Render/Common Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
From: Deepak S
According to updated BSpec, Render/Common/media Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.
v2: Update media forcewake range (Ville)
Signed-off-by: Deepak S
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submis
With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance(). Historically some (display) code
didn't use be
On Wed, Dec 10, 2014 at 03:07:07PM +, Dave Gordon wrote:
> When adding instructions to a legacy or LRC ringbuffer, the sequence of
> emit() calls must be preceded by a call to intel(_logical)_ring_begin()
> to reserve the required amount of space, and followed by a matching call
> to intel(_log
On Wed, Nov 12, 2014 at 12:13:03PM +, Nick Hoath wrote:
> On 12/11/2014 11:24, Chris Wilson wrote:
> >On Wed, Nov 12, 2014 at 10:53:26AM +, Nick Hoath wrote:
> > seq_putc(m, '\n');
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index
On Wed, Nov 12, 2014 at 10:53:22AM +, Nick Hoath wrote:
> This patchset merges execlist queue items in to gem requests. It does this by
> using the reference count added by John Harrison's "Replace seqno values with
> request structures" patchset to ensure that the gem request is available for
hey,
i have a dell xps 13 with an integrated intel adapter running on kubuntu
14.10, and a club3d csv5300 displayport hub with two attached dell displays.
i am currently using the 3.18 kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/
the problem is that the displays attache
On 2014-12-04 03:24, Jike Song wrote:
> Hi all,
>
> We are pleased to announce the first release of KVMGT project. KVMGT is
> the implementation of Intel GVT-g technology, a full GPU virtualization
> solution. Under Intel GVT-g, a virtual GPU instance is maintained for
> each VM, with part of per
On 10/12/14 10:58, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> The scheduler decouples the submission of batch buffers to the driver with
>> their
>> submission to the hardware. This basically means splitting the e
Hi Jon,
On 12/10/2014 03:06 AM, Bloomfield, Jon wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel Vetter
Sent: Tuesday, December 09, 2014 1:18 PM
To: Nguyen, Michael H
Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
Subject: R
On 10/12/14 10:40, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:06PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon
>>
>> Added various definitions that will be useful for the scheduler in general
>> and
>> pre-emptive context switching in particular.
>>
>> Change-Id: Ica805
We consistently use the _irq_handler postfix for functions called in
hardirq context. Especially when it's a non-static function hardirq is
a crazy enough calling context to warrant this level of ocd. So rename
it.
Cc: Thomas Daniel
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq
> -Original Message-
> From: Nguyen, Michael H
> Sent: Wednesday, December 10, 2014 4:34 PM
> To: Bloomfield, Jon
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for
> batch buffer pools
>
> Hi Jon,
>
> On 12/1
From now on for both DSI Ports A & C, the seq_port value has been
set to 0. seq_port value is parsed from Sequence block#53 of VBT.
So, for packets that needs to be read/write for DSI single link on
Port A and Port C will now be based on the DVO port from VBT block 2,
instead of seq_port.
Signed-o
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, December 10, 2014 4:44 PM
> To: Intel Graphics Development
> Cc: Daniel Vetter; Daniel, Thomas; Vetter, Daniel
> Subject: [PATCH] drm/i915: Call the lrc irq handler correctly
>
> We consistently u
On 09/12/2014 03:49, Tian, Kevin wrote:
> - Now we have XenGT/KVMGT separately maintained, and KVMGT lags
> behind XenGT regarding to features and qualities. Likely you'll continue
> see stale code (like Xen inst decoder) for some time. In the future we
> plan to maintain a single kernel repo for
On Wed, Dec 10, 2014 at 10:07:40PM +0530, Gaurav K Singh wrote:
> From now on for both DSI Ports A & C, the seq_port value has been
> set to 0. seq_port value is parsed from Sequence block#53 of VBT.
> So, for packets that needs to be read/write for DSI single link on
> Port A and Port C will now b
On 12/10/2014 08:41 AM, Bloomfield, Jon wrote:
why do we take the batch_pool lock in i915_gem_batch_pool_info() ?
i915_gem_batch_pool_info() is a new debugfs entry while
print_batch_pool_stats() is just an internal fnc, called from the
debugfs entry i915_gem_object_info(). i915_gem_object_inf
On Thu, Dec 11, 2014 at 09:42:49PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> According to updated BSpec, Render/Common/media Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
>
> v2: Update media forcewake
On Wed, Dec 10, 2014 at 04:33:14PM +, Dave Gordon wrote:
> On 10/12/14 10:58, Daniel Vetter wrote:
> > On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
> >> From: John Harrison
> >>
> >> The scheduler decouples the submission of batch buffers to the driver with
> >>
On 10/12/14 10:42, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:08PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon
>>
>> There is a workaround for a hardware bug when reading the seqno from the
>> status
>> page. The bug does not exist on VLV however, the workaround was sti
Log domains can be used to identify the source of log messages, such as
the test being run or the helper library.
v2: Add separate domains for different parts of the helper library and
use an empty default domain for applications.
Expand the log output to include the process name and the l
v2: add an "application" filter for the default domain (used by
applications)
Signed-off-by: Thomas Wood
---
docs/reference/intel-gpu-tools/igt_test_programs.xml | 6 --
lib/igt_core.c | 17 +++--
2 files changed, 19 insertions(+), 4 del
From: Tvrtko Ursulin
Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.
Added a GGTT view concept and linked it with the VMA to distinguish between
multiple instances per address space.
New objects and GEM functi
From: Tvrtko Ursulin
This series continues what was previously a single patch called "drm/i915:
Infrastructure for supporting different GGTT views per object".
v2:
* One less patch due early prep work getting merged.
* Main patch reworked to keep the pages pointer around for the lifetime of th
From: Tvrtko Ursulin
A short section describing background, implementation and intended usage.
v2:
* Align section name between template and DOC comment. (Michel Thierry)
For: VIZ-4544
Signed-off-by: Tvrtko Ursulin
---
Documentation/DocBook/drm.tmpl | 5
drivers/gpu/drm/i915/i9
On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
> irq_mask should include all IRQ bits that we want to mask, but atm we
> set it incorrectly to the inverse of this. If the mask is used
> subsequently to enable/disable some IRQ bits, we may unintentionally
> unmask unrelated IRQs. I can't
When querying the GTFIFOCTL register to check the FIFO space, the read value
must be masked. The operation is repeated explicitly in several places. This
change refactors the read-and-mask code into a function call.
v2: rebased on top of Mika's forcewake patch set, specifically:
[PATCH 8/8
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
Add a function to lock memory into RAM and use it in the
gem_tiled_swapping test to reduce the amount of allocated memory
required to force swapping. This also reduces the amount of time
required for the test to complete, since the data set is smaller.
The following durations were recorded on a ha
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 364/364 3
Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms. Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.
References: https://bugs.freedesktop.org/show_bug.cgi?id=76301
Signed-off-by: Jes
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next fram
Definition of VLV RR switch bit and corresponding toggling in
set_drrs function.
Signed-off-by: Vandana Kannan
Signed-off-by: Uma Shankar
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 10 --
2 files changed, 9 insertions(+), 2 de
Calls have been added to invalidate/flush DRRS whenever invalidate/flush is
called as part of frontbuffer tracking.
Apart from calls as a result of GEM tracking to fb invalidate/flush, a
call has been added to invalidate fb obj from crtc_page_flip as well. This
is to track busyness through flip cal
1 - 100 of 138 matches
Mail list logo
