On Sat, Jun 7, 2014 at 4:08 PM, Chris Wilson 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 wrote:
>> > Hi,
>> >
>> > I am still playing with DRI3... beyond this I saw that TearFree option
>> > can be explicitly set ("sna: Allo
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 rou
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.
Att
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 connectio
On Sun, Jun 8, 2014 at 1:11 AM, 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
On Mon 2014-06-09 11:25:20, Daniel Vetter wrote:
> On Sun, Jun 8, 2014 at 1:11 AM, 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 bisec
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'r
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
---
configure.ac | 6 ++
tools/quick_dump/Makefile.am | 9 +
2 files changed, 7 insertions(+), 8 deletions(-)
diff
Fix include paths and references to missing files.
Signed-off-by: Thomas Wood
---
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 ++--
tools/null_state_gen/intel_renderstate_gen8.c |
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
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
previ
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 d
On Thu, Jun 05, 2014 at 02:28:17PM -0700, Rodrigo Vivi wrote:
> Adding missing Display mmio reg offset.
>
> Credits-to: Laws, Philip
> Cc: He, Shuang
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> 1 file changed, 1 insertion(+), 1
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
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
bef
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 dis
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. Prete
From: Ville Syrjälä
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 intel_sdvo_get_config().
To avoid
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
signature.asc
Description: OpenPGP digital signature
__
DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.
Signed-off-by: Damien Lespiau
---
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
--- a/include/uapi/drm/d
It was reported that this comment was confusing, and indeed it is.
Signed-off-by: Damien Lespiau
---
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 ff57f07..eacd063 100644
---
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
---
drivers/gpu/drm/armada/armada_drv.c | 2 +-
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 ioct
On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau 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().
>
> Signed-off-by: D
On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau wrote:
> DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.
>
> Signed-off-by: Damien Lespiau
Reviewed-by: Alex Deucher
> ---
> include/uapi/drm/drm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/incl
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 exp
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 regr
On Wed, Jun 04, 2014 at 03:24:13PM -0300, Paulo Zanoni wrote:
> 2014-05-22 11:48 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > When we switch between one active pipe and multiple active pipes, the
> > display FIFO gets repartitioned. Disable the LP1+ waterwarks while that
> > is happening to make s
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 :
> > > From: Ville Syrjälä
> > >
> > > We need to perform watermark programming before and after changing the
> > > plane configuration. A
From: Tom O'Rourke
In gen8_enable_rps, don't write CHV registers unless IS_CHERRYVIEW.
Signed-off-by: Tom O'Rourke
---
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 b/drivers/gpu/drm/i915/intel_pm.c
On Mon, Jun 09, 2014 at 10:06:49AM -0700, Tom.O'rou...@intel.com wrote:
> From: Tom O'Rourke
>
> In gen8_enable_rps, don't write CHV registers unless IS_CHERRYVIEW.
>
> Signed-off-by: Tom O'Rourke
A lovely catch.
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_pm
On Fri, 06 Jun 2014, Chris Wilson 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 deadlocks in multi-head s
On Tue, Jun 03, 2014 at 07:47:11PM -0300, Paulo Zanoni wrote:
> 2014-05-22 11:48 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Switch the code over to using the two phase watermark update. The steps
> > generally follow this pattern:
> >
> > 1. Calculate new plane parameters for changed planes
> >
On Mon, Jun 09, 2014 at 09:12:18PM +0300, Jani Nikula wrote:
> On Fri, 06 Jun 2014, Chris Wilson 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 pow
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
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 (supporter:INTEL DRM DRIVERS...)
Cc: Jani Nikula (supporter:INTEL DRM DRIVERS...)
Signed-off-by: Sagar Kamble
---
dri
From: Sagar Kamble
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 (supporter:INTEL DRM DRIVERS...)
Cc: Jani Nikula (supporter:INTEL DRM DRIVERS...)
Signed
From: Sagar Kamble
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 during display well power gat
On Mon, 09 Jun 2014, Ville Syrjälä wrote:
> On Mon, Jun 09, 2014 at 09:12:18PM +0300, Jani Nikula wrote:
>> On Fri, 06 Jun 2014, Chris Wilson 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
From: Ville Syrjälä
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 the ns2501 driver, so let's ju
>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
Am 09.06.2014 21:46, schrieb ville.syrj...@linux.intel.com:
From: Ville Syrjälä
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 before. Now I only need to
swi
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 DV
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 va_ar
+Ben Widawsky & Daniel Vetter
On 06/09/2014 03:38 PM, Lewis Toohey wrote:
> On 3 June 2014 02:22, Aaron Lu 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 re
On Mon, Jun 09, 2014 at 02:39:51PM +0100, Damien Lespiau wrote:
> It was reported that this comment was confusing, and indeed it is.
>
> Signed-off-by: Damien Lespiau
> ---
> include/uapi/drm/i915_drm.h | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/uap
47 matches
Mail list logo