> -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 DDI-E shares the 4 lanes. So when DDI-E is presen
On Tue, 11 Aug 2015, "Yang, Libin" wrote:
> Hi Jani,
>
> Thanks for careful reviewing for all the patches, please
> see my comments.
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Monday, August 10, 2015 8:10 PM
>> To: Yang, Libin; alsa-de...@als
Reviewed-by: Xiong Zhang
thanks
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Saturday, August 8, 2015 8:35 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vivi, Rodrigo; Zhang, Xiong Y
> Subject: [PATCH 8/6] drm/i915/skl: Enable DDI-E
>
> There are OEMs using DDI-E out there,
> so l
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Tuesday, August 11, 2015 3:14 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: RE: [Intel-gfx] [PATCH v4 4/
The port is removed synchronously, but the connector delayed.
This causes a use after free which can cause a kernel BUG with
slug_debug=FPZU. This is fixed by freeing the port after the
connector.
This fixes a regression introduced with
6b8eeca65b18ae77e175cc2b6571731f0ee413bf
"drm/dp/mst: close d
Without this when a MST connector is removed drm_atomic_helper_set_config
can complain about set->mode && !set->num_connectors.
[ cut here ]
WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_helper.c:1673
drm_atomic_helper_set_config+0x22e/0x420()
CPU: 2 PID: 2403 Co
On Tue, 11 Aug 2015, "Yang, Libin" wrote:
> Hi Jani,
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Tuesday, August 11, 2015 3:14 PM
>> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
>> g...@lists.freedesktop.org; daniel.vet.
On Tue, Aug 11, 2015 at 09:54:59AM +0200, Maarten Lankhorst wrote:
> Without this when a MST connector is removed drm_atomic_helper_set_config
> can complain about set->mode && !set->num_connectors.
>
> [ cut here ]
> WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_
On Tue, Aug 11, 2015 at 09:54:29AM +0200, Maarten Lankhorst wrote:
> The port is removed synchronously, but the connector delayed.
> This causes a use after free which can cause a kernel BUG with
> slug_debug=FPZU. This is fixed by freeing the port after the
> connector.
>
> This fixes a regressio
On Tue, Aug 11, 2015 at 04:30:10AM +, Jindal, Sonika wrote:
> I replied to Daniel last time. Pasting it on mailing list as well:
>
> "Yes this is tested on android with HW tracking. Not sure about enabling
> by default part. But this patch will be anyways required.
I'd like it to be tested wi
On Tue, 11 Aug 2015, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 09:54:29AM +0200, Maarten Lankhorst wrote:
>> The port is removed synchronously, but the connector delayed.
>> This causes a use after free which can cause a kernel BUG with
>> slug_debug=FPZU. This is fixed by freeing the port af
On Mon, Aug 10, 2015 at 11:15:30AM +0100, Chris Wilson wrote:
> On Mon, Aug 03, 2015 at 01:09:11PM -0700, Jesse Barnes wrote:
> > Looks like
> >
> > commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
> > Author: Maarten Lankhorst
> > Date: Mon Jun 15 12:33:53 2015 +0200
> > drm/i915: Update le
On Mon, Aug 10, 2015 at 07:06:44PM +0100, Chris Wilson wrote:
> On Mon, Aug 10, 2015 at 02:57:32PM -0300, Paulo Zanoni wrote:
> > I started digging this when I noticed that the BDW code was just
> > reserving 1mb by coincidence since it was reading reserved fields.
> > Then I noticed we didn't have
On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote:
>
>
> On 8/10/2015 1:38 PM, Daniel Vetter wrote:
> >On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote:
> >>Hi Daniel,
> >>
> >>That patch was already merged:
> >>http://lists.freedesktop.org/archives/intel-gfx/2015-July/
On Tue, Aug 11, 2015 at 11:30:48AM +0200, Daniel Vetter wrote:
> On Mon, Aug 10, 2015 at 11:15:30AM +0100, Chris Wilson wrote:
> > On Mon, Aug 03, 2015 at 01:09:11PM -0700, Jesse Barnes wrote:
> > > Looks like
> > >
> > > commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
> > > Author: Maarten Lankho
On Thu, Aug 06, 2015 at 03:51:39PM +0800, Xiong Zhang wrote:
> From: Rodrigo Vivi
>
> On Skylake we have eDP-to-VGA using DDI-E and another aux.
> So let's identify it properly.
eDP means panel (the only difference in the code we have between eDP and
DP is the power panel sequncing). VGA very mu
On Thu, Aug 06, 2015 at 03:51:41PM +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 DDI-E.
>
On Mon, Aug 10, 2015 at 02:01:56PM +0300, Jani Nikula wrote:
> On Mon, 10 Aug 2015, Jani Nikula wrote:
> > On Thu, 06 Aug 2015, Mika Kuoppala wrote:
> >> If we encounter frequent problems with dp aux channel
> >> communications, we end up spamming the dmesg with the
> >> exact similar trace and s
On Fri, Aug 07, 2015 at 03:30:12PM +0100, Siluvery, Arun wrote:
> On 07/08/2015 12:52, Daniel Vetter wrote:
> >On Fri, Aug 07, 2015 at 11:15:56AM +0300, Mika Kuoppala wrote:
> >>Daniel Vetter writes:
> >>
> >>>On Thu, Aug 06, 2015 at 05:09:17PM +0300, Mika Kuoppala wrote:
> If idle to active b
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6996
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -2
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, August 11, 2015 5:47 PM
> To: Zhang, Xiong Y
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
> Subject: Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI
On Mon, Aug 10, 2015 at 09:16:46PM +0100, Chris Wilson wrote:
> If the set of pages is being imported from another device, we cannot
> assume that it is fully coherent with the CPU cache, so mark it as such.
> However, if the source is the shared memory vgem allocator, we could
> treat the buffer a
On Tue, Aug 11, 2015 at 12:12:08PM +0200, Daniel Vetter wrote:
> On Mon, Aug 10, 2015 at 09:16:46PM +0100, Chris Wilson wrote:
> > If the set of pages is being imported from another device, we cannot
> > assume that it is fully coherent with the CPU cache, so mark it as such.
> > However, if the so
This should be much cleaner, with the same effects.
(cherry picked from commit fb9d6cf8c29bfcb0b3c602f7ded87f128d730382)
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matt Roper
Signed-off-by: Jani Nikula
Cc: sta...@vger.kernel.org #v4.2
References: https://bugs.freedesktop.org/show_bug.cgi?id=
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 like this:
[ 169.127746] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:616
[ 169.127835] in_ato
Op 10-08-15 om 13:34 schreef Daniel Vetter:
> Instead of our own duplicated one. This fixes a bug in the driver
> unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> try to unregister the nonexistent fbdev drm_framebuffer.
>
> Cc: Archit Taneja
> Cc: Maarten Lankhorst
> Reporte
HI Daniel,
Looks like we are not getting an IVB machine here. I think instead of blocking
the patch set for the whole series, we can just block it for the platforms we
don’t get success for.
We are shipping many VLV/CHV systems with these patches applied, and they are
passing all Android test
On Tue, 11 Aug 2015, Maarten Lankhorst
wrote:
> This should be much cleaner, with the same effects.
>
> (cherry picked from commit fb9d6cf8c29bfcb0b3c602f7ded87f128d730382)
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Matt Roper
> Signed-off-by: Jani Nikula
> Cc: sta...@vger.kernel.org #v
Op 10-08-15 om 13:34 schreef Daniel Vetter:
> Instead of our own duplicated one. This fixes a bug in the driver
> unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> try to unregister the nonexistent fbdev drm_framebuffer.
>
> Cc: Archit Taneja
> Cc: Maarten Lankhorst
> Reporte
Op 11-08-15 om 13:12 schreef Jani Nikula:
> On Tue, 11 Aug 2015, Maarten Lankhorst
> wrote:
>> This should be much cleaner, with the same effects.
>>
>> (cherry picked from commit fb9d6cf8c29bfcb0b3c602f7ded87f128d730382)
>> Signed-off-by: Maarten Lankhorst
>> Reviewed-by: Matt Roper
>> Signed-
On Mon, Aug 10, 2015 at 03:02:44PM +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 DDI-E.
>
On Tue, Aug 11, 2015 at 01:25:08PM +0200, Maarten Lankhorst wrote:
> Op 10-08-15 om 13:34 schreef Daniel Vetter:
> > Instead of our own duplicated one. This fixes a bug in the driver
> > unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> > try to unregister the nonexistent fbdev
Don't set the size of bindless surface state on rendercopy.
And as of doing so, take into account the workaround for setting
the command size.
This was tried during hunting for
https://bugs.freedesktop.org/show_bug.cgi?id=89959. But no
impact was found.
Cc: Arun Siluvery
Signed-off-by: Mika Kuop
On Fri, Aug 07, 2015 at 11:05:24AM +0100, Nick Hoath wrote:
> Clean up lrc context init by:
>- Move context initialisation in to i915_gem_init_hw
>- Move one off initialisation for render ring to
> i915_gem_validate_context
>- Move default context initialisation to logical_ring_
On Tue, Aug 11, 2015 at 11:24:58AM +0100, Chris Wilson wrote:
> On Tue, Aug 11, 2015 at 12:12:08PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 10, 2015 at 09:16:46PM +0100, Chris Wilson wrote:
> > > If the set of pages is being imported from another device, we cannot
> > > assume that it is fully c
On Tue, Aug 11, 2015 at 02:58:59PM +0200, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 11:24:58AM +0100, Chris Wilson wrote:
> > On Tue, Aug 11, 2015 at 12:12:08PM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 10, 2015 at 09:16:46PM +0100, Chris Wilson wrote:
> > > > If the set of pages is being
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 the kernel
hang on BSW box.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_bios.h | 2 +-
1 file changed, 1
From: Ville Syrjälä
Currently we don't clflush on pin_to_display if the bo is already
UC/WT and is not in the CPU write domain. This causes problems with
pwrite since pwrite doesn't change the write domain, and it avoids
clflushing on UC/WT buffers on LLC platforms unless the buffer is
currently
From: Ville Syrjälä
igt_plane_set_fb()+igt_display_commit() have too much overhead, and that
causes the cache to get flushed before we flip, making the test
useless, at least on machines with small LLC. Switch to
drmModeSetPlane() to reduce the chance that the cache gets flushed
before we grab th
On Tue, Aug 11, 2015 at 04:59:14PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we don't clflush on pin_to_display if the bo is already
> UC/WT and is not in the CPU write domain. This causes problems with
> pwrite since pwrite doesn't change the write domain, a
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7001
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
Patch1 fixes a simple compile error in Patch2
Patch2 fixes gpu hang observed with a subtest of gem_concurrent_blit.
Arun Siluvery (1):
drm/i915/gen9: Disable gather at set shader bit
Mika Kuoppala (1):
drm/i915: Contain the WA_REG macro
drivers/gpu/drm/i915/i915_reg.h | 5 +
dr
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: Ben Widawsky
Cc: Joonas Lahtinen
Cc: Mik
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 deletions(-)
diff --git a/drivers/gpu/drm/i
On Tue, Aug 11, 2015 at 03:28:27PM +0100, Chris Wilson wrote:
> On Tue, Aug 11, 2015 at 04:59:14PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently we don't clflush on pin_to_display if the bo is already
> > UC/WT and is not in the CPU write domain. This cause
On Tue, Aug 11, 2015 at 05:56:28PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 11, 2015 at 03:28:27PM +0100, Chris Wilson wrote:
> > On Tue, Aug 11, 2015 at 04:59:14PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Currently we don't clflush on pin_to_display
On Tue, Aug 11, 2015 at 06:10:29PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 11, 2015 at 05:56:28PM +0300, Ville Syrjälä wrote:
> > Hmm. So what would happen on !LLC if we start with a cached bo, then pwrite
> > it
> > and afterwards make it uncached?
>
> In fact that would still fail even with m
The drm_open_driver*() functions replace the drm_open_any*() functions and
provide the same utility, but in a way that is platform agnostic, not
intel-specific. This opens the path for adopting intel-gpu-tools to non-intel
platforms.
This commit renames the calls and adds the chipset parameter wh
Changes since last version of patch:
Addressed comments from danvet and Chris Wilson:
- removed api doc for __get_drm_device_name
- included coccinelle script with commit
- added signed-off-by and detailed comments to commit messages, including
justification of drm_read changes
- updated codi
Apply the new API to all call sites within the test suite using the following
semantic patch:
// Semantic patch for replacing drm_open_any* with arch-specific
drm_open_driver* calls
@@
identifier i =~ "\bdrm_open_any\b";
@@
- i()
+ drm_open_driver(DRIVER_INTEL)
@@
identifier i =~ "\bdrm_open_any
Signed-off-by: Micah Fedke
---
lib/drmtest.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/lib/drmtest.h b/lib/drmtest.h
index dcb0c34..41ddbe7 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -41,12 +41,6 @@
#define OPEN_ANY_GPU 0x1
#define DRIVER_INTEL (0x1 << 1)
-/* provide th
There is some miscellaneous plumbing to do if we are going to have a test that
runs on all platforms. intel and exynos are the current targets. The test we
are aiming to support is drm_read. There is much intel-specific code
throughout the support library, so anyone attempting to make other tes
Update the drm_read test to operate on any platform to demonstrate the use of
drm_open_driver(OPEN_ANY_GPU).
To work on exynos, the event generation code is converted to use the new CRTC
selection API for vblank. The first valid crtc is selected at fixture-time.
pipe0_enabled() is updated to us
On Tue, Aug 11, 2015 at 11:59:16AM -0400, Micah Fedke wrote:
>
> Update the drm_read test to operate on any platform to demonstrate the use of
> drm_open_driver(OPEN_ANY_GPU).
>
> To work on exynos, the event generation code is converted to use the new CRTC
> selection API for vblank. The first
From: Ville Syrjälä
Currently we don't clflush on pin_to_display if the bo is already
UC/WT and is not in the CPU write domain. This causes problems with
pwrite since pwrite doesn't change the write domain, and it avoids
clflushing on UC/WT buffers on LLC platforms unless the buffer is
currently
From: Ville Syrjälä
The test does the following
1. set_domain src GTT
2. set_caching src NONE
3. pwrite src
4. set_caching src CACHED
5. blt src->dst
6. pread dst
7. verify data matches
Signed-off-by: Ville Syrjälä
---
tests/Makefile.sources | 1 +
tests/gem_pwrite_snooped.c | 140 ++
On Tue, Aug 11, 2015 at 07:47:10PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we don't clflush on pin_to_display if the bo is already
> UC/WT and is not in the CPU write domain. This causes problems with
> pwrite since pwrite doesn't change the write domain, a
From: Ville Syrjälä
Use port_clock instead of link_bw when picking the PLL parameters for
DP. link_bw may be zero with an eDP 1.4 sink that supports
DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it
to the sink appropriately.
v2: Fix typo in commit message (Sivakumar)
Revi
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; Zhang, Xiong Y
> > Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 la
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7018
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
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 Skylake we have eDP-to-VGA using DDI-E and another aux.
> > So let's identify it properly.
>
> eDP means panel (the only difference in the code
On 11.08.2015 17:44, Arun Siluvery wrote:
> Patch1 fixes a simple compile error in Patch2
> Patch2 fixes gpu hang observed with a subtest of gem_concurrent_blit.
>
> Arun Siluvery (1):
> drm/i915/gen9: Disable gather at set shader bit
>
> Mika Kuoppala (1):
> drm/i915: Contain the WA_REG macr
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
From: Daniel Vetter
FIXME: Update kerneldoc for begin/end to make it clear that those are
for mmap too.
Open: Do we need a special indication that the begin/end is from
userspace mmap and not from kernel mmap?
There's also the question already about kernel internal users - vmap
and kmap interfa
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.
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/
- 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
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
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
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 pr
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
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7059
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Tue, Aug 11, 2015 at 05:59:23PM -0300, Tiago Vignatti wrote:
> 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
On 08/07/2015 09:14 AM, Daniel Vetter wrote:
On Fri, Aug 07, 2015 at 12:45:52AM +0200, Mario Kleiner wrote:
On 08/07/2015 12:12 AM, Daniel Vetter wrote:
On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner
wrote:
Hi Daniel and all,
since Linux 4.2 (tested with rc4), i think this commit
d328c9d78d6
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7067
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -2
> 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; Zhang, Xiong Y
> > > Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Tuesday, August 11, 2015 4:14 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: RE: [Intel-gfx] [PATCH v4 4/
Hi,
> -Original Message-
> From: Yang, Libin
> Sent: Tuesday, August 11, 2015 10:41 AM
> To: Jani Nikula; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: RE: [Intel-gfx] [PATCH v2 1/4] drm/i915: Add audio set_ncts
> callbac
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7070
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
Hi Daniel,
any comments for the patch below ?
regards,
Sivakumar
On Friday 07 August 2015 03:14 PM, Sivakumar Thulasimani wrote:
From: "Thulasimani,Sivakumar"
DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current c
On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> Hi,
>
>> -Original Message-
>> From: Yang, Libin
>> Sent: Tuesday, August 11, 2015 10:41 AM
>> To: Jani Nikula; alsa-de...@alsa-project.org; ti...@suse.de; intel-
>> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
>> Subject: RE: [Intel-gfx] [
hi Ville,
can you review these patches ?
regards,
Sivakumar
On Friday 31 July 2015 11:32 AM, Sivakumar Thulasimani wrote:
From: "Thulasimani,Sivakumar"
This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä
Date: Thu Mar 12 17:10:38 2015 +0200
CHV does not s
On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> Hi Jani,
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Tuesday, August 11, 2015 4:14 PM
>> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
>> g...@lists.freedesktop.org; daniel.vet.
84 matches
Mail list logo
