Op 17-11-15 om 18:44 schreef Daniel Vetter:
> On Mon, Nov 02, 2015 at 05:38:07PM +0200, Ville Syrjälä wrote:
>> On Mon, Nov 02, 2015 at 01:41:03PM +0100, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> Op 30-10-15 om 22:06 schreef ville.syrj...@linux.intel.com:
From: Ville Syrjälä
This re
Op 17-11-15 om 19:54 schreef Daniel Vetter:
> On Wed, Nov 04, 2015 at 02:43:31PM +0100, Maarten Lankhorst wrote:
>> When setcrtc is called and steals the last connector away from a crtc
>> it's turned off because it can't stay configured without connectors.
>>
>> The framebuffer is still preserved
On Wed, Nov 18, 2015 at 09:36:46AM +0100, Maarten Lankhorst wrote:
> Op 17-11-15 om 18:44 schreef Daniel Vetter:
> > On Mon, Nov 02, 2015 at 05:38:07PM +0200, Ville Syrjälä wrote:
> >> On Mon, Nov 02, 2015 at 01:41:03PM +0100, Maarten Lankhorst wrote:
> >>> Hey,
> >>>
> >>> Op 30-10-15 om 22:06 sch
On Sat, Nov 07, 2015 at 08:29:49AM +1000, Dave Airlie wrote:
> On 3 November 2015 at 22:31, Patrik Jakobsson
> wrote:
> > We need DC5/DC6 to be disabled around modesets to prevent confusing the
> > DMC. Also, we've run out of bits in the 32 bit power domain mask so now
> > it's a 64 bit mask.
> >
Em Tue, 17 Nov 2015 17:21:32 -0700
Jonathan Corbet escreveu:
> On Tue, 17 Nov 2015 13:29:49 -0200
> Mauro Carvalho Chehab wrote:
>
> > The enclosed patch should do the trick. I tested it with perl 5.10 and
> > perl 5.22 it worked fine with both versions.
>
> Indeed it seems to work - thanks!
The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
suspend hooks as errors, but they still show up as errors in dmesg. Tune
them down.
One problem caused by this was noticed by Daniel: the i915 driver
returns EAGAIN to signal a temporary failure to suspend and as a request
On Wed, Nov 04, 2015 at 10:59:28AM +0100, Patrik Jakobsson wrote:
> On Wed, Nov 04, 2015 at 10:35:19AM +0100, Robert Fekete wrote:
> > The old value of 0x7FF will wrap the position at 2048 giving wrong
> > coordinate values on panels larger than 2048 pixels in any direction.
> > Used in i915_debugf
On Wed, 2015-11-18 at 11:12 +0530, Shubhangi Shrivastava wrote:
>
> On Wednesday 18 November 2015 01:23 AM, Daniel Vetter wrote:
> > On Mon, Nov 02, 2015 at 06:25:10PM +0530, Shubhangi Shrivastava wrote:
> > > This patch set cleans up DP detection logic to bring all DPCD
> > > operations at one pl
On Wed, 2015-11-18 at 09:55 +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 09:36:46AM +0100, Maarten Lankhorst wrote:
> > Op 17-11-15 om 18:44 schreef Daniel Vetter:
> > > On Mon, Nov 02, 2015 at 05:38:07PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Nov 02, 2015 at 01:41:03PM +0100, Maarten
On Wednesday 18 November 2015 02:53 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2015-11-18 at 11:12 +0530, Shubhangi Shrivastava wrote:
On Wednesday 18 November 2015 01:23 AM, Daniel Vetter wrote:
On Mon, Nov 02, 2015 at 06:25:10PM +0530, Shubhangi Shrivastava wrote:
This patch set cleans
On Wed, Nov 18, 2015 at 10:02 AM, Daniel Vetter wrote:
> On Sat, Nov 07, 2015 at 08:29:49AM +1000, Dave Airlie wrote:
>> On 3 November 2015 at 22:31, Patrik Jakobsson
>> wrote:
>> > We need DC5/DC6 to be disabled around modesets to prevent confusing the
>> > DMC. Also, we've run out of bits in th
On Wed, Nov 04, 2015 at 11:20:00PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If we ignore the BXT situation, we can observe that the only variables
> affecting gpio_mmio_base is IS_VALLEVIEW and HAS_GMCH_DISPLAY. The BXT
> situation we can fit into the same pattern if
If we suppose that on average it takes 1ms to do a fullscreen paint
(which is fairly typical across generations, as the GPUs get faster the
displays get larger), then the likelihood of a synchronous wait on the last
request completing within 2 microseconds is miniscule. On the other
hand, not every
Convert the bool interruptible argument over to a flags bitmask so that
we can add further bool parameters conveniently.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 42 +++--
drivers/gpu/d
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
spin timeout and so we will just be wasting CPU cycles.
Signed-off-by: Chris Wilson
This should filter out all explicit wait requests from userspace and
only apply busywaiting to circumstances where we are forced to drain the
GPU of old requests. With the 2 microsecond timeout from before, this
still seems to preserve the speed up in stress tests and cancel the
busywaiting for des
On Thu, Nov 05, 2015 at 05:15:59PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> we try a nonblocking pin for the whole object (since that is fastest if
> reused), then failing that we try to
On Thu, Nov 05, 2015 at 09:04:02PM +, Chris Wilson wrote:
> On Thu, Nov 05, 2015 at 10:49:59AM -0800, Rodrigo Vivi wrote:
> > With the lock in place we can expose ips enabled/disable on sysfs
> > for developing, debugging and information purposes.
>
> No. sysfs is not for developement, debuggi
On Tue, Nov 17, 2015 at 10:40:51AM +, Chris Wilson wrote:
> We have varied reports of swizzling corruption on gen4 desktop, and
> confirmation that it is triggered by uneven memory banks. The
> implication is that the swizzling various between the paired channels
> and the remainder of memory o
On Thu, Nov 05, 2015 at 10:50:02AM -0800, Rodrigo Vivi wrote:
> PSR will be enabled on every post primary update when it is
> ready and parameter allows.
> With this we allow test cases to continue using this parameter
> for enabling disabling the feature.
>
> Signed-off-by: Rodrigo Vivi
> ---
>
On Tue, 17 Nov 2015, Ville Syrjälä wrote:
> On Tue, Nov 17, 2015 at 06:14:26PM +0200, Mika Kuoppala wrote:
>> With gen < 9 we have had always 50Mhz units as our hw
>> ratio. With gen >= 9 the hw ratio changed to 16.667Mhz (50/3).
>> The result was that our gpu frequency tracing started to output
>
On Thu, Nov 05, 2015 at 10:50:04AM -0800, Rodrigo Vivi wrote:
> PSR is still disabled by default, but even passing i915.enable_psr=1
> at this point we weren't able to get PSR working because with
> fastboot by default in place we weren't executing the path that enables
> encoder and consequently P
On Thu, Nov 05, 2015 at 10:50:08AM -0800, Rodrigo Vivi wrote:
> With Fastboot by default we don't necessarily do a
> full modeset enabling the primary plane.
> So DRRS enable call that was in that path wasn't being
> called anymore.
>
> So, let's relly on post atomic modeset path
> and on has_drrs
Hi Imre,
[auto build test ERROR on pci/next]
[also build test ERROR on v4.4-rc1 next-20151118]
url:
https://github.com/0day-ci/linux/commits/Imre-Deak/PCI-PM-tune-down-RPM-suspend-error-message-with-EBUSY-and-EAGAIN-retval/20151118-171831
base: https://git.kernel.org/pub/scm/linux/kernel
On Tue, Nov 17, 2015 at 01:49:06PM -0200, Paulo Zanoni wrote:
> 2015-11-17 13:34 GMT-02:00 Daniel Vetter :
[snip]
> > I thought the hidden tests in kms_frontbuffer_tracking would be useful,
> > just really slow, but seems I'm mistaken. In general we have a bunch of
> > stress tests which we want to
On Wed, Nov 18, 2015 at 02:17:17AM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
> head: e64e6bd0f46c78b53b236474f59bd1290b834c89
> commit: 5bab6f60cb4d1417ad7c599166bcfec87529c1a2 [0/1] drm/i915: Serialise
> updates to GGTT with access t
From: Tim Gore
when checking to make sure that the driver has performed
the expected number of resets, this test looks at the
reset_count, which is incremented each time the GPU is
reset. Upcoming changes in the way GPU hangs are handled
mean that in most cases (and in all the cases in this
test)
On Tue, Nov 10, 2015 at 07:49:51PM -0200, Paulo Zanoni wrote:
> 2015-11-10 18:31 GMT-02:00 Paulo Zanoni :
> > 2015-11-05 16:50 GMT-02:00 Rodrigo Vivi :
> >> According to VESA DP spec TEST_CRC_COUNT (Bits 3:0) at
> >> TEST_SINK_MISC (00246h) is "Reset to 0 when TEST_SINK bit 0 = 0;
> >>
> >> So let'
On Thu, Nov 05, 2015 at 06:30:30PM -0200, Paulo Zanoni wrote:
> 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi :
> > Even with all sink crc re-works we still have platforms
> > where after 6 vblanks it is unable to calculate the
> > sink crc. But if we don't get the sink crc it isn't true
> > that test fa
On Mon, Nov 09, 2015 at 11:52:20AM -0200, Paulo Zanoni wrote:
> 2015-11-05 18:40 GMT-02:00 Ville Syrjälä :
> > On Thu, Nov 05, 2015 at 06:34:07PM -0200, Paulo Zanoni wrote:
> >> 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi :
> >> > There are few platforms with other suspend resume bugs that breaks
> >>
On Tue, Nov 17, 2015 at 11:35:33PM +0200, Imre Deak wrote:
> On Tue, 2015-11-17 at 23:30 +0200, Ville Syrjälä wrote:
> > On Tue, Nov 17, 2015 at 10:18:41PM +0100, Daniel Vetter wrote:
> > > If we can't acquire dev->struct_mutex we need to fail runtime suspend,
> > > at least with the current design
On Fri, Nov 06, 2015 at 07:34:46PM +0530, Vandita Kulkarni wrote:
> From: vandita kulkarni
>
> This patch adds support for RGB formats on sprites
> for BXT (as per Bspec) as we have Universal planes
> This patch also adds support for AYUV format on
> primary and sprites.
>
> Signed-off-by: vandi
On Sun, Nov 08, 2015 at 12:31:36AM +, Damien Lespiau wrote:
> Hi all,
>
> I've added a feature to sort the patches sent to intel-gfx into 3
> buckets: i915, intel-gpu-tools and libdrm. This sorting relies on
> tagging patches, using the subject prefixes (which is what most people
> do already
The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
suspend hooks as errors, but they still show up as errors in dmesg. Tune
them down.
One problem caused by this was noticed by Daniel: the i915 driver
returns EAGAIN to signal a temporary failure to suspend and as a request
On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
> Typing:
>
> # cat /sys/devices/pci:00/:00:02.0/rom
>
> Provokes:
>
> i915 :00:02.0: Invalid ROM contents
Hmm. So there's no PCI option ROM there. I wonder what is there. I
get the same on my Braswell BTW. I tried to
On older platforms scalers/cliping used to provide destination size an
exact multiple of src size.
Gen-9 and above support fractional ratio of dst/src so that source is
not manipulated to meet the exact multiple factor.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/i915/intel_sprite.c | 48 ++
On 90/270 rotation case source width and height was not compared
properly with destination height and width check plane.Which added
erroneous check while doing scaling or normal 90/270 rotation.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/i915/intel_display.c | 22 --
1
On Wed, Nov 18, 2015 at 10:24:43AM +, tim.g...@intel.com wrote:
> From: Tim Gore
>
> when checking to make sure that the driver has performed
> the expected number of resets, this test looks at the
> reset_count, which is incremented each time the GPU is
> reset. Upcoming changes in the way G
Uninitialized variables (width, Height) in intel_check_sprite_plane
leads to compilererror in O1 level. Initialize all declared variables
to fix this issue.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
> On older platforms scalers/cliping used to provide destination size an
> exact multiple of src size.
> Gen-9 and above support fractional ratio of dst/src so that source is
> not manipulated to meet the exact multiple factor.
>
> Sig
On Wed, Nov 18, 2015 at 05:19:26PM +0530, Nabendu Maiti wrote:
> On 90/270 rotation case source width and height was not compared
> properly with destination height and width check plane.Which added
> erroneous check while doing scaling or normal 90/270 rotation.
>
> Signed-off-by: Nabendu Maiti
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, November 18, 2015 11:54 AM
> To: Gore, Tim
> Cc: intel-gfx@lists.freedesktop
On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
> Uninitialized variables (width, Height) in intel_check_sprite_plane
> leads to compilererror in O1 level. Initialize all declared variables
> to fix this issue.
>
> Signed-off-by: Nabendu Maiti
> ---
> drivers/gpu/drm/i915/intel_sp
On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
> Uninitialized variables (width, Height) in intel_check_sprite_plane
> leads to compilererror in O1 level. Initialize all declared variables
> to fix this issue.
>
> Signed-off-by: Nabendu Maiti
Or perhaps:
diff --git a/drivers/gpu
CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock
used for timing execution of tests.
When fetching either the starting or ending time of a test, show the
time as -1.000s.
v3:
- Do not exit directly from handler (Chris)
- Show elapsed time as -1 if it is not calculable
v2:
-
On 16.11.2015 17:53, Jani Nikula wrote:
On Mon, 16 Nov 2015, Maarten Lankhorst
wrote:
When diagnosing a unrelated bug for someone on irc, it would seem the hardware
can
be brought up by the BIOS with the embedded displayport using the SPLL for
spread spectrum.
Right now this is not handle
On Wed, Nov 18, 2015 at 02:18:52PM +0200, Joonas Lahtinen wrote:
> CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock
> used for timing execution of tests.
>
> When fetching either the starting or ending time of a test, show the
> time as -1.000s.
>
> v3:
> - Do not exit direct
On Fri, Nov 06, 2015 at 09:43:41PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Store the upper dword of the register offset in the whitelist as well.
> This would allow it to read register where the two halves aren't sitting
> right next to each other, and it'll make it
The power metter was not showing up due to a check over I915_PERF_ENERGY.
ENOENT is returned when I915_PERF_ENERGY is not available, and we use
that for relaying on debugfs i915_energy_uJ.
Signed-off-by: Marius Vlad
---
overlay/power.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
d
On 18 November 2015 at 13:31, Gabriel Feceoru wrote:
>
>
> On 16.11.2015 17:53, Jani Nikula wrote:
>>
>> On Mon, 16 Nov 2015, Maarten Lankhorst
>> wrote:
>>>
>>> When diagnosing a unrelated bug for someone on irc, it would seem the
>>> hardware can
>>> be brought up by the BIOS with the embedded
From: Marius Vlad
The power metter was not showing up due to a check over I915_PERF_ENERGY.
ENOENT is returned when I915_PERF_ENERGY is not available, and we use
that for relaying on debugfs i915_energy_uJ.
Signed-off-by: Marius Vlad
---
overlay/power.c | 4 ++--
1 file changed, 2 insertions(+
From: Marius Vlad
Use sigaction() instead of signal() and add SIGINT, SIGTERM to close
the overlay window. With this change the overlay window will be
destroyed.
Signed-off-by: Marius Vlad
---
overlay/overlay.c | 42 --
1 file changed, 36 insertions(+),
From: Marius Vlad
The power metter was not showing up due to a check over I915_PERF_ENERGY.
ENOENT is returned when I915_PERF_ENERGY is not available, and we use
that for relaying on debugfs i915_energy_uJ.
Signed-off-by: Marius Vlad
---
overlay/power.c | 4 ++--
1 file changed, 2 insertions(+
On Wed, Nov 18, 2015 at 02:36:22PM +0200, Marius Vlad wrote:
> The power metter was not showing up due to a check over I915_PERF_ENERGY.
> ENOENT is returned when I915_PERF_ENERGY is not available, and we use
> that for relaying on debugfs i915_energy_uJ.
>
> Signed-off-by: Marius Vlad
> ---
> o
agreed, this is better
On 11/18/2015 5:49 PM, Chris Wilson wrote:
On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
Uninitialized variables (width, Height) in intel_check_sprite_plane
leads to compilererror in O1 level. Initialize all declared variables
to fix this issue.
Signed
Just trying to figure out what we have currently. I can redo with with -1, if
that's
OK with you.
Out of curiosity noticed that I915_PERF_ENERGY is not available on my machine,
is that related to i915_oa? (Haswell).
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk
On Wed, Nov 18, 2015 at 12:19:06PM +, Chris Wilson wrote:
> On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
> > Uninitialized variables (width, Height) in intel_check_sprite_plane
> > leads to compilererror in O1 level. Initialize all declared variables
> > to fix this issue.
> >
We'll be adding more context for the subtests than just the max
brightness.
Signed-off-by: Jani Nikula
---
tests/pm_backlight.c | 39 ++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/tests/pm_backlight.c b/tests/pm_backlight.c
index bdc0e33d
Gives out better diagnostics than just igt_asssert.
Signed-off-by: Jani Nikula
---
tests/pm_backlight.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/pm_backlight.c b/tests/pm_backlight.c
index d24fb1034198..bdc0e33de94c 100644
--- a/tests/pm_backlight.c
+++ b/test
Signed-off-by: Jani Nikula
---
tests/pm_backlight.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tests/pm_backlight.c b/tests/pm_backlight.c
index c199b9bf4baf..8258d4e4c124 100644
--- a/tests/pm_backlight.c
+++ b/tests/pm_backlight.c
@@ -95,7 +95,7 @@ stat
On ke, 2015-11-18 at 12:28 +, Chris Wilson wrote:
> On Wed, Nov 18, 2015 at 02:18:52PM +0200, Joonas Lahtinen wrote:
> > CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE
> > clock
> > used for timing execution of tests.
> >
> > When fetching either the starting or ending time of
On Wed, Nov 18, 2015 at 12:50:10PM +, Vlad, Marius C wrote:
> Just trying to figure out what we have currently. I can redo with with -1, if
> that's
> OK with you.
Already pushed.
> Out of curiosity noticed that I915_PERF_ENERGY is not available on my
> machine,
> is that related to i915
Hi,
Just applying this patch is enough to make gem_ringfill --r render work
on my SKL 2+2 DT GT2 system I have at Espoo. I do not need the second
patch which seems to be required for Arun's SKL.
Also working with just that patch on one SKL Y system here at Egham
office. It's some months older tha
On Wed, Nov 18, 2015 at 02:40:29PM +0200, marius.c.v...@intel.com wrote:
> From: Marius Vlad
>
> Use sigaction() instead of signal() and add SIGINT, SIGTERM to close
> the overlay window. With this change the overlay window will be
> destroyed.
>
> Signed-off-by: Marius Vlad
> ---
> overlay/ov
On Wed, Nov 18, 2015 at 02:54:20PM +0200, Joonas Lahtinen wrote:
> On ke, 2015-11-18 at 12:28 +, Chris Wilson wrote:
> > On Wed, Nov 18, 2015 at 02:18:52PM +0200, Joonas Lahtinen wrote:
> > > CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE
> > > clock
> > > used for timing execu
On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
On older platforms scalers/cliping used to provide destination size an
exact multiple of src size.
Gen-9 and above support fractional ratio of dst/src so that source is
not manipulated to
On Wed, 18 Nov 2015, Emil Renner Berthing wrote:
> On 18 November 2015 at 13:31, Gabriel Feceoru
> wrote:
>>
>>
>> On 16.11.2015 17:53, Jani Nikula wrote:
>>>
>>> On Mon, 16 Nov 2015, Maarten Lankhorst
>>> wrote:
When diagnosing a unrelated bug for someone on irc, it would seem the
>>
On 11/18/2015 6:22 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 12:19:06PM +, Chris Wilson wrote:
On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
Uninitialized variables (width, Height) in intel_check_sprite_plane
leads to compilererror in O1 level. Initialize all decl
On Wed, Nov 18, 2015 at 06:37:17PM +0530, Maiti, Nabendu Bikash wrote:
>
>
> On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
> >> On older platforms scalers/cliping used to provide destination size an
> >> exact multiple of src size.
On ke, 2015-11-18 at 12:56 +0200, Imre Deak wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down.
>
> One problem caused by this was noticed by Daniel: the i915 driver
> returns EA
On Wed, Nov 18, 2015 at 06:48:37PM +0530, Maiti, Nabendu Bikash wrote:
>
>
>
> On 11/18/2015 6:22 PM, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 12:19:06PM +, Chris Wilson wrote:
> >> On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
> >>> Uninitialized variables (width, H
On Wed, Nov 18, 2015 at 5:59 AM, Ville Syrjälä
wrote:
> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>> Typing:
>>
>> # cat /sys/devices/pci:00/:00:02.0/rom
>>
>> Provokes:
>>
>> i915 :00:02.0: Invalid ROM contents
>
> Hmm. So there's no PCI option ROM there. I wond
On Wed, Nov 04, 2015 at 11:19:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Another round of stuff for the type safe register access. Some of these
> were already posted during the first round, but a lot of it is new
> (LRI stuff, cmd parser, lrc setup etc., vgpu, etc
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, November 18, 2015 2:59 PM
To: Vlad, Marius C
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH i-g-t] overlay/intel-gpu-overlay
On Wed, Nov 18, 2015 at 02:40:29PM +0200, marius.c.
Due to the current sharing of the DDI encoder between DP and HDMI
connectors we can run the DP detection after the HDMI detection has
already set the shared encoder's type. For now solve this keeping the
current behavior and running the detection in this case too. For a proper
solution Ville sugges
MISSING_CASE() would have been useful to track down a recent problem in
intel_display_port_aux_power_domain(), so add it there and a few related
helpers. This was also suggested by Ville in his review of the latest
DMC/DC changes, we forgot to address that.
Signed-off-by: Imre Deak
---
drivers/g
On Wed, Nov 18, 2015 at 01:51:57PM +, Vlad, Marius C wrote:
>
>
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, November 18, 2015 2:59 PM
> To: Vlad, Marius C
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t
On Wed, Nov 18, 2015 at 12:15:11PM +, Gore, Tim wrote:
>
>
> Tim Gore
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Wednesda
On Wed, Nov 18, 2015 at 03:28:38PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 12:56 +0200, Imre Deak wrote:
> > The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> > suspend hooks as errors, but they still show up as errors in dmesg. Tune
> > them down.
> >
> > One pro
On Wed, Nov 18, 2015 at 03:57:25PM +0200, Imre Deak wrote:
> MISSING_CASE() would have been useful to track down a recent problem in
> intel_display_port_aux_power_domain(), so add it there and a few related
> helpers. This was also suggested by Ville in his review of the latest
> DMC/DC changes, w
On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> Atm, we assert that the device is not suspended after the point when the
> HW is truly put to a suspended state. This is fine, but we can catch
> more problems if we check the RPM refcount. After that one drops to zero
> we shouldn't acce
On Wed, Nov 18, 2015 at 03:57:25PM +0200, Imre Deak wrote:
> MISSING_CASE() would have been useful to track down a recent problem in
> intel_display_port_aux_power_domain(), so add it there and a few related
> helpers. This was also suggested by Ville in his review of the latest
> DMC/DC changes, w
On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > Atm, we assert that the device is not suspended after the point
> > when the
> > HW is truly put to a suspended state. This is fine, but we can
> > catch
> > more problems if we c
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, November 18, 2015 2:12 PM
> To: Gore, Tim
> Cc: Daniel Vetter; intel-gfx@lis
On Tue, Nov 10, 2015 at 07:37:54AM -0800, Vinay Belgaumkar wrote:
> v1: These tests exercise the userptr ioctl to create shared buffers
> between CPU and GPU. They contain error and normal usage scenarios.
> They also contain a couple of stress tests which copy buffers between
> CPU and GPU. These
On Mon, Nov 16, 2015 at 03:59:15PM +, Rodrigo Vivi wrote:
> Hi Daniel,
>
> could you please ignore patch 5 in this series and merge the 4 first
> patches.
I merged an earlier instance of the first 4 patches. Has anything changed?
Please double-check the right versions landed in dinq.
Thanks,
On Mon, Nov 16, 2015 at 04:00:35PM +, Rodrigo Vivi wrote:
> Hi Daniel,
>
> All 4 patches in this series are reviewed and ready to merge,
> could you please merge them?
All merged to dinq, thanks for patches&review.
-Daniel
>
> Thanks,
> Rodrigo.
>
> On Fri, Nov 13, 2015 at 10:42 AM Vivi, R
On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > > Atm, we assert that the device is not suspended after the point
> > > when the
> > > HW is truly put to a suspended state.
On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > > > Atm, we assert that the device is not suspended after t
On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
Their logic is exactly the same: check if the digital port is connected
and then call intel_dp_detect_dpcd(). So just put that logic in their
only caller: intel_dp_detect().
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp.c | 33 +
1
There was a silent conflict between
commit 0a878716265e9af9f697264dc2e858fcc060d833
Author: Daniel Vetter
Date: Thu Oct 15 14:23:01 2015 +0200
drm/i915: restore ggtt double-bind avoidance
and
commit 5bab6f60cb4d1417ad7c599166bcfec87529c1a2
Author: Chris Wilson
Date: Fri Oct 23 18:43:3
That call was moved to intel_dp_detect() in
commit d410b56d74bc706f414158cb0149e2a149ee1650
Author: Chris Wilson
Date: Tue Sep 2 20:03:59 2014 +0100
drm/i915/dp: Refactor common eDP lid detection
but it seem to have been resurrected in the following commit, probably
due to a wrong merge c
Hi,
currently a DDI port may register both DP and HDMI and it shares the
same encoder. The bug we've got a report is about this encoder type:
namely, a machine using DDI port D for HDMI is screwed up because the
encoder is switched to DP suddently. The details are found in:
http://bugzilla.ope
On Wed, Nov 18, 2015 at 05:19:29PM +0200, Ander Conselvan de Oliveira wrote:
> That call was moved to intel_dp_detect() in
>
> commit d410b56d74bc706f414158cb0149e2a149ee1650
> Author: Chris Wilson
> Date: Tue Sep 2 20:03:59 2014 +0100
>
> drm/i915/dp: Refactor common eDP lid detection
>
During suspend-to-idle we need to keep the DMC firmware active and DC6
enabled, since otherwise we won't reach deep system power states like
PC9/10. The lead for this came from Nivedita who noticed that the
kernel's turbostat tool didn't report any PC9/10 residency change
across an 'echo freeze > /
On Wed, Nov 18, 2015 at 04:23:06PM +0100, Takashi Iwai wrote:
> Hi,
>
> currently a DDI port may register both DP and HDMI and it shares the
> same encoder. The bug we've got a report is about this encoder type:
> namely, a machine using DDI port D for HDMI is screwed up because the
> encoder is
On Wed, Nov 18, 2015 at 04:23:06PM +0100, Takashi Iwai wrote:
> Hi,
>
> currently a DDI port may register both DP and HDMI and it shares the
> same encoder. The bug we've got a report is about this encoder type:
> namely, a machine using DDI port D for HDMI is screwed up because the
> encoder is
On Mon, Nov 16, 2015 at 03:22:23PM +0200, Joonas Lahtinen wrote:
> Cc: Thomas Wood
> Cc: Chris Wilson
> Cc: Damien Lespiau
> Signed-off-by: Joonas Lahtinen
Given that we have all that in piglit already the commit message is a bit
thin on justification. Why do we need this in igt too? How does
On Wed, Nov 18, 2015 at 05:11:03PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> > On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> > > On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > > > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
1 - 100 of 160 matches
Mail list logo
