Regards
Shashank
On 8/13/2014 5:44 PM, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 06:08:20PM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
The current hdmi_detect() function is getting called from
many places, few of these are:
1. HDMI hot plug
On Wed, Aug 13, 2014 at 05:50:38PM +0300, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
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
On Wed, Aug 13, 2014 at 03:40:24PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 02:09:22PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 03:04:02PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 02:46:53PM
On Thu, Aug 14, 2014 at 8:15 AM, Sharma, Shashank
shashank.sha...@intel.com wrote:
Can you please point out what is it, that's unexpected to you ?
I think this is what we (you Shobhit) agreed on:
1. Timeout based EDID caching
2. Use of cached EDID within caching duration
3. Separate path for
On Thu, Aug 14, 2014 at 8:54 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
I disaggree with the conversion of the BUG_ON though, a WARN there is
going to screw up unpredictably (well, a hard hang without any output
is the predictable outcome). I'd like to have asserts for things that
could
From: Akash Goel akash.g...@intel.com
This patch removes the check for change in pitch of frame buffer
across page flips. Since there is a support for MMIO based page
flips, we can update the plane registers to update the
FB pitch accordingly the offsets in LINOFF/TILEOFF registers.
The plane
From: Akash Goel akash.g...@intel.com
This patch changes the return type of panel fitter configuration
functions from 'void', so that an error could be returned back to
User space, either during the modeset time or when some property
is being set, if the configuation is not valid.
Signed-off-by:
From: Akash Goel akash.g...@intel.com
This patch changes the return type of 'crtc_restore_mode'
function from 'void', so that an error could be returned back to
User space, from the set property ioctl call, if the configuation
is not valid.
Signed-off-by: Akash Goel akash.g...@intel.com
From: Akash Goel akash.g...@intel.com
Updated drm documentation to include description of
Crtc size property
Signed-off-by: Akash Goel akash.g...@intel.com
Signed-off-by: Pallavi Gpallav...@intel.com
---
Documentation/DocBook/drm.tmpl | 13 +++--
1 file changed, 11 insertions(+), 2
From: Akash Goel akash.g...@intel.com
This patch adds a new drm crtc property for varying the Pipe Src size
or the Panel fitter input size. Pipe Src controls the size that is
scaled from.
This will allow to dynamically flip the frame buffers
of different resolutions.
For this Driver internally
From: Akash Goel akash.g...@intel.com
Added a new drm crtc property which provides control
to vary the Pipe Src or Crtc size.
With this, User can flip the frame buffers of resolution, which
is different from the currently selected mode. For this Driver will
appropriately enable the Panel fitter
From: Akash Goel akash.g...@intel.com
This patch adds a check on the Max down scale ratio supported by the
Panel fitter. If Source width/height is too big, that the downscale
ratio of more than 1.125 is needed to fit into the Output window,
then that configuration will be rejected.
Hi Daniel,
I can do all the changes accordingly and upload a new patch.
This is what I am going to do:
1. Change the EDID caching time to a second from a minute (probably
there was a miscommunication).
2. Remove the gen_check
3. Use the connector-edid pointer to cache EDID.
I have only few
On Thu, 14 Aug 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Aug 14, 2014 at 8:54 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I disaggree with the conversion of the BUG_ON though, a WARN there is
going to screw up unpredictably (well, a hard hang without any output
is the
Chris Wilson ch...@chris-wilson.co.uk writes:
On Wed, Aug 13, 2014 at 05:50:38PM +0300, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
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
On Wed, Aug 13, 2014 at 10:58:54AM +0100, Chris Wilson wrote:
If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE
will silently fail. This leads to an indefinite hang as WAITACTIVE never
returns causing lockups on boot. This issue becomes apparent when the
kernel driver
On Wed, 2014-08-13 at 23:07 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
With this change, intel_runtime_suspend and intel_runtime_resume functions
become completely platform agnostic. Platform specific suspend/resume
changes are moved to
On Thu, Aug 14, 2014 at 02:53:44PM +0530, Sharma, Shashank wrote:
Hi Daniel,
I can do all the changes accordingly and upload a new patch.
This is what I am going to do:
1. Change the EDID caching time to a second from a minute (probably there
was a miscommunication).
2. Remove the
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
v2: fix build error
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Sourab Gupta sourab.gu...@intel.com
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
Also there is an interface available, which provides information
about the several memory related attributes of every
On Thu, 14 Aug 2014, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
Also there is an interface available, which provides information
On Thu, Aug 14, 2014 at 02:51:15PM +0300, Imre Deak wrote:
On Wed, 2014-08-13 at 23:07 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
With this change, intel_runtime_suspend and intel_runtime_resume functions
become completely platform agnostic.
On Thu, 2014-08-14 at 16:50 +0300, Jani Nikula wrote:
On Thu, 14 Aug 2014, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
Also
On Thu, Aug 14, 2014 at 01:07:06PM +0300, Jani Nikula wrote:
On Thu, 14 Aug 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Aug 14, 2014 at 8:54 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I disaggree with the conversion of the BUG_ON though, a WARN there is
going to screw up
On Thu, Aug 14, 2014 at 11:36:11AM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 10:58:54AM +0100, Chris Wilson wrote:
If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE
will silently fail. This leads to an indefinite hang as WAITACTIVE never
returns causing
On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
This sounds more like gpu reset should be a bit more careful (even more
careful than we already are compared to earlier kernels) with making
On Thu, Aug 14, 2014 at 04:50:19PM +0300, Jani Nikula wrote:
On Thu, 14 Aug 2014, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
On Thu, Aug 14, 2014 at 02:54:25PM +0530, akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
This patch removes the check for change in pitch of frame buffer
across page flips. Since there is a support for MMIO based page
flips, we can update the plane registers to update the
On Tue, 12 Aug 2014, Paulo Zanoni przan...@gmail.com wrote:
2014-08-12 13:39 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the cursor gets fully clipped when enabling it on a disabled
crtc via setplane. This will prevent the lower level
On Mon, 11 Aug 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Aug 11, 2014 at 01:15:35PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_enable_pipe_a() gets called with all the modeset locks already
held (by drm_modeset_lock_all()), so
On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
+ /* Check if the current FB is compatible with new requested
+Pipesrc values by the User */
+ if (new_width fb-width ||
+
On Thu, Aug 14, 2014 at 04:23:16PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
This sounds more like gpu reset should be a bit more careful (even more
Chris Wilson ch...@chris-wilson.co.uk writes:
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
On Thu, Aug 14, 2014 at 05:45:59PM +0300, Ville Syrjälä wrote:
On Thu, Aug 14, 2014 at 04:23:16PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
This
On Thu, Aug 14, 2014 at 01:18:46PM +0300, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
On Wed, Aug 13, 2014 at 05:50:38PM +0300, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
The current error state harks back to the era of just a single VM.
From: Paulo Zanoni paulo.r.zan...@intel.com
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 the objects, and to
change the fences. The pin functions are the ideal places for
On Thu, Aug 14, 2014 at 04:42:01PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
+ /* Check if the current FB is compatible with new requested
+ Pipesrc values by the User */
+
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, August 13, 2014 4:16 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context and
Daniel Vetter dan...@ffwll.ch writes:
On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
This sounds more like gpu reset should be a bit more careful (even more
careful than we already are
On Thu, Aug 14, 2014 at 06:06:58PM +0300, Ville Syrjälä wrote:
On Thu, Aug 14, 2014 at 04:42:01PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
+ /* Check if the current FB is compatible with
On Thu, Aug 14, 2014 at 05:32:28PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 03:09:45PM +, Daniel, Thomas wrote:
When it comes to the execlist submission (actually as early as the execlist
request queueing), the engine and context are indeed used and required.
Add a function to restore the previous VT mode after
igt_set_vt_graphics_mode is called.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
lib/igt_kms.c | 27 +--
lib/igt_kms.h | 1 +
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/lib/igt_kms.c
The following patches allow the VT mode to be reset and then add a check in
kms_rotation_crc to ensure the rotation has been restored. The test in
kms_rotation_crc uses CRC values to determine this rather than just reading the
property since the original issue exposed an inconsistency between the
Make sure the rotation is reset after the VT mode is restored by
collecting the unrotated CRC and comparing with the CRC value after VT mode
has been restored. The CRC is used to ensure the hardware state is checked,
rather than any software state.
References:
On Thu, Aug 14, 2014 at 05:26:27PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 06:06:58PM +0300, Ville Syrjälä wrote:
On Thu, Aug 14, 2014 at 04:42:01PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
From: Akash Goel
Mika Kuoppala mika.kuopp...@linux.intel.com writes:
Daniel Vetter dan...@ffwll.ch writes:
On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
This sounds more like gpu reset should be a bit
On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote:
Make sure plane rotation is reset correctly when restoring the fbdev
configuration by using drm_mode_plane_set_obj_prop. This calls the
driver's set_property callback and ensures the rotation is actually
changed.
Bugzilla:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Thursday, August 14, 2014 4:37 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context and an
On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
My quick grep audit tells me the viewport check and
drm_primary_helper_update() are the only places in the core that care.
The latter is rather dubious anyway since the clipping should be done
against the
On Thu, Aug 14, 2014 at 03:56:20PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Thursday, August 14, 2014 4:37 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
From: Oscar Mateo oscar.ma...@intel.com
The execlist patches have a bit a convoluted and long history and due
to that have the actual submission still misplaced deeply burried in
the low-level ringbuffer handling code. This design goes back to the
legacy ringbuffer code with its tricky lazy
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Thursday, August 14, 2014 5:28 PM
To: Intel Graphics Development
Cc: Mateo Lozano, Oscar; Daniel, Thomas; Daniel Vetter
Subject: [PATCH] drm/i915: Add temporary ring-ctx backpointer
From: Oscar Mateo
On Thu, Aug 14, 2014 at 06:07:44PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
My quick grep audit tells me the viewport check and
drm_primary_helper_update() are the only places in the core that care.
The latter is rather
From: Arun Siluvery arun.siluv...@linux.intel.com
The workarounds at the moment are initialized in init_clock_gating() but
they are lost during reset, suspend/resume; this patch moves workarounds
that are part of register state context to render ring init fn otherwise
default context ends up with
From: Arun Siluvery arun.siluv...@linux.intel.com
This patch adds a new test to verify applied workarounds before
and after an operation such as gpu reset, suspend/resume.
It is a simple test which captures w/a state at the beginning and
compares their status with the state after the operation.
2014-08-14 13:51 GMT-03:00 arun.siluv...@linux.intel.com:
From: Arun Siluvery arun.siluv...@linux.intel.com
This patch adds a new test to verify applied workarounds before
and after an operation such as gpu reset, suspend/resume.
It is a simple test which captures w/a state at the beginning
On Thu, Aug 14, 2014 at 6:45 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Thu, Aug 14, 2014 at 06:07:44PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
My quick grep audit tells me the viewport check and
On Thu, Aug 14, 2014 at 07:36:13PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 6:45 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Thu, Aug 14, 2014 at 06:07:44PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
ville.syrj...@linux.intel.com
From: Clint Taylor clinton.a.tay...@intel.com
Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI
On Thu, Aug 14, 2014 at 7:58 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
Sure but the user can supply any mode, doesn't have to be on any list.
And the only sane rule for the frobbing would be that you can (slightly)
reduce hdisp/vdisp but never expand them so that there will never
On Thu, Aug 14, 2014 at 11:09:25AM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor clinton.a.tay...@intel.com
Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does
On Thu, Aug 14, 2014 at 08:33:23PM +0200, Daniel Vetter wrote:
On Thu, Aug 14, 2014 at 7:58 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
Sure but the user can supply any mode, doesn't have to be on any list.
And the only sane rule for the frobbing would be that you can (slightly)
From: Ville Syrjälä ville.syrj...@linux.intel.com
We changed to an interrupt based vblank wait (as opposed to polling)
in:
commit 44bd93a3d367913d883be6abba9a6e51a53c4e90
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Jul 25 23:36:44 2014 +0200
drm/i915: Use generic vblank wait
On Thu, Aug 14, 2014 at 10:04:37PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We changed to an interrupt based vblank wait (as opposed to polling)
in:
commit 44bd93a3d367913d883be6abba9a6e51a53c4e90
Author: Daniel Vetter
On Thu, Aug 14, 2014 at 05:51:48PM +0300, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
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
On Mon, 11 Aug 2014 23:33:57 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Aug 11, 2014 at 11:08:38AM -0700, Daisy Sun wrote:
BDW supports GT C0 residency reporting in constant time unit. Driver
calculates GT utilization based on C0 residency and adjusts RP
frequency up/down
Tested-by and Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
On Fri, Aug 8, 2014 at 11:27 AM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We treat other plane updates in the same fashion. Spotted because
Rodrigo kept reporting a bug in the PSR code where the frontbuffer was
eternally stuck
Hi Jani,
On 13-8-2014 3:43, Jani Nikula wrote:
On Wed, 23 Jul 2014, Hans de Goede hdego...@redhat.com wrote:
On 07/22/2014 08:52 AM, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 8:42 AM, Hans de Goede hdego...@redhat.com wrote:
snip
Also please grab latest intel-gpu-tools and record a
On Wed, Aug 13, 2014 at 05:30:07PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 10:25 PM
To:
2014-08-14 12:06 GMT-03:00 Paulo Zanoni przan...@gmail.com:
From: Paulo Zanoni paulo.r.zan...@intel.com
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 the objects, and to
On Thu, Jul 24, 2014 at 05:04:38PM +0100, Thomas Daniel wrote:
From: Michel Thierry michel.thie...@intel.com
Context switch (and execlist submission) should happen only when
other contexts are not active, otherwise pre-emption occurs.
To assure this, we place context switch requests in a
On Thu, Jul 24, 2014 at 05:04:38PM +0100, Thomas Daniel wrote:
From: Michel Thierry michel.thie...@intel.com
Context switch (and execlist submission) should happen only when
other contexts are not active, otherwise pre-emption occurs.
To assure this, we place context switch requests in a
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to
On Thu, Jul 24, 2014 at 05:04:40PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
In the current Execlists feeding mechanism, full preemption is not
supported yet: only lite-restores are allowed (this is: the GPU
simply samples a new tail pointer for the context
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to
On Thu, Jul 24, 2014 at 05:04:41PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see
gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking
for
contexts to squash
On Thu, Aug 14, 2014 at 12:49:06PM -0700, Rodrigo Vivi wrote:
Tested-by and Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Thanks a lot for testing and review, happy that we've tracked this one
down. Patch merged to dinq (since psr is unfortunately already disabled
again in 3.17 upstream).
From: Ville Syrjälä ville.syrj...@linux.intel.com
Thomas asked me to repost my 830/ns2501 patches. So here they are. I added
a few more patches (trickle feed and unused ring init) to fix some post-resume
issues. The primary plane rmw elimination patches and some locking/load detect
fixes already
From: Ville Syrjälä ville.syrj...@linux.intel.com
gen2/3 platforms have a boatload of rings we're not using. On my 830
the BIOS/hw can leave some of those active after resume which will
prevent c3 entry. The ring is apparently considered active whenever
head != tail even if the ring is disabled.
From: Ville Syrjälä ville.syrj...@linux.intel.com
The max watermark value for gen2 planes B and C is 0x1f, instead of
the 0x3f that plane A uses.
Also check against the max even if the pipe is disabled since the
FIFO size exceeds the plane B and C max watermark value.
Signed-off-by: Ville
From: Ville Syrjälä ville.syrj...@linux.intel.com
My 830 is unhappy with trickle feed enabled. The symptom is that
the image on the screen shifts a bit to right occasionally.
The BIOS initially disables trickle feed, but it gets reset during
suspend, so we need to re-disable it ourselves. Juse
From: Ville Syrjälä ville.syrj...@linux.intel.com
On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead
of DVOC.
FIXME: Maybe need to dig out the correct DVO port from VBT
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
From: Ville Syrjälä ville.syrj...@linux.intel.com
Just pass the intel_crtc around instead of dev_priv+pipe.
Also make intel_wait_for_pipe_off() static since it's only used in
intel_display.c.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c |
From: Ville Syrjälä ville.syrj...@linux.intel.com
Calling the mode_set hook on DPMS changes doesn't seem to be necessary
for ns2501. Just drop it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dvo.c | 4
1 file changed, 4 deletions(-)
diff --git
From: Ville Syrjälä ville.syrj...@linux.intel.com
To more closely match the IEGD ns2501 driver behaviour, call the
mode_set hook while the DVO port is still disabled, then enable the DVO
port, and finally call the dpms hook.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
Disable double wide even if the pipe quirk compels us to leave the
pipe running. Double wide has certain implications for the plane
assignments so best keep it off.
Also helps resuming from S3 on the Fujitsu-Siemens Lifebook S6010
when double
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/dvo_ns2501.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index
From: Ville Syrjälä ville.syrj...@linux.intel.com
In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Looks like IEGD does a one time init of these three registers. We don't
have a good one time init place in
From: Ville Syrjälä ville.syrj...@linux.intel.com
Try to use the same programming sequence as used by the IEGD driver.
Also shovel the magic register values into a big static const array.
The register values are actually the based on what the BIOS programs
on the Fujitsu-Siemens Lifebook S6010.
From: Ville Syrjälä ville.syrj...@linux.intel.com
The spec says:
For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata,
GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31
(DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in
both the DPLL A Control Register
From: Ville Syrjälä ville.syrj...@linux.intel.com
830M has problems when some of the pipes are disabled. Namely if a
plane, DVO port etc. is currently assigned to a disabled pipe, it
can't moved to the other pipe until the current pipe is also enabled.
To keep things simple just leave both pipes
From: Ville Syrjälä ville.syrj...@linux.intel.com
830 really does want the pipe A quirk. The planes and ports don't
react to any register writes unless the pipe currently attached
to them is running, so it's impossible to move them to the other
pipe unless both pipes are running.
Also it's
From: Ville Syrjälä ville.syrj...@linux.intel.com
The vbt on my Fujitsu-Siemens Lifebook S6010 provides two 800x600 modes,
60Hz and 56Hz. The magic register values we have correspond to the 60Hz
mode, and as I don't know how one would trick the VGA BIOS to set up
the 56Hz mode we can't get the
From: Ville Syrjälä ville.syrj...@linux.intel.com
My Fujistsu-Siemens Lifebook S6010 doesn't like to resume from
S3 unless VGACNTR has been restore to the original value. The BIOS
value in this case was 0x0124008E. Setting the VGA disable bit
doesn't interfere with the S3 resume fortunately.
From: Clint Taylor clinton.a.tay...@intel.com
Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
Greetings,
I am submitting the below changes to i915 Gfx driver to support resume time
Responsiveness measurements. These changes parallel the work already done in
the IVB Windows Gfx driver. These changes in addition to other OTS scripts
(suspend_resume) allow tracking of what is referred
99 matches
Mail list logo
