On Wed, Aug 12, 2015 at 9:26 PM, Ville Syrjälä
wrote:
> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
>> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
>> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek
>> > wrote:
>> >> Hi,
>> >>
>> >> this my first build of a 4.2-rcN Linux-
On Thu, Aug 13, 2015 at 1:37 AM, Lukas Wunner wrote:
> Hi Daniel,
>
> On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote:
>> > * Reprobing if the inactive GPU initializes before the apple-gmux module:
>> > v1 used Matthew Garrett's approach of adding a driver callback.
>> > v2 simpl
sdvo is still using color_range name in it's functions. would be good to
rename that as well along with dp & hdmi done here.
otherwise changes are fine
Reviewed-by: Sivakumar Thulasimani
On Monday 06 July 2015 05:40 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Currently we tr
On Wed, 2015-08-12 at 15:43 +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 04:42:53PM +0300, Jani Nikula wrote:
> > On Wed, 12 Aug 2015, Daniel Vetter wrote:
> > > On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote:
> > >> Depending on the VBT BDB version the maximum size
> > >> ca
On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote:
On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
-Original Message-
From: Vivi, Rodrigo
Sent: Saturday, August 8, 2015 8:34 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rod
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7112
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On 8/12/2015 6:26 PM, Daniel Vetter wrote:
On Mon, Aug 10, 2015 at 05:51:48PM +0530, Sivakumar Thulasimani wrote:
On 8/10/2015 5:44 PM, Jani Nikula wrote:
On Mon, 10 Aug 2015, Sivakumar Thulasimani
wrote:
On 8/10/2015 5:07 PM, Jani Nikula wrote:
On Mon, 10 Aug 2015, Sivakumar Thulasimani
Hi, Ville
Have you reported this to the owner of the backlight core?
This looks like a bug that the backlight core should handle.
What intel backlight driver and acpi backlight driver have done here are just
invoking APIs provided by the backlight core.
So it is the duty of the backlight core to
> On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
> > > On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
> > > > > -Original Message-
> > > > > From: Vivi, Rodrigo
> > > > > Sent: Saturday, August 8, 2015 8:34 AM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: V
On Wednesday 15 July 2015 11:34:43 Daniel Vetter wrote:
> On Tue, Jul 14, 2015 at 01:37:32PM -0700, Greg KH wrote:
> > On Tue, Jul 14, 2015 at 11:22:35AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 13, 2015 at 09:36:45AM -0700, jay.p.pa...@intel.com wrote:
> > > > From: Jay Patel
> > > >
> > >
> On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
> > DDI-E doesn't have the correspondent GMBUS pin.
> >
> > We rely on VBT to tell us which one it being used instead.
> >
> > The DVI/HDMI on shared port couldn't exist.
> >
> > This patch isn't tested without hardware wchich has HDMI
On Wed, Aug 12, 2015 at 07:57:37AM -0700, Gordon, David S wrote:
> On 12/08/15 15:43, Dave Gordon wrote:
> > This patch series enables command submission via the GuC. In this mode,
> > instead of the host CPU driving the execlist port directly, it hands
> > over work items to the GuC, using a doorb
Thanks for the quick fix! Comments below...
On 08/12/2015 11:43 AM, Daniel Vetter wrote:
In
commit d328c9d78d64ca11e744fe227096990430a88477
Author: Daniel Vetter
Date: Fri Apr 10 16:22:37 2015 +0200
drm/i915: Select starting pipe bpp irrespective or the primary plane
we started to sel
On Wed, Aug 12, 2015 at 03:10:18PM +0300, Joonas Lahtinen wrote:
> On ke, 2015-08-12 at 12:26 +0100, Arun Siluvery wrote:
> > From Gen9, by default push constant command is not committed to the
> > shader unit
> > untill the corresponding shader's BTP_* command is parsed. This is
> > the
> > beha
On Monday, August 10, 2015 08:29:00 PM Sedat Dilek wrote:
> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek wrote:
> >> Hi,
> >>
> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> >>
> >
> > Just FYI:
> >
> > I am *not* seei
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7110
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Wed, Jul 15, 2015 at 2:34 AM, Daniel Vetter wrote:
>
> On Tue, Jul 14, 2015 at 01:37:32PM -0700, Greg KH wrote:
> > On Tue, Jul 14, 2015 at 11:22:35AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 13, 2015 at 09:36:45AM -0700, jay.p.pa...@intel.com wrote:
> > > > From: Jay Patel
> > > >
> > >
Hi Daniel,
On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote:
> > * Reprobing if the inactive GPU initializes before the apple-gmux module:
> > v1 used Matthew Garrett's approach of adding a driver callback.
> > v2 simply generates a hotplug event instead. nouveau polls its outputs
It requires i915 changes to add end_cpu_access().
Signed-off-by: Tiago Vignatti
---
tests/kms_mmap_write_crc.c | 63 --
1 file changed, 55 insertions(+), 8 deletions(-)
diff --git a/tests/kms_mmap_write_crc.c b/tests/kms_mmap_write_crc.c
index e24d535
This program can be used to detect when the writes don't land in scanout due
cache incoherency. Although this seems a problem inherently of non-LCC machines
("Atom"), this particular test catches a cache dirt on scanout on LLC machines
as well. It's inspired in Ville's kms_pwrite_crc.c and can be u
This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.
This test also adds test_forked_cpu_write, which creates the GEM bo in one
p
From: Rob Bradford
This test has the following subtests:
- test_correct for correctness of the data
- test_map_unmap checks for mapping idempotency
- test_reprime checks for dma-buf creation idempotency
- test_forked checks for multiprocess access
- test_refcounting checks for buffer referen
From: Daniel Thompson
Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.
It is trivial to relax the restriction and permit read/write a
- Remove pattern_check(), which was walking through a useless iterator
- Remove superfluous PROT_WRITE from gem_mmap, in test_correct()
- Add binary file to .gitignore
Signed-off-by: Tiago Vignatti
---
tests/.gitignore | 1 +
tests/prime_mmap.c | 37 -
2 fi
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index e9c2bfd..8447ba4 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++
Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.
v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
v3: Fix return values.
v4: !obj->base.filp is user triggerable, so removed the WA
This patch moves userptr definitions and helpers implementation that were
locally in gem_userptr_benchmark and gem_userptr_blits to the library, so other
tests can make use of them as well. There's no functional changes.
Signed-off-by: Tiago Vignatti
---
benchmarks/gem_userptr_benchmark.c | 45 +
A userptr doesn't have the obj->base.filp, but can be exported via dma-buf, so
make sure it fails when mmaping.
Signed-off-by: Tiago Vignatti
---
In machine, export the handle to fd is actually returning error and falling
before the actual test happens. Same issue happens in gem_userptr_blits's
t
From: Daniel Vetter
The userspace might need some sort of cache coherency management e.g. when CPU
and GPU domains are being accessed through dma-buf at the same time. To
circumvent this problem there are begin/end coherency markers, that forward
directly to existing dma-buf device drivers vfunc
Hi,
The idea is to create a GEM bo in one process and pass the prime handle of the
it to another process, which in turn uses the handle only to map and write.
This could be useful for Chrome OS architecture, where the Web content
("unpriviledged process") maps and CPU-draws a buffer, which was pre
We need to test those pixel formats on the FBC code, so let's make
sure the drawing library works on them first.
Signed-off-by: Paulo Zanoni
---
lib/igt_draw.c | 162 +++
lib/igt_draw.h | 2 +-
tests/kms_draw_crc.c
On 11.08.2015 10:05, Zhang, Xiong Y wrote:
>> -Original Message-
>> From: Vivi, Rodrigo
>> Sent: Saturday, August 8, 2015 8:34 AM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Vivi, Rodrigo; Zhang, Xiong Y
>> Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
>>
>> DDI-A and
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7109
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek wrote:
> >> Hi,
> >>
> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> >>
> >
> > Just FYI:
> >
> > I am *not* s
On Wed, Aug 12, 2015 at 08:30:23PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 31, 2015 at 03:13:50PM +0300, Mika Kahola wrote:
> > Store max dotclock into dev_priv structure so we are able
> > to filter out the modes that are not supported by our
> > platforms.
> >
> > V2:
> > - limit the max dot c
On Fri, Jul 31, 2015 at 03:13:56PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:51PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:58PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:59PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:52PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:57PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:55PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:54PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 31, 2015 at 03:13:53PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7106
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Fri, Jul 31, 2015 at 03:13:50PM +0300, Mika Kahola wrote:
> Store max dotclock into dev_priv structure so we are able
> to filter out the modes that are not supported by our
> platforms.
>
> V2:
> - limit the max dot clock frequency to max CD clock frequency
> for the gen9 and above
> - limit
On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
> > On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
> > > > -Original Message-
> > > > From: Vivi, Rodrigo
> > > > Sent: Saturday, August 8, 2015 8:34 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Vivi, Rodrigo;
On Wed, 2015-08-12 at 14:32 +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 10:27:08AM +, Zhang, Xiong Y wrote:
> > > On Tue, 2015-08-11 at 11:47 +0200, Daniel Vetter wrote:
> > > > On Thu, Aug 06, 2015 at 03:51:39PM +0800, Xiong Zhang wrote:
> > > > > From: Rodrigo Vivi
> > > > >
> > >
This WA doesn't have a name. According to WA ID 0555 in spec, driver need to
reset disable gather at set shader bit in per ctx WA batch. It is to be noted
that the default value is already '0' for this bit but we still need to apply
this WA because userspace may set it. If userspace really need it
On Mon, Jul 06, 2015 at 03:09:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> While working on CHV DPIO powergating I relized DP .compute_config() was
> clobbering lane_count etc. stored in intel_dp. This could cause problems
> if we do the .compute_config() but later f
On 12/08/2015 16:41, Dave Gordon wrote:
On 11/08/15 15:44, Arun Siluvery wrote:
From Gen9, Push constant instruction parsing behaviour varies
according to
whether set shader is enabled or not. If we want legacy behaviour then it
can be achieved by disabling set shader.
Bugzilla: https://bugs.f
From: Ville Syrjälä
On SKL the port A HPD has moved to the PCH. Hook it up.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 21 +++--
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: Ville Syrjälä
Starting from SPT the only interrupts living in the south are GMBUS and
HPD. What's worse some of the SPT specific new bits conflict with some
other bits on earlier PCH generations. So better not use the
cpt_irq_handler() for SPT+ anymore.
Also kill the hand rolled port E han
From: Ville Syrjälä
Extract the core of ironlake_{enable,disable}_display_irq() into a new
function. We'll have further use for it later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 39 ---
1 file changed, 24 insertions(+), 15 deletion
From: Ville Syrjälä
As with ILK/SNB wire up the port A HPD on IVB/HSW.
This might be more important on HSW with PSR. BSpec tells us that if the
automagic link training performed by the hardware fails for some reason,
we're going to get a short HPD and are supposed to re-train the link
manyally.
From: Ville Syrjälä
Make LPT:LP checks look neater by wrapping the details in a
new HAS_PCH_LPT_LP() macro.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 f
From: Ville Syrjälä
Eliminate a bunch of duplicated code that calculates the currently
enabled HPD interrupt bits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 43 -
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/dr
From: Ville Syrjälä
ILK/SNB support port A HPD. While HPD is optional on eDP let's at least
try to wite it up so that we might notice if the link has issues.
The eDP spec suggests that if HPD is not wired up, one should poll the
link status instead. We don't even do that currently.
Signed-off-b
From: Ville Syrjälä
Supposedly we have to enable port A HPD also in the south on LPT:LP.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d994b80..de601
From: Ville Syrjälä
Wire up the port A HPD for BDW. Compared to earlier platforms the
interrupt setup is a bit different, but basically everything else
looks the same.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 72 +
1 file change
From: Ville Syrjälä
I've had a bunch of this stuff sitting in a branch for quite a while, almost a
year by the looks of the git dates :P I also had port E HPD in there but
something similar has already landed in the meantime so I just rebased my
junk on top.
I've only quickly tested the port A H
From: Ville Syrjälä
The PORTA HPD defines are not BXT specific. They also exist on SPT,
and partially already on LPT:LP.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
From: Ville Syrjälä
Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space
vs. tab issues.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 72 +
1 file changed, 37 insertions(+), 35 deletions(-)
diff --git a/drivers/gp
On 11/08/15 15:44, Arun Siluvery wrote:
From Gen9, Push constant instruction parsing behaviour varies according to
whether set shader is enabled or not. If we want legacy behaviour then it
can be achieved by disabling set shader.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
Cc:
On 11/08/15 15:44, Arun Siluvery wrote:
From: Mika Kuoppala
Prevent leaking the if scoping by containing the WA_REG
macro inside its own scope.
Reported-by: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 12, 2015 9:43 PM
> To: Jani Nikula
> Cc: Daniel Vetter; Yang, Libin; alsa-de...@alsa-project.org;
> ti...@suse.de; intel-gfx@lists.freedesktop.org; d
On 12/08/15 08:56, Thierry, Michel wrote:
On 8/11/2015 1:05 PM, Zhiyuan Lv wrote:
Hi Mika/Dave/Michel,
I saw the patch of using LRI for root pointer update has been merged to
drm-intel. When we consider i915 driver to run inside a virtual machine, e.g.
with XenGT, we may still need Mika's this
On 12/08/15 15:43, Dave Gordon wrote:
This patch series enables command submission via the GuC. In this mode,
instead of the host CPU driving the execlist port directly, it hands
over work items to the GuC, using a doorbell mechanism to tell the GuC
that new items have been added to its work queu
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, August 12, 2015 10:45 PM
> To: Yang, Libin; Daniel Vetter
> Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: RE: [
For both patches,
Reviewed-by: Ander Conselvan de Oliveira
On Tue, 2015-08-11 at 12:31 +0200, Maarten Lankhorst wrote:
> This patch is based on the upstream commit 5ac1c4bcf073ad and amended
> for v4.2 to make sure it works as intended.
>
> Repeated calls to begin_crtc_commit can cause warnings
From: Alex Dai
This fetches the required firmware image from the filesystem,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky.
v2:
Various improvements per review comments by Chris Wils
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use; doorbel
Turn on interrupt steering to route necessary interrupts to GuC.
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +
2 files
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
v5:
Added GuC per-engine submission & seqno statistics
v6:
Add per-ring statistics to client, refactor client-dumper.
Signed-off-by: Dav
From: Alex Dai
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address that is NOT in the
From: Alex Dai
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes
From: Alex Dai
The new node provides access to the status of the GuC-specific loader;
also the scratch registers used for communication between the i915
driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
v6:
Rebased
Issue: VIZ-4884
Signed-off-by:
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to describe a context for submission via
the GuC, we need one of the same functions used in execlist mode.
This commit exposes one such function,
This patch series enables command submission via the GuC. In this mode,
instead of the host CPU driving the execlist port directly, it hands
over work items to the GuC, using a doorbell mechanism to tell the GuC
that new items have been added to its work queue. The GuC then dispatches
contexts to t
From: Alex Dai
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drive
On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> Hi Daniel,
>
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
>> Daniel Vetter
>> Sent: Wednesday, August 12, 2015 9:06 PM
>> To: Jani Nikula
>> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de;
On Wed, Aug 12, 2015 at 04:54:09PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 12, 2015 at 01:08:22PM +0100, Chris Wilson wrote:
> > When we queue the command or operation to change the scanout address, we
> > mark the flip as in progress. We can use this flag to prevent us from
> > checking for a st
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 12, 2015 9:06 PM
> To: Jani Nikula
> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 12, 2015 9:05 PM
> To: Jani Nikula
> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@
On Wed, Aug 12, 2015 at 03:14:53PM +0100, Chris Wilson wrote:
> On Wed, Aug 12, 2015 at 04:45:39PM +0300, Ville Syrjälä wrote:
> > > - /*
> > > - * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> > > - * for DP the encoder type can be set by the caller to
> > > - * INTEL_OUTPUT
On Thu, 16 Jul 2015, Damien Lespiau wrote:
> On Thu, Jul 16, 2015 at 07:36:51PM +0300, Mika Kuoppala wrote:
>> Fix divide by zero if we end up updating the watermarks
>> with zero dotclock.
>>
>> This is a stop gap measure to allow module load in cases
>> where our state keeping fails.
>>
>> v2:
Hi Tiago,
Thanks for the patch!
On 12 August 2015 at 02:29, Tiago Vignatti wrote:
> From: Daniel Vetter
>
> FIXME: Update kerneldoc for begin/end to make it clear that those are
> for mmap too.
I think if we're going to add this patch upstream, atleast the FIXMEs
should be fixed.
>
> Open: Do
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7093
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Wed, 12 Aug 2015, David Weinehall wrote:
> Some more fixup is needed; the bits from Antti's patch
> that actually expanded the struct to fully fit the newer
> versions of the child_device_config was part of the second
> patch; since that patch hasn't been merged yet we need this bit:
>
> This a
On Tue, Aug 11, 2015 at 12:29:17PM +0200, Lukas Wunner wrote:
> This is a follow-up to the v1 posted in April:
> http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
>
>
> Patches 1 - 17 enable GPU switching on the pre-retina MacBook Pro.
> These were tested successfully by mult
On Wed, 12 Aug 2015, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote:
>> On Wed, 12 Aug 2015, Daniel Vetter wrote:
>> > It sounds like we actually need to ping the audio side _before_ we do the
>>
>> Do you mean "read _HSW_AUD_STR_DESC_*" by "ping the audio sid
On Wed, Aug 12, 2015 at 04:45:39PM +0300, Ville Syrjälä wrote:
> > - /*
> > -* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> > -* for DP the encoder type can be set by the caller to
> > -* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> > -*/
> > - if (t
On Wed, Aug 12, 2015 at 01:08:22PM +0100, Chris Wilson wrote:
> When we queue the command or operation to change the scanout address, we
> mark the flip as in progress. We can use this flag to prevent us from
> checking for a stalled flip prior to its existence!
>
> Signed-off-by: Chris Wilson
>
On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote:
> >
> >
> > On 8/12/2015 5:02 PM, Ville Syrjälä wrote:
> > > On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:
> > >> From: "Thulasimani,Siv
On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:
> We follow the VBT as to whether a DDI port is used for eDP and if so, do
> not attach a HDMI encoder to it. However there are machines for which
> the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link.
> Furthermore, o
On Wed, Aug 12, 2015 at 04:42:53PM +0300, Jani Nikula wrote:
> On Wed, 12 Aug 2015, Daniel Vetter wrote:
> > On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote:
> >> Depending on the VBT BDB version the maximum size
> >> can be up to 38 bytes.
> >>
> >> This fix increases the maximum of
On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote:
> On Wed, 12 Aug 2015, Daniel Vetter wrote:
> > On Wed, Aug 12, 2015 at 09:20:17AM +0300, Jani Nikula wrote:
> >> On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> >> > Hi Jani,
> >> >
> >> >> -Original Message-
> >> >> From: Jani Nik
On Wed, 12 Aug 2015, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote:
>> Depending on the VBT BDB version the maximum size
>> can be up to 38 bytes.
>>
>> This fix increases the maximum of the VBT expected size
>> from 33 bytes to 38 bytes and by doing so cures
jn Wed, Aug 12, 2015 at 03:23:45PM +0530, vikas.korj...@intel.com wrote:
> From: vkorjani
>
> s RFC is for feature Display Stream Compression (DSC) for BXT,
> It is a VESA defined standard to compress and decompress image in display
> streams in a link independent manner. Some of the basic requir
On Wed, Aug 12, 2015 at 03:23:48PM +0530, vikas.korj...@intel.com wrote:
> From: vkorjani
>
> This patch adds code to initialize Picture Parameter set (PPS)
> data structure for DSC.
> DSC is enabled than the bitrate should be calculated using the
> formula pixel_clock * bits_per_pixel / lane_co
1 - 100 of 156 matches
Mail list logo
