Thomas found that his machine would deadlock reloading the i915.ko
module after resume. He identified that this was caused by the
reacquisition of the connection mutex inside intel_enable_pipe_a()
during the CRTC sanitization routine. This will only affect machines
that quirk PIPE A, i.e. the
On Sat, Jun 7, 2014 at 4:08 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Sat, Jun 07, 2014 at 02:00:46PM +0200, Sedat Dilek wrote:
On Sat, Jun 7, 2014 at 1:47 PM, Sedat Dilek sedat.di...@gmail.com wrote:
Hi,
I am still playing with DRI3... beyond this I saw that TearFree option
On Mon, Jun 09, 2014 at 07:47:10AM +0100, Chris Wilson wrote:
Thomas found that his machine would deadlock reloading the i915.ko
module after resume. He identified that this was caused by the
reacquisition of the connection mutex inside intel_enable_pipe_a()
during the CRTC sanitization
Why need add rc6_residency_counter subtest case:
RC6 feature support residency counter,from power consumption aspect,
the counter closer to 1,the better.If the counter is 0.9, the residency
is not good and will impact power consumption value, if the counter is 1,
sysfs file is inaccurate.
On Mon, Jun 09, 2014 at 11:30:26AM +0300, Ville Syrjälä wrote:
On Mon, Jun 09, 2014 at 07:47:10AM +0100, Chris Wilson wrote:
Thomas found that his machine would deadlock reloading the i915.ko
module after resume. He identified that this was caused by the
reacquisition of the connection
On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek pa...@ucw.cz wrote:
Strange. It seems 3.15 with the patch reverted only boots in 30% or so
cases... And I've seen resume failure, too, so maybe I was just lucky
that it worked for a while.
git bisect really likes 25f397a429dfa43f22c278d0119a60 -
On Mon 2014-06-09 11:25:20, Daniel Vetter wrote:
On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek pa...@ucw.cz wrote:
Strange. It seems 3.15 with the patch reverted only boots in 30% or so
cases... And I've seen resume failure, too, so maybe I was just lucky
that it worked for a while.
git
Hi Ville, dear intel experts,
without the deadlock in i915, I had at least a partial success in
restoring the video on the Fujitsu S6010.
Apparently, the bios does not re-initialize the 830MG registers, nor the
registers of the ns2501 DVO.
Instead, the 830MG is configured in a 640x480 mode (no
On Mon, 9 Jun 2014, Pavel Machek wrote:
Strange. It seems 3.15 with the patch reverted only boots in 30% or so
cases... And I've seen resume failure, too, so maybe I was just lucky
that it worked for a while.
git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
Each architecture file contains a list of the text files it requires, so
use this to add to the list of files to distribute.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
configure.ac | 6 ++
tools/quick_dump/Makefile.am | 9 +
2 files changed, 7 insertions(+),
Fix include paths and references to missing files.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
tools/null_state_gen/Makefile.am | 3 +++
tools/null_state_gen/intel_renderstate_gen6.c | 4 ++--
tools/null_state_gen/intel_renderstate_gen7.c | 4 ++--
On Mon, Jun 09, 2014 at 12:57:46PM +0200, Thomas Richter wrote:
Hi Ville, dear intel experts,
without the deadlock in i915, I had at least a partial success in
restoring the video on the Fujitsu S6010.
Apparently, the bios does not re-initialize the 830MG registers, nor the
registers of
Am 09.06.2014 13:08, schrieb Ville Syrjälä
No, we do restore the mode you were using before suspend.
Are you still using vbetool? That would explain why things go bad since
vbetool will clobber whatever i915 already did.
No, vbetool is out of the equation (see the script attached to the
On Mon, Jun 09, 2014 at 01:19:46PM +0200, Thomas Richter wrote:
Am 09.06.2014 13:08, schrieb Ville Syrjälä
No, we do restore the mode you were using before suspend.
Are you still using vbetool? That would explain why things go bad since
vbetool will clobber whatever i915 already did.
On Thu, Jun 05, 2014 at 02:28:17PM -0700, Rodrigo Vivi wrote:
Adding missing Display mmio reg offset.
Credits-to: Laws, Philip philip.l...@intel.com
Cc: He, Shuang shuang...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Dear Intel graphics folks,
Am Freitag, den 30.05.2014, 14:47 +0200 schrieb Paul Menzel:
Am Freitag, den 30.05.2014, 13:45 +0200 schrieb Paul Menzel:
since commit 17fec8a0 [1]
drm/i915: Use Graphics Base of Stolen Memory on all gen3+
Linux reads the register BSM (Base of
Am 09.06.2014 13:31, schrieb Ville Syrjälä:
So now you're using acpi_sleep=s3_bios, or nothing?
Ok, tried now with acpi_sleep=s3. Unfortunately, this hangs the machine
completely during resume, I cannot even ping it.
Then, I tried the same trick again, namely unloading the i915 module
On Fri, May 30, 2014 at 05:16:34PM +0100, Chris Wilson wrote:
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to
On Fri, May 30, 2014 at 05:16:35PM +0100, Chris Wilson wrote:
If we successfully confuse the hardware, and cause it to drop a queued
pageflip, we wait for 60s and issue a warning before continuing on with
the modeset. However, this leaves the pending pageflip still stuck
indefinitely. Pretend
From: Ville Syrjälä ville.syrj...@linux.intel.com
On certain platforms pixel_multiplier is read out in
.get_pipe_config(), but it also gets used to calculate the
pixel clock in intel_sdvo_get_config(). If the pipe is disable
but some SDVO outputs are active, we may end up dividing by zero
in
Hi,
On 06/06/14 18:20, Daniel Vetter wrote:
Tomi/Jean can you please ack merging this through drm-intel trees? It
just exports the vga and dummy consoles so that i915 can do what it
needs to do.
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Tomi
signature.asc
Description: OpenPGP
DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/uapi/drm/drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 9abbeb9..b0b8556 100644
It was reported that this comment was confusing, and indeed it is.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/uapi/drm/i915_drm.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index
I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
in a few places. I suspect its usage has been spread by copy paste
rather than anything else.
Let's just remove it for plain ARRAY_SIZE().
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
It was reported a long time ago the various comments about the DRM/driver
specific ioctl split were confusing. So tried to fix that.
Patch #1 is a bonus patch that removes DRM_ARRAY_SIZE().
--
Damien
Damien Lespiau (3):
drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()
drm: Driver-specific
On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau damien.lesp...@intel.com wrote:
I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
in a few places. I suspect its usage has been spread by copy paste
rather than anything else.
Let's just remove it for plain ARRAY_SIZE().
On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau damien.lesp...@intel.com wrote:
DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
include/uapi/drm/drm.h | 2 +-
On Wed, Jun 04, 2014 at 06:10:44PM +0200, Daniel Vetter wrote:
On Wed, Jun 04, 2014 at 11:01:01AM -0300, Paulo Zanoni wrote:
This function is only called at init/resume. It populates the software
state with something that matches the current hardware state. I guess
a comment explaning
For reasons I can't claim to fully understand gen4 seems to require
backlight duty cycle setting after the backlight has been enabled, or
else black screen follows. I don't have documentation for the correct
sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1.
This fixes a
On Wed, Jun 04, 2014 at 03:24:13PM -0300, Paulo Zanoni wrote:
2014-05-22 11:48 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When we switch between one active pipe and multiple active pipes, the
display FIFO gets repartitioned. Disable the
On Wed, Jun 04, 2014 at 06:22:13PM +0200, Daniel Vetter wrote:
On Tue, Jun 03, 2014 at 05:51:01PM -0300, Paulo Zanoni wrote:
2014-05-22 11:48 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We need to perform watermark programming before and
From: Tom O'Rourke Tom.O'rou...@intel.com
In gen8_enable_rps, don't write CHV registers unless IS_CHERRYVIEW.
Signed-off-by: Tom O'Rourke Tom.O'rou...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On Mon, Jun 09, 2014 at 10:06:49AM -0700, Tom.O'rou...@intel.com wrote:
From: Tom O'Rourke Tom.O'rou...@intel.com
In gen8_enable_rps, don't write CHV registers unless IS_CHERRYVIEW.
Signed-off-by: Tom O'Rourke Tom.O'rou...@intel.com
A lovely catch.
Reviewed-by: Damien Lespiau
On Fri, 06 Jun 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
It causes black screen on bootup and is approximately 100x slower than
running with FBC disabled, so the GPU runs at a high frequency for much
longer - completely contrary to the power saving claims. It also still
has mutex
On Tue, Jun 03, 2014 at 07:47:11PM -0300, Paulo Zanoni wrote:
2014-05-22 11:48 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Switch the code over to using the two phase watermark update. The steps
generally follow this pattern:
1.
On Mon, Jun 09, 2014 at 09:12:18PM +0300, Jani Nikula wrote:
On Fri, 06 Jun 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
It causes black screen on bootup and is approximately 100x slower than
running with FBC disabled, so the GPU runs at a high frequency for much
longer - completely
Hi Ville, dear Intel experts,
more on the partial resume from suspend for the S6010. It seems that the
culprit is really the lack of a proper
initialization of the DVO. The minimum sequence to restore the display
does not require to modify the 830 registers
directly, but rather needs to setup
From: Sagar Kamble sagar.a.kam...@intel.com
Display power island is on during boot, we have one count for it
once this power gates, we do a put making sure runtime_suspend is
called
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM DRIVERS...)
Cc: Jani Nikula
From: Sagar Kamble sagar.a.kam...@intel.com
To do a platform wide S0i3 transition, Gfx is required to go
to D3_hot state. pci_save_state and pci_restore_state needed to avoid ring
hangs across D3_hot transitions.
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM DRIVERS...)
Cc: Jani
From: Sagar Kamble sagar.a.kam...@intel.com
With these patches runtime_suspend is triggered by updating runtime pm
usage count when display well is power gated and pci state is set to D3 hot
in runtime_suspend and set to D0 in runtime_resume.
Sagar Kamble (2):
drm/i915: do runtime_get/put
On Mon, 09 Jun 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Mon, Jun 09, 2014 at 09:12:18PM +0300, Jani Nikula wrote:
On Fri, 06 Jun 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
It causes black screen on bootup and is approximately 100x slower than
running with FBC
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: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, June 03, 2014 12:38 AM
To: O'Rourke, Tom
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Ben Widawsky; Kristen
Carlson Accardi
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6
Am 09.06.2014 21:46, schrieb ville.syrj...@linux.intel.com:
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.
Thanks, this *almost* works, much better than
Hi Ville,
thanks for the latest patch. As said, the screen did not come back quite
correctly. I checked the register values
again, and I am sorry to say that I was wrong - register values do
differ. Apparently, the code configures now
the wrong pipe to generate output to the DVO and thus the
Hi all,
It is time for a new i-g-t release. Thank you all for let everything ready
for a smoth release.
Here goes a new i-g-t quarterly release with the following changes:
- Piles of API documentation for the core i-g-t testing libraries.
- Improved igt loggin, now also with igt_vlog (for
+Ben Widawsky Daniel Vetter
On 06/09/2014 03:38 PM, Lewis Toohey wrote:
On 3 June 2014 02:22, Aaron Lu aaron...@intel.com wrote:
On 05/30/2014 09:12 PM, Lewis Toohey wrote:
Aaron
I am in the process of performing this bisection, however, I need a
bit of advice.
I have got a mix of
47 matches
Mail list logo