On Thu, Apr 23, 2015 at 05:31:01PM -0700, Marc MERLIN wrote:
> Hi Chris, thanks for the answer,
>
> On Thu, Apr 23, 2015 at 11:49:24PM +0100, Chris Wilson wrote:
> > On Thu, Apr 23, 2015 at 03:22:44PM -0700, Marc MERLIN wrote:
> > > I do boot my kernel with these options I found recommended to sav
Since
commit 43566dedde54f9729113f5f9fde77d53e75e61e9
Author: Chris Wilson
Date: Fri Jan 2 16:29:29 2015 +0530
drm/i915: Broaden application of set-domain(GTT)
we allowed objects to be in the GTT domain, but unbound. Therefore
removing the GTT cache domain when removing the GGTT vma is no
I picked up this work due to the following Jira ticket created by the
security team (on Android) and was asked to give it a second look and
found a few more issues with the hw lock code.
https://jira01.devtools.intel.com/browse/GMINL-5388
I/O control on /dev/dri/card0 crashes the kernel (0x4008642
Hi Chris, thanks for the answer,
On Thu, Apr 23, 2015 at 11:49:24PM +0100, Chris Wilson wrote:
> On Thu, Apr 23, 2015 at 03:22:44PM -0700, Marc MERLIN wrote:
> > I do boot my kernel with these options I found recommended to save
> > power, maybe I should remove some of them because they kill perfo
On Thu, Apr 23, 2015 at 5:30 PM, Bjorn Helgaas wrote:
> [+cc Matthew]
>
> On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
>> Hmm. The odd Intel PCI resource mess is back.
>>
>> Or maybe it never went away.
>>
>> I get these when suspending. Things *work*, but it's really spamming
>
ok, let's keep it the the original way.
On Fri, Apr 24, 2015 at 12:09 AM, Daniel Vetter wrote:
> On Wed, Apr 22, 2015 at 10:50:55AM +0800, John Hunter wrote:
> > Sure, but I need Daniel to admit that, because maybe include the two
> header
> > file make it easier to understand.
> > And after che
On Thu, Apr 23, 2015 at 03:22:44PM -0700, Marc MERLIN wrote:
> I do boot my kernel with these options I found recommended to save
> power, maybe I should remove some of them because they kill performance?
> pcie_aspm=force i915.i915_enable_rc6=7 i915.i915_enable_fbc=1
> i915.semaphores=1 i915.lvds
On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett
wrote:
> On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
>>
>> int pcibios_add_device(struct pci_dev *dev)
>> {
>> if (dev-is-default-vga-device) {
>> dev->rom = 0xC;
>> dev->romlen = 0x2;
>> }
>
> I don't know
Hi,
My performance for normal work (2D, although many things like chrome use
the GPU nowadays), and video (mplayer) is between just usable to
horrible.
Performance is bad enough that I'm about to replace the mainboard to get
one with the Nvidia GeForce GT 730M 1GB. I have no idea how good or bad
n
On Thu, Apr 23, 2015 at 08:56:40PM +0200, Daniel Vetter wrote:
> Yeah, but I didn't really see the point in the debug infrastructure for
> aliasing ppgtt. The pde loading is done somewhere completely else than for
> full ppgtt. And if we forget to load the pdes the effects are obvious,
> whereas fa
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6223
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6225
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6227
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1
[+cc Matthew]
On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
> i915 :00:02.0: BAR 6: [??? 0x00
On Thu, 16 Apr 2015, Daniel Vetter wrote:
> On Thu, Apr 16, 2015 at 09:45:01AM +0300, Imre Deak wrote:
>> On ke, 2015-04-15 at 16:52 -0700, Rodrigo Vivi wrote:
>> > From: Imre Deak
>> >
>> > Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across
>> > suspend/resume, so fix thi
On Wed, 15 Apr 2015, Chris Wilson wrote:
> On Wed, Apr 15, 2015 at 06:11:33PM +0100, Michel Thierry wrote:
>> WaIdleLiteRestore is an execlists-only workaround, and requires the driver
>> to ensure that any context always has HEAD!=TAIL when attempting lite
>> restore.
>>
>> Add two extra MI_NOOP
On Thu, 23 Apr 2015, Daniel Vetter wrote:
> On Tue, Apr 21, 2015 at 10:12:19AM -0700, Linus Torvalds wrote:
>> On Tue, Apr 21, 2015 at 9:49 AM, Dmitry Torokhov
>> wrote:
>> > The hardware, according to the specs, is limited to 256 byte transfers,
>> > and current driver has no protections in case
On Wed, Apr 15, 2015 at 03:14:38PM -0700, Chandra Konduru wrote:
> This patch enables skylake primary plane scaling using shared
> scalers atomic desgin.
>
> v2:
> -use single copy of scaler limits (Matt)
>
> v3:
> -move detach_scalers to crtc commit path (Matt)
> -use values in plane_state->src
On Thu, Apr 23, 2015 at 09:15:41PM +0200, Daniel Vetter wrote:
> On Tue, Apr 21, 2015 at 01:18:57PM +0100, Tvrtko Ursulin wrote:
> > Interesting, well, I had a look around and this means all sorts of "trouble"
> > (refactoring) if proper wm param comparison is to be done.
> >
> > Alternatively, in
Hi all,
New -testing cycle with cool stuff:
- dither support for ns2501 dvo (Thomas Richter)
- some polish for the gtt code and fixes to finally enable the cmd parser on hsw
- first pile of bxt stage 1 enabling (too many different people to list ...)
- more psr fixes from Rodrigo
- skl rotation su
On Thu, Apr 23, 2015 at 08:56:40PM +0200, Daniel Vetter wrote:
> Yeah, but I didn't really see the point in the debug infrastructure for
> aliasing ppgtt. The pde loading is done somewhere completely else than for
> full ppgtt. And if we forget to load the pdes the effects are obvious,
> whereas fa
On Thu, Apr 23, 2015 at 10:17:34AM +0200, Thomas Richter wrote:
> Hi Daniel, hi Ville,
>
> third attempt (-: This is a patch that enables dithering on the Fujitsu
> S6010 installed NS2501 DVO. It also pulls out a couple of registers into
> a separate structure, at least those registers of which I
On Tue, Apr 21, 2015 at 01:18:57PM +0100, Tvrtko Ursulin wrote:
> On 04/21/2015 11:07 AM, Chris Wilson wrote:
> >On Tue, Apr 21, 2015 at 11:01:03AM +0100, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 04/21/2015 10:51 AM, Chris Wilson wrote:
> >>>On Tue, Apr 21, 2015 at 10:29:52AM +0100, Tvrtko Ur
On Tue, Apr 21, 2015 at 10:05:46AM +0100, Tvrtko Ursulin wrote:
>
> On 04/21/2015 05:55 AM, Jindal, Sonika wrote:
> >On 4/20/2015 11:14 PM, Daniel Vetter wrote:
> >>On Mon, Apr 20, 2015 at 05:38:20PM +0100, Tvrtko Ursulin wrote:
> >>>
> >>>On 04/20/2015 05:22 PM, Daniel Vetter wrote:
> On Mon,
On Tue, Apr 21, 2015 at 04:36:55PM +0300, Mika Kuoppala wrote:
> Daniel Vetter writes:
>
> > We have this neat abstraction between ppgtt and ggtt for (un)bind_vma
> > and didn't end up using it really. What a shame, so fix this and make
> > the ->bind_vma hook a bit more useful.
> >
> > Signed-of
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6256
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
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 Tue, Apr 14, 2015 at 07:11:25PM +0200, Daniel Vetter wrote:
>
On 17/04/15 22:21, yu@intel.com wrote:
> From: Alex Dai
>
> Add GuC firmware loader. It uses the unified firmware loader to
> fetch firmware blob first, then load to hw in driver main thread.
>
> Issue: VIZ-4884
> Signed-off-by: Alex Dai
> ---
> drivers/gpu/drm/i915/Makefile |
On 17/04/15 22:21, yu@intel.com wrote:
> From: Dave Gordon
>
> Factor out the common code of loading firmware into a new file,
> leaving only the uC-specific parts in the GuC loaders.
>
> Issue: VIZ-4884
> Signed-off-by: Alex Dai
> Signed-off-by: Dave Gordon
> ---
> drivers/gpu/drm/i915/M
The bug entry is at
https://code.google.com/p/chromium/issues/detail?id=476001
The patch below makes clang happy.
debugger/eudb.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/debugger/eudb.c b/debugger/eudb.c
index 0e810db..7188a4f 100644
--- a/debugger/eudb.c
+++ b/d
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6255
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Tue, Apr 21, 2015 at 10:12:19AM -0700, Linus Torvalds wrote:
> On Tue, Apr 21, 2015 at 9:49 AM, Dmitry Torokhov
> wrote:
> > The hardware, according to the specs, is limited to 256 byte transfers,
> > and current driver has no protections in case users attempt to do larger
> > transfers. The co
On Wed, Apr 22, 2015 at 10:50:55AM +0800, John Hunter wrote:
> Sure, but I need Daniel to admit that, because maybe include the two header
> file make it easier to understand.
> And after checked other files in drm/i915, I found that a lot other file do
> the
> same thing(include both header file).
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 Tue, Apr 14, 2015 at 07:11:25PM +0200, Daniel Vetter wrote:
> >> > On Tue, Apr 14, 2015 at 05:06:36PM +0100, Chris Wilson wrote:
> >>
From: Daniele Ceraolo Spurio
Using imported objects should not leak i915 vmas (and vms).
In practice this simulates Xorg importing fbcon and leaking (or not) one vma
per Xorg startup cycle.
v2: use low-level ioctl wrappers and bo offset to check the leak (Chris)
v3: use the flinked bo as batch
On Thu, Apr 23, 2015 at 02:34:24PM +, Antoine, Peter wrote:
> Before the patch the system required rebooting (driver crash and/or kernel
> panic).
> Now the application gets terminated.
It should have an GPF which should not have required a reboot, but
terminated the application. Unless you s
Before the patch the system required rebooting (driver crash and/or kernel
panic).
Now the application gets terminated.
This follows the pattern in the other parts of this code that checks that
pointer.
Peter.
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sen
On Thu, Apr 23, 2015 at 03:07:55PM +0100, Peter Antoine wrote:
> This patch fixes an unsafe deference in the DRM_IOCTL_NEW_CTX. If the
> ioctl is called before the lock is created or after it has been destroyed.
> The code will deference a NULL pointer. This ioctl is a root ioctl so
> exploitation
On Thu, Apr 23, 2015 at 03:07:54PM +0100, Peter Antoine wrote:
> This patch fixes a possible kernel crash when drm_unlock (DRM_IOCTL_UNLOCK)
> is called by a application that has not had a lock created by it. This
> crash can be caused by any application from all users.
Crashing the application is
This patch fixes a possible kernel crash when drm_unlock (DRM_IOCTL_UNLOCK)
is called by a application that has not had a lock created by it. This
crash can be caused by any application from all users.
Issue: VIZ-5485
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/drm_lock.c | 8
1 fi
This patch fixes an unsafe deference in the DRM_IOCTL_NEW_CTX. If the
ioctl is called before the lock is created or after it has been destroyed.
The code will deference a NULL pointer. This ioctl is a root ioctl so
exploitation is limited.
Issue: VIZ-5485
Signed-off-by: Peter Antoine
---
drivers
As these functions are only used by one driver and there are security holes
in these functions. Make the functions optional.
These changes are based on the two patches:
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie
And the commit that the above patch reverts:
commit 7
If an application that has a driver lock created, wants the lock the
kernel context, it is not allowed to. If the call to drm_lock has a
context of 0, it is rejected. If you set the context to _DRM_LOCK_CONT
then call drm lock, it will pass the context == DRM_KERNEL_CONTEXT checks.
But as the DRM_L
As these functions are only used by one driver and there are security holes
in these functions. Make the functions optional.
Issue: VIZ-5485
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/drm_lock.c| 6 ++
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/nouveau
The following series of patches fix a number of security holes in the i915
driver (actually in drm but...). The first three patches remove the actual
security issues that have been found. The last two patches make the functions
optional for all drivers. The only driver that has this feature turned
There are several issues with the hardware locks functions that stretch
from kernel crashes to priority escalations. This new test will test the
the fixes for these features.
This test will cause a driver/kernel crash on un-patched kernels, the
following patches should be applied to stop the crash
we still don't have code to enumerate DDI E or DDI D. but this will
handle them when this bit is missed by GOP/VBIOS during boot up.
Reviewed-by: Sivakumar Thulasimani
On 4/23/2015 5:58 PM, Sonika Jindal wrote:
Currently, if bios fails to drive an edp panel due to any reason,
the ddi buffer
On Wed, Apr 22, 2015 at 12:45 PM, Mika Kuoppala
wrote:
> The current aliasing ppgtt implementation allocates
> the page table structures on driver initialization
> for the entire vm address space. Earlier the page tables
> were allocated as array of struct pages, but introduction
> of dynamic allo
On Thu, Apr 23, 2015 at 02:01:43PM +0100, Ceraolo Spurio, Daniele wrote:
> On 4/23/2015 12:36 PM, Chris Wilson wrote:
> >>+ memset(&execbuf, 0, sizeof(execbuf));
> >>+ execbuf.buffers_ptr = (uintptr_t)exec;
> >>+ execbuf.buffer_count = 1;
> >>+ execbuf.batch_len = sizeof(batch_data);
> >>+
On 4/23/2015 12:36 PM, Chris Wilson wrote:
On Thu, Apr 23, 2015 at 12:23:17PM +0100, daniele.ceraolospu...@intel.com wrote:
From: Tvrtko Ursulin
Using imported objects should not leak i915 vmas (and vms).
In practice this simulates Xorg importing fbcon and leaking (or not) one vma
per Xorg st
Currently, if bios fails to drive an edp panel due to any reason,
the ddi buffer will not be enabled. And the DDIA lane capability
will remain 0. This leads to assumption of DDIA x2 which means DDIA
supports 2 lanes and DDIE supports 2 lanes. For some higher resolution
panel which needs 4 lanes, we
On 17/04/15 22:21, yu@intel.com wrote:
> From: Dave Gordon
>
> In order to fully initialise the default contexts, we have to execute
> batchbuffer commands on the GPU engines. But we can't do that until any
> required firmware has been loaded, which may not be possible during
> driver load, b
Since
commit 43566dedde54f9729113f5f9fde77d53e75e61e9
Author: Chris Wilson
Date: Fri Jan 2 16:29:29 2015 +0530
drm/i915: Broaden application of set-domain(GTT)
we allowed objects to be in the GTT domain, but unbound. Therefore
removing the GTT cache domain when removing the GGTT vma is no
On 04/23/2015 12:23 PM, daniele.ceraolospu...@intel.com wrote:
From: Tvrtko Ursulin
I have least to do with the current version so best upgrade yourself as
author now!
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
On Thu, Apr 23, 2015 at 12:23:17PM +0100, daniele.ceraolospu...@intel.com wrote:
> From: Tvrtko Ursulin
>
> Using imported objects should not leak i915 vmas (and vms).
>
> In practice this simulates Xorg importing fbcon and leaking (or not) one vma
> per Xorg startup cycle.
>
> v2: use low-leve
On 04/23/2015 11:39 AM, Chris Wilson wrote:
On Thu, Apr 23, 2015 at 11:08:35AM +0100, Tvrtko Ursulin wrote:
+/*
+ * Test that tiled page flips work.
Worth saying that we don't always expect linear->tiled flips to work, so
the mo is to first set the CRTC with a tiled fb, then flip to the
secon
From: Tvrtko Ursulin
Using imported objects should not leak i915 vmas (and vms).
In practice this simulates Xorg importing fbcon and leaking (or not) one vma
per Xorg startup cycle.
v2: use low-level ioctl wrappers and bo offset to check the leak (Chris)
v3: use the flinked bo as batch (Chris)
Michel Thierry writes:
> Aliasing ppgtt is fully allocated right after creation, thus shouldn't
> need to call allocate_va_range in i915_vma_bind.
>
> This duplication started after commit 5c5f645773b6d147bf68c350674dc3ef4f8de83d
> ("drm/i915: drm/i915: Unify aliasing ppgtt handling"), as aliasin
On Thu, Apr 23, 2015 at 11:08:35AM +0100, Tvrtko Ursulin wrote:
> +/*
> + * Test that tiled page flips work.
Worth saying that we don't always expect linear->tiled flips to work, so
the mo is to first set the CRTC with a tiled fb, then flip to the
second.
> + */
> +static void
> +test_tiled_flip(
On Thu, Apr 23, 2015 at 11:19:50AM +0100, Chris Wilson wrote:
> I probably have the scaling inverted. What should also work, but we may
> have to beat the kernel up to fix a few bugs...
>
> xrandr --addmode eDP1 3840x2160 \
> --output eDP1 --primary --mode 3840x2160 --crtc 0 \
> --outp
On Thu, Apr 23, 2015 at 11:14:12AM +0100, Ceraolo Spurio, Daniele wrote:
> On 4/23/2015 10:43 AM, Chris Wilson wrote:
> >On Thu, Apr 23, 2015 at 10:30:01AM +0100, daniele.ceraolospu...@intel.com
> >wrote:
> >>From: Daniele Ceraolo Spurio
> >>
> >>From: Tvrtko Ursulin
> >>
> >>Using imported obje
On Thu, Apr 23, 2015 at 12:03:24PM +0200, Lukas Hejtmanek wrote:
> On Thu, Apr 23, 2015 at 10:22:31AM +0100, Chris Wilson wrote:
> > $ xrandr --output eDP1 --off --output DP1-8 --off --output DP1-9 --off ; \
> > xrandr \
> > --output eDP1 --primary --preferred --crtc 0 \
> > --output DP1-
On 4/23/2015 10:43 AM, Chris Wilson wrote:
On Thu, Apr 23, 2015 at 10:30:01AM +0100, daniele.ceraolospu...@intel.com wrote:
From: Daniele Ceraolo Spurio
From: Tvrtko Ursulin
Using imported objects should not leak i915 vmas (and vms).
In practice this simulates Xorg importing fbcon and leaki
From: Tvrtko Ursulin
Or in other words tests that display programming remains
correct when page flipping between tiled frame buffers.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Daniel Vetter
---
tests/kms_flip_tiling.c | 107 ++--
1 file ch
On Thu, Apr 23, 2015 at 10:22:31AM +0100, Chris Wilson wrote:
> $ xrandr --output eDP1 --off --output DP1-8 --off --output DP1-9 --off ; \
> xrandr \
> --output eDP1 --primary --preferred --crtc 0 \
> --output DP1-8 --preferred --right-of eDP1 --crtc 1 \
> --output DP1-9 --prefe
On Thu, Apr 23, 2015 at 10:30:01AM +0100, daniele.ceraolospu...@intel.com wrote:
> From: Daniele Ceraolo Spurio
>
> From: Tvrtko Ursulin
>
> Using imported objects should not leak i915 vmas (and vms).
>
> In practice this simulates Xorg importing fbcon and leaking (or not) one vma
> per Xorg s
Thanks Tvrtko.
This series makes kms_rotation_crc much cleaner :)
Reviewed-by: Sonika Jindal
On 4/22/2015 9:16 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Saves a good amount of code duplication by supporting expected
failures from the main loop.
Signed-off-by: Tvrtko Ursulin
Cc: Sonik
From: Daniele Ceraolo Spurio
From: Tvrtko Ursulin
Using imported objects should not leak i915 vmas (and vms).
In practice this simulates Xorg importing fbcon and leaking (or not) one vma
per Xorg startup cycle.
v2: use low-level ioctl wrappers and bo offset to check the leak (Chris)
Signed-o
On Thu, Apr 23, 2015 at 10:39:54AM +0200, Lukas Hejtmanek wrote:
> Chris,
>
> On Wed, Apr 22, 2015 at 03:27:51PM +0100, Chris Wilson wrote:
> > Try
> > $ xrandr \
> > --output eDP1 --primary --preferred \
> > --output DP1-8 --preferred --right-of eDP1 \
> > --output DP1-9 --preferred -
[cc'ing the authors]
On Sat, Apr 11, 2015 at 07:40:34PM -0300, Ismael Luceno wrote:
> A bisect showed that commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68
> introduced the issue.
>
> The issue starts as soon as X takes control of the screen, even if just
> a plain X doing nothing, so based on the
On 04/22/2015 05:45 PM, Chris Wilson wrote:
On Wed, Apr 22, 2015 at 05:23:11PM +0100, Tvrtko Ursulin wrote:
Hi,
On 04/22/2015 05:07 PM, Chris Wilson wrote:
On Wed, Apr 22, 2015 at 05:00:27PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This matches the behaviour in kernel patch
"drm/
Chris,
On Wed, Apr 22, 2015 at 03:27:51PM +0100, Chris Wilson wrote:
> Try
> $ xrandr \
> --output eDP1 --primary --preferred \
> --output DP1-8 --preferred --right-of eDP1 \
> --output DP1-9 --preferred --right-of DP1-8
anubis: ~ $ xrandr \
Continue> --output eDP1 --pri
Hi Daniel, hi Ville,
third attempt (-: This is a patch that enables dithering on the Fujitsu
S6010 installed NS2501 DVO. It also pulls out a couple of registers into
a separate structure, at least those registers of which I believe I know
what they do. Note that the NS2501 DVO is otherwise undocum
73 matches
Mail list logo
