Hey,
Op 29-07-15 om 12:51 schreef Daniel Vetter:
> In
>
> commit 6f75cea66c8dd043ced282016b21a639af176642
> Author: Daniel Vetter
> 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 commits agains
On Fri, 31 Jul 2015, Sivakumar Thulasimani
wrote:
> From: "Thulasimani,Sivakumar"
>
> 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 read into display_info, hence bpp from
> VBT will be us
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
On Thu, Jul 30, 2015 at 10:04:49AM -0400, Mike Frysinger wrote:
> On 30 Jul 2015 15:30, Patrik Jakobsson wrote:
> > On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote:
> > > On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
> > > > Use pkg-config to try to find libdrm. If that fails use the
On Fri, 31 Jul 2015, Paulo Zanoni wrote:
> From: Damien Lespiau
>
> 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 one?
BR,
Jani.
> Author: Damien Lespiau
Reviewed-by: Ander Conselvan de Oliveira
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 happen immediatel
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 t
Reviewed-by: Ander Conselvan de Oliveira
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
> ---
> drivers/gpu/drm/i915/intel_crt.c
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> There are no more users, byebye!
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 37
> +---
> drivers/gpu/drm/i915/intel_d
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
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu
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
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 1600
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:
-
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 o
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:
- r
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:
-
Information on maximum supported DOT clock frequency to
i915_frequency_info.
Signed-off-by: Mika Kahola
---
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
index 23a69307..4ba02b5
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:
-
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 code is already
32/64-bit safe (Chris).
v3: Add goto
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 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:
-
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
Signed-off-by: Michel Thierry
---
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 @@ MODUL
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 Goe
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 skl_co
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 drm_devi
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 Disp
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
> > Date: Wed Nov 19 18:38:07 2014 +0100
> >
> > drm/atomic: Only destroy connec
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 a
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
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space
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 objects
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 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 fi
2015-07-31 6:24 GMT-03:00 Jani Nikula :
> On Fri, 31 Jul 2015, Paulo Zanoni wrote:
>> From: Damien Lespiau
>>
>> 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 patc
2015-07-30 20:37 GMT-03:00 Rodrigo Vivi :
>
>
> On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni wrote:
>>
>> From: Paulo Zanoni
>>
>> Due to the way busy_bits was handled, we were not doing any flushes if
>> we didn't previously get an invalidate. Since it's possible to get
>> flushes without an in
A programming restriction exists for this instruction, atleast one component
of one valid vertex element must be enabled.
Cc: Ben Widawsky
Cc: Chris Wilson
Signed-off-by: Arun Siluvery
---
tools/null_state_gen/intel_renderstate_gen9.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Atleast one component of one valid vertex element must be enabled.
Cc: Ben Widawsky
Cc: Chris Wilson
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_renderstate_gen9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen9.c
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 writes:
> > >
> > > > On Tue, Apr 14, 2015 at 06:53:41PM +0100, Chris Wilson wrote:
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 r
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 won
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:
Li
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
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: s/full_64b/full_48b/. (Akash
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 code
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
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
---
intel/intel_aub.h| 153
On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter 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 reproduce the mst p
---
lib/igt_kms.c | 13 +++--
lib/igt_kms.h | 2 +-
tests/kms_flip.c | 2 +-
tests/kms_pipe_crc_basic.c | 2 +-
4 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7e956b4..c067443 100644
--- a/lib/igt_k
---
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 |
---
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"
---
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*() 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
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
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 ioct
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
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 - s
On Fri, Jul 31, 2015 at 9:07 PM, Linus Torvalds
wrote:
> On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter 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 tw
61 matches
Mail list logo
