On Fri, Jul 31, 2015 at 9:07 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
I delayed my -fixes pull a bit hoping that I could include a fix for the
dp mst stuff but looks a bit more nasty than that. So just
On 7/22/2015 8:09 PM, Chris Wilson wrote:
On Wed, Jul 22, 2015 at 07:21:49PM +0530, ankitprasad.r.sha...@intel.com wrote:
static int
i915_gem_shmem_pread(struct drm_device *dev,
struct drm_i915_gem_object *obj,
@@ -754,17 +850,20 @@ i915_gem_pread_ioctl(struct
On Fri, Jul 31, 2015 at 10:34:43AM +0200, Maarten Lankhorst wrote:
Hey,
Op 29-07-15 om 12:51 schreef Daniel Vetter:
In
commit 6f75cea66c8dd043ced282016b21a639af176642
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Nov 19 18:38:07 2014 +0100
drm/atomic: Only destroy
On 7/27/2015 3:08 PM, Daniel Vetter wrote:
On Wed, Jul 22, 2015 at 07:21:48PM +0530, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson chris at chris-wilson.co.uk
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Update the sanitize_enable_ppgtt for 48 bit PPGTT mode.
Note, aliasing PPGTT remains 32b only.
v2: s/full_64b/full_48b/. (Akash)
v3: Add sanitize_enable_ppgtt changes until here. (Akash)
v4: Update param description (Chris)
Cc: Akash
When reading out hw state for planes we disable inactive planes which in
turn triggers an update of the watermarks. The update depends on the
crtc_clock being set which is done when reading out encoders. Thus
postpone the plane readout until after encoder readout.
This prevents a warning in
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 the max dot clock frequency to 90% of the max CD clock
frequency for the
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 support the requested pixel clock.
This patch applies to TV.
V2:
-
Hello, I have a Thinkpad X230 (IvyBridge, HD4000) with a very clever
display mod (described to some extent by a guy here --
http://boweihe.me/?p=1442). Practically the low res native LVDS panel
of the laptop was replaced with a FHD IPS eDP panel. The FHD eDP screen
is attached to the dock
On 22.07.2015 10:27, Daniel Vetter wrote:
On Tue, Jul 21, 2015 at 08:07:47PM +0200, Krzysztof Kolasa wrote:
On 21.07.2015 16:03, Daniel Vetter wrote:
On Tue, Jul 21, 2015 at 02:48:21PM +0200, Krzysztof Kolasa wrote:
On 21.07.2015 11:43, Chris Wilson wrote:
On Tue, Jul 21, 2015 at 11:07:20AM
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 support the requested pixel clock.
This patch applies to
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 support the requested pixel clock.
This patch applies to SDVO.
V2:
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 support the requested pixel clock.
This patch applies to DVO.
V2:
-
From EDID we can read and request higher pixel clock than
our HW can support. This set of patches add checks if
requested pixel clock is lower than the one supported by the HW.
The requested mode is discarded if we cannot support the requested
pixel clock. For example for Cherryview
'cvt 2560
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 support the requested pixel clock.
This patch applies to HDMI.
V2:
Information on maximum supported DOT clock frequency to
i915_frequency_info.
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
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 support the requested pixel clock.
This patch applies to LVDS.
V2:
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Update the sanitize_enable_ppgtt for 48 bit PPGTT mode.
Note, aliasing PPGTT remains 32b only.
v2: s/full_64b/full_48b/. (Akash)
v3: Add sanitize_enable_ppgtt changes until here. (Akash)
Cc: Akash Goel akash.g...@intel.com
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 support the requested pixel clock.
This patch applies to DSI.
V2:
-
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 support the requested pixel clock.
This patch applies to DisplayPort
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 support the requested pixel clock.
This patch applies to CRT.
V2:
-
On Fri, Jul 31, 2015 at 08:12:30PM +0530, Goel, Akash wrote:
On 7/29/2015 5:34 PM, Chris Wilson wrote:
On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:
Chris and I just discussed on irc that the bound_list isn't in a great LRU
order right now and Chris sent out a fix for
2015-07-31 6:24 GMT-03:00 Jani Nikula jani.nik...@linux.intel.com:
On Fri, 31 Jul 2015, Paulo Zanoni paulo.r.zan...@intel.com wrote:
From: Damien Lespiau damien.lesp...@intel.com
Similar to the -enable vfunc in commit:
commit 865720564389b2b19cf58e41ed31701e5f464b9d
That sha won't be the
On Thu, Apr 23, 2015 at 08:56:40PM +0200, Daniel Vetter wrote:
On Thu, Apr 23, 2015 at 04:43:52PM +0100, Chris Wilson wrote:
On Fri, Apr 17, 2015 at 04:49:18PM +0300, Mika Kuoppala wrote:
Daniel Vetter dan...@ffwll.ch writes:
On Tue, Apr 14, 2015 at 06:53:41PM +0100, Chris Wilson
On 7/31/2015 8:36 PM, Chris Wilson wrote:
On Fri, Jul 31, 2015 at 08:12:30PM +0530, Goel, Akash wrote:
On 7/29/2015 5:34 PM, Chris Wilson wrote:
On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:
Chris and I just discussed on irc that the bound_list isn't in a great LRU
order
Why are so many IGT tests blacklisted? How does a test get put on the
blacklist? We've been running the full (almost) IGT suite on Chrome OS. Our
blacklist has around 46 tests, mainly for tests that timeout, hang the system
and don't reboot, or cause a reboot in the middle of the test. I'm
2015-07-30 20:37 GMT-03:00 Rodrigo Vivi rodrigo.v...@gmail.com:
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Due to the way busy_bits was handled, we were not doing any flushes if
we didn't previously get an invalidate.
A programming restriction exists for this instruction, atleast one component
of one valid vertex element must be enabled.
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
Hi Linus,
I delayed my -fixes pull a bit hoping that I could include a fix for the
dp mst stuff but looks a bit more nasty than that. So just 3 other
regression fixes, one 4.2 other two cc: stable.
Cheers, Daniel
The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f:
On Fri, Jul 31, 2015 at 04:11:21PM +0200, Krzysztof Kolasa wrote:
On 22.07.2015 10:27, Daniel Vetter wrote:
On Tue, Jul 21, 2015 at 08:07:47PM +0200, Krzysztof Kolasa wrote:
On 21.07.2015 16:03, Daniel Vetter wrote:
On Tue, Jul 21, 2015 at 02:48:21PM +0200, Krzysztof Kolasa wrote:
On
Atleast one component of one valid vertex element must be enabled.
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/intel_renderstate_gen9.c | 2 +-
1 file changed, 1
On Fri, Jul 31, 2015 at 01:13:00PM +0100, Michel Thierry wrote:
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 5ae4b0a..900e48a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -111,7 +111,7 @@
On 7/29/2015 5:34 PM, Chris Wilson wrote:
On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:
Chris and I just discussed on irc that the bound_list isn't in a great LRU
order right now and Chris sent out a fix for that. But it only works if we
preferrentially shrink inactive
On Fri, Jul 31, 2015 at 05:26:24PM +0100, Chris Wilson wrote:
This performance regression is still unfixed.
Hah. Just found out that adding the git id to the version also changes
the kernel name - so everytime I was booting the wrong kernel and the
bisect ended up at the wrong patch.
So whilst
From: Kristian Høgsberg Kristensen kristian.h.kristen...@intel.com
We now have a separate tool for this in intel-gpu-tools and we don't
need to clutter up libdrm with this feature. We leave the entry points
in there to avoid breaking API/ABI.
Signed-off-by: Kristian Høgsberg Kristensen
Reviewed the patch it looks fine.
Reviewed-by: Akash Goel akash.g...@intel.com
On 7/31/2015 6:05 PM, Michel Thierry wrote:
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Update the sanitize_enable_ppgtt for 48 bit PPGTT mode.
Note, aliasing PPGTT remains 32b only.
v2:
On 7/31/2015 5:42 PM, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt
Hi,
I've tested these two patches (in drm-intel-nightly, but also in CrOS kernel
v3.14) and they seem just enough for what we want to do: 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
---
benchmarks/gem_userptr_benchmark.c | 2 +-
benchmarks/intel_upload_blit_large.c | 2 +-
benchmarks/intel_upload_blit_large_gtt.c | 2 +-
benchmarks/intel_upload_blit_large_map.c | 2 +-
benchmarks/intel_upload_blit_small.c | 2 +-
debugger/eudb.c |
Changes since last version of patch:
Addressed comments from danvet:
- added drm_open_driver(driver_flag)
- replaced existing drm_open_any's with cocci (separate commit)
- updated drm_read (and some associated plumbing) to run with OPEN_ANY_GPU
The updated version of drm_read works on exynos5
---
lib/drmtest.c | 108 ++
lib/drmtest.h | 18 +++---
2 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index ee5c123..4e3ddd6 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -75,23 +75,43
---
lib/drmtest.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/lib/drmtest.h b/lib/drmtest.h
index 740aac1..7a41ae5 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -41,13 +41,6 @@
#define OPEN_ANY_GPU 0x1
#define DRIVER_INTEL 0x1 1
-// provide the deprecated drm_open_any*()
---
tests/drm_read.c | 101 ++-
1 file changed, 55 insertions(+), 46 deletions(-)
diff --git a/tests/drm_read.c b/tests/drm_read.c
index fdaf126..f60e21c 100644
--- a/tests/drm_read.c
+++ b/tests/drm_read.c
@@ -45,10 +45,15 @@
#include drm.h
From: Daniel Thompson daniel.thomp...@linaro.org
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
For now we're opting out devices that don't have the LLC CPU cache (mostly
Atom devices). Alternatively, we could build up a path to mmap them through
GTT WC (and ignore the fact that will be dead-slow for reading). Or, an even
more complex work I believe, would involve on setting up dma-buf
On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
I delayed my -fixes pull a bit hoping that I could include a fix for the
dp mst stuff but looks a bit more nasty than that. So just 3 other
regression fixes, one 4.2 other two cc: stable.
Quick question: you can now
On Fri, Jul 31, 2015 at 05:42:23PM -0300, Tiago Vignatti wrote:
For now we're opting out devices that don't have the LLC CPU cache (mostly
Atom devices). Alternatively, we could build up a path to mmap them through
GTT WC (and ignore the fact that will be dead-slow for reading). Or, an even
Describing arguments at top of a struct definition works fine
for small/medium size structs, but it definitely doesn't work well
for struct with a huge list of elements.
Keeping the arguments list inside the struct body makes it easier
to maintain the documentation.
ie:
/**
* struct my_struct -
Hi all,
New -testing cycle with cool stuff:
- kerneldoc for tiling/swizzling/fencing code
- bxt hpd port A w/a
- various other fixes all over
... not much, everyone's on vacation.
Happy testing!
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hey,
Op 29-07-15 om 12:51 schreef Daniel Vetter:
In
commit 6f75cea66c8dd043ced282016b21a639af176642
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Nov 19 18:38:07 2014 +0100
drm/atomic: Only destroy connector states with connection mutex held
I tried to fix races of atomic
On Fri, 31 Jul 2015, Paulo Zanoni paulo.r.zan...@intel.com wrote:
From: Damien Lespiau damien.lesp...@intel.com
Similar to the -enable vfunc in commit:
commit 865720564389b2b19cf58e41ed31701e5f464b9d
That sha won't be the same once it gets applied. Maybe just squash these
two patches into
On Thu, 2015-07-30 at 14:57 +0200, Maarten Lankhorst wrote:
Right now dpms callbacks can still fiddle with the connector state,
but it can only turn connectors off.
This is remediated by only checking crtc-state-active when the
connector is active, and ignore crtc-state-active when the
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
This is now done completely atomically.
Keep connectors_active for now, but make it mirror crtc_state-active.
Signed-off-by: Maarten Lankhorst
On Fri, 31 Jul 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com
wrote:
From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
On Thu, 2015-07-30 at 14:57 +0200, Maarten Lankhorst wrote:
First step in removing dpms and validating atomic state.
There can still be a mismatch in the connector state because the dpms
callbacks are still used, but this can not
On Thu, Jul 30, 2015 at 06:20:25PM -0300, Paulo Zanoni wrote:
Hello
So I discovered that SKL runtime PM doesn't work on drm-intel-nightly and
decided to investigate why. I found this patch in one of Damien's trees and it
fixed the problem I was seeing. I really don't know why the patches
Older VBT (e.g. gen2) have smaller child block defintions, so do not cry
wolf over an error that is outside of our control and is not an error
anyway.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
57 matches
Mail list logo
