On Wed, Aug 13, 2014 at 11:34:02AM +0530, Sharma, Shashank wrote:
> > I know. That is orthogonal to the tweaks I was suggesting. Also if you
> > feel you need to add details to your rationale, then your changelog is
> > incomplete.
> > -Chris
>
> Thanks Chris,
> Please find my comments inline to y
> I know. That is orthogonal to the tweaks I was suggesting. Also if you
> feel you need to add details to your rationale, then your changelog is
> incomplete.
> -Chris
Thanks Chris,
Please find my comments inline to your previous mail, with suggestions.
On 8/12/2014 6:17 PM, Chris Wilson wrote:
On Tue, Aug 12, 2014 at 10:37:21PM +0200, Daniel Vetter wrote:
> On Tue, Aug 12, 2014 at 10:30 PM, Chris Wilson
> wrote:
> > On Tue, Aug 12, 2014 at 10:19:20PM +0200, Daniel Vetter wrote:
> >> On Tue, Aug 12, 2014 at 9:33 PM, Paulo Zanoni wrote:
> >> > 2014-08-12 16:28 GMT-03:00 Chris Wilson :
>
On Tue, Aug 12, 2014 at 10:30 PM, Chris Wilson wrote:
> On Tue, Aug 12, 2014 at 10:19:20PM +0200, Daniel Vetter wrote:
>> On Tue, Aug 12, 2014 at 9:33 PM, Paulo Zanoni wrote:
>> > 2014-08-12 16:28 GMT-03:00 Chris Wilson :
>> >> On Tue, Aug 12, 2014 at 04:12:38PM -0300, Paulo Zanoni wrote:
>> >>>
On Tue, Aug 12, 2014 at 10:19:20PM +0200, Daniel Vetter wrote:
> On Tue, Aug 12, 2014 at 9:33 PM, Paulo Zanoni wrote:
> > 2014-08-12 16:28 GMT-03:00 Chris Wilson :
> >> On Tue, Aug 12, 2014 at 04:12:38PM -0300, Paulo Zanoni wrote:
> >>> But we just get/put RPM around this function, not for the who
On Tue, Aug 12, 2014 at 9:33 PM, Paulo Zanoni wrote:
> 2014-08-12 16:28 GMT-03:00 Chris Wilson :
>> On Tue, Aug 12, 2014 at 04:12:38PM -0300, Paulo Zanoni wrote:
>>> But we just get/put RPM around this function, not for the whole time
>>> while the object is pinned.
>>
>> Ah misread, saw pin->get,
2014-08-12 16:28 GMT-03:00 Chris Wilson :
> On Tue, Aug 12, 2014 at 04:12:38PM -0300, Paulo Zanoni wrote:
>> But we just get/put RPM around this function, not for the whole time
>> while the object is pinned.
>
> Ah misread, saw pin->get, unpin->put and assumed the symmetry. But why
> unpin then? I
On Tue, Aug 12, 2014 at 04:12:38PM -0300, Paulo Zanoni wrote:
> But we just get/put RPM around this function, not for the whole time
> while the object is pinned.
Ah misread, saw pin->get, unpin->put and assumed the symmetry. But why
unpin then? It doesn't touch any hardware registers.
-Chris
--
2014-08-12 16:09 GMT-03:00 Chris Wilson :
> On Tue, Aug 12, 2014 at 03:55:12PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If we're runtime suspended and try to use the plane interfaces, we
>> will get a lot of WARNs saying we did the wrong thing.
>>
>> We need to get runtime PM referen
On Tue, Aug 12, 2014 at 03:55:12PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we're runtime suspended and try to use the plane interfaces, we
> will get a lot of WARNs saying we did the wrong thing.
>
> We need to get runtime PM references to pin/unpin the objects, and to
> change th
For cleanliness, i915_error_object_create() was written to handle the
NULL pointer in a central location. The macro that wrapped it and passed
it a num_pages to use, was not safe. As we now never limit the num_pages
to use (we did so at one point to only capture the first page of the
context), we c
The current error state harks back to the era of just a single VM. For
full-ppgtt, we capture every bo on every VM. It behoves us to then print
every bo for every VM, which we currently fail to do and so miss vital
information in the error state.
v2: Use the vma address rather than -1!
Signed-off
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 726e6b1..1e05414 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
++
At the heart of this change is that the seqno is a too low level of an
abstraction to handle the growing complexities of command tracking, both
with the introduction of multiple command queues with execbuffer and the
potential for reordering with a scheduler. On top of the seqno we have
the request
For stolen pages, since it is verboten to access them directly on many
architectures, we have to read them through the GTT aperture. If they
are not accessible through the aperture, then we have to abort.
This was complicated by
commit 8b6124a633d8095b0c8364f585edff9c59568a96
Author: Chris Wilson
From: Paulo Zanoni
If we're runtime suspended and try to use the plane interfaces, we
will get a lot of WARNs saying we did the wrong thing.
We need to get runtime PM references to pin/unpin the objects, and to
change the fences. The pin/unpin functions are the ideal places for
this, but intel_c
2014-08-12 13:39 GMT-03:00 :
> From: Ville Syrjälä
>
> Make sure the cursor gets fully clipped when enabling it on a disabled
> crtc via setplane. This will prevent the lower level code from
> attempting to enable the cursor in hardware.
If this is going to replace part of the fix I recently sub
On 08/11/2014 11:59 PM, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 07:39:24AM +0100, Chris Wilson wrote:
On Mon, Aug 11, 2014 at 03:33:02PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Intel HDMI does not correctly configure pixel replicated HDMI modes
480i and 576i. Remove s
From: Ville Syrjälä
Ever since
commit 5efb3e2838536832c9b6872512e6b6daf592cee9
Author: Ville Syrjälä
Date: Wed Apr 9 13:28:53 2014 +0300
drm/i915/chv: Add cursor pipe offsets
the only difference between i9xx_update_cursor() and ivb_update_cursor()
was the hsw+ pipe csc handling. Let's
On Tue, Aug 12, 2014 at 07:39:55PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 845/865 support different cursor sizes as well, albeit a bit differently
> than later platforms. Add the necessary code to make them work.
>
> Untested due to lack of hardware.
Oh that looks
From: Ville Syrjälä
845/865 support different cursor sizes as well, albeit a bit differently
than later platforms. Add the necessary code to make them work.
Untested due to lack of hardware.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 3 +-
drivers/gpu/drm/i915/in
From: Ville Syrjälä
I had to look at the cursor code recently, and as usual I ended up
doing bit of fixing and some cleanups. There's still more that needs
doing, but I'll leave that for later and not continue down this path
for now.
While trying to figure out what this CURSIZE register is I als
From: Ville Syrjälä
CURSIZE register exists on 845/865 only, so move it to
i845_update_cursor(). Changes to cursor size must be done only when the
cursor is disabled, so do the write just before enabling the cursor.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5 +---
From: Ville Syrjälä
Make sure the cursor gets fully clipped when enabling it on a disabled
crtc via setplane. This will prevent the lower level code from
attempting to enable the cursor in hardware.
Cc: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4 ++-
On Tue, Aug 12, 2014 at 08:56:44PM +0530, Sharma, Shashank wrote:
> Hello Chris,
>
> Thanks for your time and comments.
> I would like to give a brief history of the patch.
>
> We tried to apply this optimization by default, and check all the
> EDID read based on the live status. But not all deve
Hello Chris,
Thanks for your time and comments.
I would like to give a brief history of the patch.
We tried to apply this optimization by default, and check all the EDID
read based on the live status. But not all developers agreed to have
this by default, with following reasons:
1. live_statu
Hi Paulo,
Thanks for your response. I am on kernel 3.13.0-32-generic. I was
actually able to resolve my problem by installing the latest Intel graphics
driver on Ubuntu.
Thank You,
Brayden Williams
On Mon, Aug 11, 2014 at 6:12 AM, Paulo Zanoni wrote:
> Hi
>
> When you have this type of que
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock acquisation into the callee where it will
be compiled out by the config option entirely. This includes moving the
deferred fb_set_suspend() dance and encapsulating it entirely within
intel_fbdev.c.
Make backlight class sysfs bl_power a sub-state of backlight enabled, if
a backlight power connector callback is defined. It's up to the
connector callback to handle the sub-state, typically in a way that
respects panel power sequencing.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_
Make backlight class sysfs brightness 0 value switch off the backlight
for connectors that have the backlight_power callback defined. For eDP,
this has the similar caveats regarding power savings as bl_power as only
the power sequencer backlight control is switched off.
Signed-off-by: Jani Nikula
Make it possible to change panel power control backlight state without
touching the PWM. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu
This lets the userspace switch off the backlight using the backlight
class sysfs bl_power file. The switch is done using the power sequencer;
the backlight PWM, and everything else, remains enabled. The display
backlight won't draw power, but for maximum power savings the encoder
needs to be switch
This series adds support for backlight class sysfs bl_power attribute
for eDP panels, which allows switching the backlight on/off. This is
done using the eDP panel power control as a sub-state of everything else
being enabled. Patch 4 also makes 0 brightness switch off the eDP
backlight using the s
On Fri, Aug 08, 2014 at 01:09:25PM +, Thierry, Michel wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Daniel Vetter
> > Sent: Wednesday, August 06, 2014 2:05 PM
> > To: Intel Graphics Development
> > Cc: Daniel Ve
On Tue, 2014-08-12 at 15:53 +0300, Ville Syrjälä wrote:
> On Tue, Aug 12, 2014 at 03:36:01PM +0300, Imre Deak wrote:
> > On Tue, 2014-08-12 at 15:13 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 11, 2014 at 09:54:15PM +0300, Imre Deak wrote:
> > > > Make sure these work handlers don't run after we
On Tue, Aug 12, 2014 at 11:24:11AM +0300, Ville Syrjälä wrote:
> On Mon, Aug 11, 2014 at 04:44:23PM -0300, Paulo Zanoni wrote:
> > 2014-06-30 7:10 GMT-03:00 Jani Nikula :
> > > On Thu, 26 Jun 2014, Rodrigo Vivi wrote:
> > >> I'm sure this might affect Wayne, so, cc'ing him here.
> > >>
> > >> from
On Tue, 2014-08-12 at 15:34 +0300, Ville Syrjälä wrote:
> On Mon, Aug 11, 2014 at 10:04:50PM +0300, Imre Deak wrote:
> > Atm we may leave eDP VDD enabled during system suspend after the CRTCs
> > are disabled through an HPD->DPCD read event. So disable VDD during
> > suspend at a point when no HPDs
On Tue, Aug 12, 2014 at 03:36:01PM +0300, Imre Deak wrote:
> On Tue, 2014-08-12 at 15:13 +0300, Ville Syrjälä wrote:
> > On Mon, Aug 11, 2014 at 09:54:15PM +0300, Imre Deak wrote:
> > > Make sure these work handlers don't run after we system suspend or
> > > unload the driver. Note that we don't ca
On Tue, Aug 12, 2014 at 06:08:21PM +0530, shashank.sha...@intel.com wrote:
> From: Shashank Sharma
>
> During the HDMI complaince tests, most of the HDMI analyzers
> issue a soft HPD, to automate the tests. This process keeps
> the HDMI cable connected, and DDC chhanel alive.
>
> HDMI detect() l
On Tue, 2014-08-12 at 15:13 +0300, Ville Syrjälä wrote:
> On Mon, Aug 11, 2014 at 09:54:15PM +0300, Imre Deak wrote:
> > Make sure these work handlers don't run after we system suspend or
> > unload the driver. Note that we don't cancel the handlers during runtime
> > suspend. That could lead to a
On Mon, Aug 11, 2014 at 10:04:50PM +0300, Imre Deak wrote:
> Atm we may leave eDP VDD enabled during system suspend after the CRTCs
> are disabled through an HPD->DPCD read event. So disable VDD during
> suspend at a point when no HPDs can occur.
And vdd itself holds a runtime pm ref so this probl
From: Shashank Sharma
During the HDMI complaince tests, most of the HDMI analyzers
issue a soft HPD, to automate the tests. This process keeps
the HDMI cable connected, and DDC chhanel alive.
HDMI detect() logic relies on EDID readability, to decide if
its a HDMI connect or disconnect event. But
From: Shashank Sharma
The current hdmi_detect() function is getting called from
many places, few of these are:
1. HDMI hot plug interrupt bottom half
2. get_resources() IOCTL family
3. drm_helper_probe_single_connector_modes() family
4. output_poll_execute()
5. status_show() etc...
Every time th
From: Shashank Sharma
This patch set adds 2 patches:
1. drm/i915: Optimize HDMI EDID reads
This patch adds a EDID caching solution in intel_hdmi_detect function
to avoid multiple EDID reads for single HPD. A delayed work function
makes sure that the cached EDID gets clear after a time out.
2. dr
On Mon, Aug 11, 2014 at 10:04:51PM +0300, Imre Deak wrote:
> Atm we may retrain the DP link even if the CRTC is inactive through
> HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
> (at least on BYT), since the DP port is disabled.
>
> Bugzilla: https://bugs.freedesktop.org
On Mon, Aug 11, 2014 at 09:54:15PM +0300, Imre Deak wrote:
> Make sure these work handlers don't run after we system suspend or
> unload the driver. Note that we don't cancel the handlers during runtime
> suspend. That could lead to a lockup, since we take a runtime PM ref
> from the handlers thems
On Tue, Aug 12, 2014 at 04:21:55PM +0530, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> v1:
> Sequence to get gfx clocks on/off, allow/disallow wake and save/restore of
> gunit registers need to be followed in
> PM suspend and resume path similar to runtime suspend and resume.
>
> v2
On Tue, Aug 12, 2014 at 10:24:58AM +0100, Chris Wilson wrote:
> This reverts commit 67e5871be82fec1451801d448b51d9a403d1ffac.
>
> The missed interrupts are back, in a big fashion. I am observing stalls
> followed by the missing interrupt warning on every Sandybridge+ machine
> I have (a mixture of
On Tue, Jul 29, 2014 at 02:58:23PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated
> to 1440. The current driver reports 1440 pixel to the OS and does not set
> pixel replicated modes.
>
> Signed-of
From: Sagar Kamble
v1:
Sequence to get gfx clocks on/off, allow/disallow wake and save/restore of
gunit registers need to be followed in
PM suspend and resume path similar to runtime suspend and resume.
v2:
1. Keeping GT access, wake, gunit save/restore related helpers static.
2. Moved GT acces
A plain bool is good enough, no need for fancy negative error values.
Signed-off-by: Daniel Vetter
---
lib/igt_kms.c | 12 ++--
lib/igt_kms.h | 4 ++--
tests/kms_setmode.c | 4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms
So give it a kmstest_ prefix and shuffle it around a bit.
Signed-off-by: Daniel Vetter
---
lib/igt_kms.c | 14 +-
lib/igt_kms.h | 9 ++---
tests/kms_cursor_crc.c | 2 +-
tests/kms_fbc_crc.c | 2 +-
tests/kms_fence_pin_leak.c | 2 +-
t
And remove sprite_name, redundant and won't work due to lack of
dev_priv.
Signed-off-by: Daniel Vetter
---
lib/igt_kms.c | 40 ++--
lib/igt_kms.h | 13 +
2 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
A plain bool is enough.
Signed-off-by: Daniel Vetter
---
lib/igt_kms.c | 15 ---
lib/igt_kms.h | 7 +++
tests/kms_flip.c | 12 ++--
tests/kms_psr_sink_crc.c | 11 ---
tests/kms_render.c | 6 ++
tests/kms_sink_crc
And add api doc while at it.
Signed-off-by: Daniel Vetter
---
lib/igt_debugfs.c | 8 +++---
lib/igt_kms.c | 61 ++---
lib/igt_kms.h | 3 +--
tests/kms_cursor_crc.c | 10 +---
tests/kms_fbc_crc.c | 15
Also shuffle things around a bit to make sure the order in the header
matches the order in the .c file.
Signed-off-by: Daniel Vetter
---
lib/igt_kms.h | 53 +
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/lib/igt_kms.h b/lib/i
It's not documented and there's really not a lot to it either. We can
always readd when it's growing into something bigger.
Signed-off-by: Daniel Vetter
---
docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml | 1 -
1 file changed, 1 deletion(-)
diff --git a/docs/reference/intel-gpu-tools/i
Group them a bit both in the header and .c file, and make sure they
appear in the same order in both.
Signed-off-by: Daniel Vetter
---
lib/igt_kms.c | 372 +-
lib/igt_kms.h | 19 +--
2 files changed, 196 insertions(+), 195 deletions(-)
di
Plus a bit an overview section explaining the split in the library - a
few people (everyone except me it seems) didn't really understand it.
Signed-off-by: Daniel Vetter
---
lib/igt_kms.c | 54 --
1 file changed, 52 insertions(+), 2 deletions(-
Signed-off-by: Daniel Vetter
---
tests/kms_cursor_crc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index bbbf053d3207..723a6d556b54 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -396,8 +396,7 @@ stati
This reverts commit 67e5871be82fec1451801d448b51d9a403d1ffac.
The missed interrupts are back, in a big fashion. I am observing stalls
followed by the missing interrupt warning on every Sandybridge+ machine
I have (a mixture of Sandybridge, Ivybridge and Haswell).
Signed-off-by: Chris Wilson
---
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Wednesday, August 06, 2014 7:20 PM
> To: Intel Graphics Development
> Cc: Daniel Vetter
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915: Rework ppgtt init to no require
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Wednesday, August 06, 2014 2:05 PM
> To: Intel Graphics Development
> Cc: Daniel Vetter
> Subject: [Intel-gfx] [PATCH 07/15] drm/i915: Allow
> i915_gem_setup_global
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Wednesday, August 06, 2014 2:05 PM
> To: Intel Graphics Development
> Cc: Daniel Vetter
> Subject: [Intel-gfx] [PATCH 03/15] drm/i915: Move i915_gem_chipset_flush
>
On Tue, Aug 12, 2014 at 09:36:04AM +0100, Chris Wilson wrote:
> As we may query the edid multiple times following a detect, record the
> EDID found during output discovery and reuse it. This is a separate
> issue from caching the output EDID across detection cycles.
As reference, for a couple of D
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_hdmi.c | 68 --
As we may query the edid multiple times following a detect, record the
EDID found during output discovery and reuse it. This is a separate
issue from caching the output EDID across detection cycles.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dp.c | 95 ---
On Mon, Aug 11, 2014 at 04:44:23PM -0300, Paulo Zanoni wrote:
> 2014-06-30 7:10 GMT-03:00 Jani Nikula :
> > On Thu, 26 Jun 2014, Rodrigo Vivi wrote:
> >> I'm sure this might affect Wayne, so, cc'ing him here.
> >>
> >> from my point of view this is right so:
> >> Reviewed-by: Rodrigo Vivi
> >
> >
On Mon, Aug 11, 2014 at 02:57:44PM -0300, Paulo Zanoni wrote:
> 2014-08-11 11:42 GMT-03:00 Ville Syrjälä :
> > On Mon, Aug 11, 2014 at 11:29:21AM -0300, Paulo Zanoni wrote:
> >> 2014-08-11 8:32 GMT-03:00 Ville Syrjälä :
> >> > On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
> >> >> Fr
On Tue, Aug 12, 2014 at 07:39:24AM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 03:33:02PM -0700, clinton.a.tay...@intel.com wrote:
> > From: Clint Taylor
> >
> > Intel HDMI does not correctly configure pixel replicated HDMI modes
> > 480i and 576i. Remove support for these modes until DR
70 matches
Mail list logo
