Hi Dave, i915 fixes headed for v4.1-rc1.
BR,
Jani.
The following changes since commit 37ef01ab5d24d1d520dc79f6a98099d451c2a901:
drm/i915: Dont enable CS_PARSER_ERROR interrupts at all (2015-04-14 17:03:12
+0300)
are available in the git repository at:
git://anongit.freedesktop.org/drm-in
On Fri, Apr 24, 2015 at 04:27:58PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Measures DRM_IOCTL_MODE_SETCRTC and DRM_IOCTL_MODE_SETPLANE as proxy for
> drm_atomic_helper_update_plane if I got it right.
>
> Discovered some slow cursor updates (1.6ms) so needed something to test
> di
> -Original Message-
> From: Konduru, Chandra
> Sent: Friday, April 24, 2015 10:53 AM
> To: 'Tvrtko Ursulin'; Intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko
> Subject: RE: [PATCH] drm/i915/skl: Bypass debug message if scalers are not
> requested
>
>
>
> > -Original Message--
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Friday, April 24, 2015 9:34 AM
> To: Konduru, Chandra; Intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko
> Subject: Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are not
> requested
On Fri, 24 Apr 2015, Jim Davis wrote:
> Building with the attached random configuration file,
>
> warning: (SND_SOC_INTEL_BYTCR_RT5640_MACH &&
> SND_SOC_INTEL_CHT_BSW_RT5672_MACH &&
> SND_SOC_INTEL_CHT_BSW_RT5645_MACH) selects SND_SST_IPC_ACPI which has
> unmet direct dependencies (SOUND && !M68K
On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
> Your i915 does not have a ROM BAR in hardware. If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_RO
On Thu, Apr 23, 2015 at 3:47 PM, Linus Torvalds
wrote:
> I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
> yes, if what this is all about is the magic video ROM at 0xc, then
It's used in the PCI layer to say "Read from 0xc rather than the
ROM BAR" and then ends up a
On 24 April 2015 at 14:43, wrote:
> From: Tim Gore
>
> The call to low_mem_killer_disable(true) was being done
> from within function oom_adjust_for_doom. However,
> oom_adjust_for_doom gets called from 3 places. We only
> want the call to low_mem_killer_disable(true) to happen
> during common_i
Building with the attached random configuration file,
warning: (SND_SOC_INTEL_BYTCR_RT5640_MACH &&
SND_SOC_INTEL_CHT_BSW_RT5672_MACH &&
SND_SOC_INTEL_CHT_BSW_RT5645_MACH) selects SND_SST_IPC_ACPI which has
unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC &&
ACPI)
drivers/built-
On 04/24/2015 05:30 PM, Konduru, Chandra wrote:
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Friday, April 24, 2015 9:08 AM
To: Intel-gfx@lists.freedesktop.org
Cc: Ursulin, Tvrtko; Konduru, Chandra
Subject: [PATCH] drm/i915/skl: Bypass debug me
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Friday, April 24, 2015 9:08 AM
> To: Intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko; Konduru, Chandra
> Subject: [PATCH] drm/i915/skl: Bypass debug message if scalers are not
> requested
>
On Fri, Apr 24, 2015 at 04:53:53PM +0100, Chris Wilson wrote:
> Whether of not it tears depends upon your window manager. On bare X,
> using mplayer -vo xv or -vo gl, should not tear. Under a compositing
> window manager, it depends upon how it decides to update the screen. To
> force everything to
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
Cc: Chandra Konduru
---
Up for discussion I suppose, but like it is, with typical drm.debug = 0xe,
it logs one line per cursor movement while the log would otherwise be quiet.
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +++
1 file changed, 3
On Fri, Apr 24, 2015 at 08:35:33AM -0700, Marc MERLIN wrote:
> On Fri, Apr 24, 2015 at 07:53:29AM +0100, Chris Wilson wrote:
> > > On top of being bleeding edge enoug not to be in debian unstable, does it
> > > have
> > > performance enhancements that you are hopeful will help my situation?
> >
In case some drivers are unloading, they can remove lookup tables which
they would have registered during their load time to avoid redundant
entries if loaded again
v2: Ccing maintainers
CC: Samuel Ortiz
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Thierry Reding
Signed-off-by: Shobhit Kumar
On Fri, Apr 24, 2015 at 07:53:29AM +0100, Chris Wilson wrote:
> > On top of being bleeding edge enoug not to be in debian unstable, does it
> > have
> > performance enhancements that you are hopeful will help my situation?
>
> Lots.
:)
Ok, so I owe you thanks.
Between the module options and t
In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload
v2: Ccing maintainers
Cc: Samuel Ortiz
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Thierry Reding
On 04/24/2015 04:27 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Measures DRM_IOCTL_MODE_SETCRTC and DRM_IOCTL_MODE_SETPLANE as proxy for
drm_atomic_helper_update_plane if I got it right.
Discovered some slow cursor updates (1.6ms) so needed something to test
different kernel configs etc.
The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.
v2: Use the newer gpiod interface(Alexandre)
v3: Remove the redundant checks and unused code
On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
entry for the same to be used by the consumer (Intel GFX)
v2: Remove the lookup table on driver unload (Thierry)
CC: Samuel Ortiz
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Thierry Reding
Signed-off-by: Shobhit Kumar
--
Needed for PWM control suuported by the PMIC
CC: Samuel Ortiz
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Thierry Reding
Signed-off-by: Shobhit Kumar
---
drivers/mfd/intel_soc_pmic_crc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/int
The Crystalcove PMIC controls PWM signals and this driver exports that
capability as a PWM chip driver. This is platform device implementtaion
of the drivers/mfd cell device for CRC PMIC
v2: Use the existing config callback with duty_ns and period_ns(Thierry)
CC: Samuel Ortiz
Cc: Linus Walleij
On some Intel SoC platforms, the panel enable/disable signals are
controlled by CRC PMIC. Add those control as a new GPIO in a lookup
table for gpio-crystalcove chip during CRC driver load
v2: Make the lookup table static (Thierry)
Remove the lookup table during driver remove (Thierry)
CC: Sa
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
CC: Samuel Ortiz
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Thierry Reding
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_drv.h | 5 +++
drivers/gpu/
In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload
Signed-off-by: Shobhit Kumar
---
drivers/gpio/gpiolib.c | 13 +
include/linux/gpio
In case some drivers are unloading, they can remove lookup tables which
they would have registered during their load time to avoid redundant
entries if loaded again
Signed-off-by: Shobhit Kumar
---
drivers/pwm/core.c | 17 +
include/linux/pwm.h | 5 +
2 files changed, 22 in
Hi All,
Finally I came back to this and tried to address the pending review comments.
Couple of the patches from the older series were merged in linux-next. This
series reworks on the remaining and rebases on linux-next. Basically following
are implemented -
1. GPIO control for panel enable/disa
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6260
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
From: Tvrtko Ursulin
Measures DRM_IOCTL_MODE_SETCRTC and DRM_IOCTL_MODE_SETPLANE as proxy for
drm_atomic_helper_update_plane if I got it right.
Discovered some slow cursor updates (1.6ms) so needed something to test
different kernel configs etc.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/.g
On Fri, 2015-04-24 at 15:47 +0300, Ander Conselvan De Oliveira wrote:
> On Tue, 2015-03-17 at 11:40 +0200, Imre Deak wrote:
> > From: Damien Lespiau
> >
> > Not every DDIs is necessarily connected can be strapped off and, in the
> > future, we'll have platforms with a different number of default
From: Tim Gore
The call to low_mem_killer_disable(true) was being done
from within function oom_adjust_for_doom. However,
oom_adjust_for_doom gets called from 3 places. We only
want the call to low_mem_killer_disable(true) to happen
during common_init, so call it from here instead of from
oom_adj
On Fri, Apr 24, 2015 at 03:04:37PM +0200, Lukas Hejtmanek wrote:
> On Fri, Apr 24, 2015 at 01:24:56PM +0100, Chris Wilson wrote:
> > iirc xrandr automatically chooses a fb size for your based on the
> > remaining outputs.
> >
> > If you add --fb 3840x2160 to each of your invocations, it shouldn't
On Fri, Apr 24, 2015 at 01:24:56PM +0100, Chris Wilson wrote:
> iirc xrandr automatically chooses a fb size for your based on the
> remaining outputs.
>
> If you add --fb 3840x2160 to each of your invocations, it shouldn't
> touch the screen size. Hopefully.
> -Chris
if you meant something like t
Daniel Vetter writes:
> With the binding regression from the original full ppgtt patches
> fixed we can throw the switch. Yay!
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/driver
On Tue, 2015-03-17 at 11:40 +0200, Imre Deak wrote:
> From: Damien Lespiau
>
> Not every DDIs is necessarily connected can be strapped off and, in the
> future, we'll have platforms with a different number of default DDI
> ports. So, let's only call intel_prepare_ddi_buffers() on DDI ports that
>
On Fri, Apr 24, 2015 at 03:10:20PM +0300, Joonas Lahtinen wrote:
> Use partial view for huge BOs (bigger than half the mappable aperture)
> in fault handler so that they can be accessed withough trying to make
> room for them by evicting other objects.
>
> Signed-off-by: Joonas Lahtinen
> ---
>
On Fri, Apr 24, 2015 at 03:09:39PM +0300, Joonas Lahtinen wrote:
> Do not skip special GGTT views when considering whether an object
> is pinned or not.
>
> Wrong behaviour was introduced in;
>
> commit ec7adb6ee79c8c9fe64d63ad638a31cd62e55515
> Author: Joonas Lahtinen
> Date: Mon Mar 16 14:11
On Fri, Apr 24, 2015 at 02:19:25PM +0200, Lukas Hejtmanek wrote:
> Chris,
>
> On Thu, Apr 23, 2015 at 11:19:50AM +0100, Chris Wilson wrote:
> > Anything is possible... Considering that the two halves are different
> > sizes to the eDP, you can either scale the DP or scale the panel. You
> > can tr
Chris,
On Thu, Apr 23, 2015 at 11:19:50AM +0100, Chris Wilson wrote:
> Anything is possible... Considering that the two halves are different
> sizes to the eDP, you can either scale the DP or scale the panel. You
> can try something like
well, if anything is possible, can I keep virtual size 4k w
Do not to clear mappings outside the allocated VMA under any
circumstances. Only clear the smaller of VMA or object page count.
This is required to allow creating partial object VMAs which in
turn are needed for partial GGTT views.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_ge
GGTT VMA sizes might be smaller than the whole object size due to
different GGTT views.
v2:
- Separate GGTT view constraint calculations from normal view
constraint calculations (Chris Wilson)
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 106 +++
Do not skip special GGTT views when considering whether an object
is pinned or not.
Wrong behaviour was introduced in;
commit ec7adb6ee79c8c9fe64d63ad638a31cd62e55515
Author: Joonas Lahtinen
Date: Mon Mar 16 14:11:13 2015 +0200
drm/i915: Do not use ggtt_view with (aliasing) PPGTT
Cc: Dan
Partial view type allows manipulating parts of huge BOs through the GGTT,
which was not previously possible due to constraint that whole object had
to be mapped for any access to it through GGTT.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 46 +
This series adds partial GGTT views and uses them from the GTT mmap
fault handler for objects bigger than half the aperture. This allows
to handle huge objects through mmap from user land. And not only
huge objects, but when objects are of regular size and aperture is
shrinked due to virtualization
Use partial view for huge BOs (bigger than half the mappable aperture)
in fault handler so that they can be accessed withough trying to make
room for them by evicting other objects.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 67 ++-
On Fri, Apr 24, 2015 at 12:14:17PM +0100, Chris Wilson wrote:
> On Mon, Apr 20, 2015 at 09:04:05AM -0700, Daniel Vetter wrote:
> > Currently we have the problem that the decision whether ptes need to
> > be (re)written is splattered all over the codebase. Move all that into
> > i915_vma_bind. This
On Mon, Apr 20, 2015 at 09:04:05AM -0700, Daniel Vetter wrote:
> Currently we have the problem that the decision whether ptes need to
> be (re)written is splattered all over the codebase. Move all that into
> i915_vma_bind. This needs a few changes:
> - Just reuse the PIN_* flags for i915_vma_bind
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6259
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On 24/04/15 10:43, Olivier Fourdan wrote:
[...]
Yet, *not* setting _FORTIFY_SOURCE seems to work around the issue. I
find it weird the error is with the inlining of memcpy() ...
I'll double check on the gcc side and report back once I know more :)
Quick follow-up, I checked with Jakub and he
On Thu, 2015-04-23 at 08:19 +0200, Maarten Lankhorst wrote:
> This kills off most of the transitional sers and uses atomic plane updates
> in the modeset path to update everything.
>
> Signed-off-by: Maarten Lankhorst
> ---
> Changes since v1:
> - Add atomic and sprite planes during a modeset to
On Wed, 2015-04-22 at 13:24 +0200, maarten.lankho...@linux.intel.com
wrote:
> From: Maarten Lankhorst
>
> This prevents unnecessarily updating power domains, while still
> enabling all power domains on initial setup.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_displ
On Wed, 2015-04-22 at 13:24 +0200, maarten.lankho...@linux.intel.com
wrote:
> From: Maarten Lankhorst
>
> Now that the dpll updates are (mostly) atomic, the .off() code is no longer
> used,
> and there are no more callers for intel_put_shared_dpll.
This is a bit confusing since until this patch
Hi Chris,
On 24/04/15 10:11, Chris Wilson wrote:
On Fri, Apr 24, 2015 at 09:43:37AM +0200, Olivier Fourdan wrote:
gcc generates an error at build time because it fails to inline some
functions:
blt.c: In function 'affine_blt':
blt.c:980:1: error: inlining failed in call to always_inline
On Fri, Apr 24, 2015 at 09:43:37AM +0200, Olivier Fourdan wrote:
> gcc generates an error at build time because it fails to inline some
> functions:
>
> blt.c: In function 'affine_blt':
> blt.c:980:1: error: inlining failed in call to always_inline
> 'bilinear_weight': optimization level att
On 04/23/2015 08:15 PM, Daniel Vetter wrote:
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 1
On Fri, Apr 24, 2015 at 09:43:37AM +0200, Olivier Fourdan wrote:
> gcc generates an error at build time because it fails to inline some
> functions:
>
> blt.c: In function 'affine_blt':
> blt.c:980:1: error: inlining failed in call to always_inline
> 'bilinear_weight': optimization level att
This patch adds information on current CD clock
frequency to debugfs i915_frequency_info
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9c2b
This patch adds information on current CD clock
frequency to debugfs 'i915_frequency_info'.
Mika Kahola (1):
drm/i915: CD clock frequency on debugfs
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
--
1.9.1
___
Intel-gf
gcc generates an error at build time because it fails to inline some
functions:
blt.c: In function 'affine_blt':
blt.c:980:1: error: inlining failed in call to always_inline
'bilinear_weight': optimization level attribute mismatch
bilinear_weight(pixman_fixed_t x)
blt.c:1164:7: error:
Now that there is PAGE_SIZE define, use it.
Signed-off-by: Joonas Lahtinen
---
tests/gem_mmap_gtt.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index e80f52e..92fa644 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests
On Fri, Apr 24, 2015 at 07:45:23AM +0100, Chris Wilson wrote:
> v2: Akash worried that we were discarding the serialisation point with
> outstanding GTT writes before doing the unbind, so restore the wmb() for
> the writes. We only lose the write domain now, and not both - 1 one
> sided barrier now
61 matches
Mail list logo
