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ä
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ä
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ä
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.
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
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
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 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
> > > > >
> > >
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 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
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: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
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: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: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: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: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: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: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: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 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 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
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 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
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
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
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
- 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 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
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
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
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
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
> > > >
> > >
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 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
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
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 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
> 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 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, 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
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 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
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/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
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
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 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
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-
101 - 156 of 156 matches
Mail list logo
