Re: [Intel-gfx] [PATCH xf86-video-intel] Add OpenBSD backlight control implementation

> Date: Fri, 22 Mar 2013 11:30:45 + > From: Chris Wilson > > On Fri, Mar 22, 2013 at 11:23:11AM +0100, Mark Kettenis wrote: > > From: Mark Kettenis > > Thank you for the patch, I presume it works ;-) Pushed, It actually does work ;). Thanks Chris!

Re: [Intel-gfx] [PATCH 6/6] drm/i915: More HSW PM clean up.

On Fri, Mar 22, 2013 at 06:13:50PM -0300, Rodrigo Vivi wrote: > > > > On Wed, Feb 27, 2013 at 10:46 AM, Paulo Zanoni wrote: > Hi > > 2013/2/25 Rodrigo Vivi : > > This is the last cleaning up patch for HSW, letting render standby > > programming sequence like the documented

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Use BUG() in a case of a programming error

Hi 2013/3/7 Damien Lespiau : > The port number should always be correctly set. Do the same thing as the > switch above and use BUG() to signal that branch is not supposed to be > taken. > > Signed-off-by: Damien Lespiau Reviewed-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_dp.c |3

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Rename intel_ddi_enable_pipe_func() to transcoder_func()

Hi 2013/3/7 Damien Lespiau : > We are really talking about the transcoder function here and the disable > version uses trancoder in its name already, so let's try to be > consistent. > > Signed-off-by: Damien Lespiau Reviewed-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_ddi.c |

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Cleanup if the EDP transcoder has a bobug input value

Hi 2013/3/7 Damien Lespiau : > In the case where the hardware has been wrongly programmed and the EDP > TRANS_DDI_FUNC_CTL register has a bogus value in its EDP Input field, we > were using the pipe variable uninitialized. > > In this case, shutdown the transcoder. It will be programmed correctly

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Error out if we are trying to use VGA with SPLL already in use

Hi 2013/3/8 Ben Widawsky : > On Thu, Mar 07, 2013 at 03:30:25PM +, Damien Lespiau wrote: >> Our static analysis tool noticed that 'reg' could be used uninitialized if >> we are trying to get a PLL to drive VGA and SPLL is already in use >> (plls->spll_refcoung != 0). This was also reported by

Re: [Intel-gfx] [PATCH 6/6] drm/i915: More HSW PM clean up.

On Wed, Feb 27, 2013 at 10:46 AM, Paulo Zanoni wrote: > Hi > > 2013/2/25 Rodrigo Vivi : > > This is the last cleaning up patch for HSW, letting render standby > > programming sequence like the documented one at HSW PM programing guide. > > > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu

[Intel-gfx] [PATCH] drm/i915: set dummy page for stolen objects

This is needed since currently sg_for_each_page assumes that we have a valid page in each sg item. It is only a real problem for CONFIG_SPARSEMEM where the page is dereferenced, in other cases the iterator works ok with an invalid page pointer. We can remove this workaround when we have fixed sg_p

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Warn if a pipe is enabled with a bogus port

Hi 2013/3/7 Damien Lespiau : > If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect > port, we are currently trying to read PORT_CLK_SEL(port) with an > initialized value. s/initialized/uninitialized/g > > Handle that case by returning PORT_CLK_SEL_NONE and warning about it. > > S

Re: [Intel-gfx] Screen blanking when copying files to USB/SD-Card ??

I have created the /sys/kernel/dri/0/i915_error_state dump, it's there: http://dl.free.fr/hSD3OtrII It is 9 Mo gzipped, 52 Mo ungzipped, much too much info I guess, but I don't know what to edit out, sorry for the garbage. ​ ___ Intel-gfx mailing list I

Re: [Intel-gfx] [PATCH 2/7] drm/i915: only disable DDI sound if intel_crtc->eld_vld

On Fri, Mar 22, 2013 at 02:11:43PM -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > We already have the same check on intel_enable_ddi. This patch > prevents "unclaimed register" messages when the power well is > disabled. > > V2: Reset intel_crtc->eld_vld to false after the mode_set function

[Intel-gfx] [PATCH 7/7] drm/i915: there's no PIPESTAT on HAS_PCH_SPLIT platforms

From: Paulo Zanoni So don't read it when capturing the error state. This solves "unclaimed register" messages on Haswell when we have a GPU hang. V2: Check for HAS_PCH_SPLIT instead of Gen5+ because VLV still has this register. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_irq.c |

[Intel-gfx] [PATCH 6/7] drm/i915: there's no DSPPOS register on gen4+

From: Paulo Zanoni So don't read it when capturing the error state. This solves some "unclaimed register" messages on Haswell when we hang the GPU. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --gi

[Intel-gfx] [PATCH 5/7] drm/i915: fix DSPADDR Gen check

From: Paulo Zanoni The first version of commit "drm/i915: there's no DSPADDR register on Haswell" added 2 "!IS_HASWELL" checks. When reviewing the patch, Ben suggested to make these checks more future-proof, so when Daniel applied the patch he fixed the first check but not the second. This commit

[Intel-gfx] [PATCH 4/7] drm/i915: don't touch the PF regs if the power well is down

From: Paulo Zanoni This solves some "unclaimed register" messages when booting the machine with eDP attached. V2: Rebase and add the comment requested by Daniel. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletion

[Intel-gfx] [PATCH 3/7] drm/i915: add intel_using_power_well

From: Paulo Zanoni It returns true if we've requested to turn the power well on and it's really on. It also returns true for all the previous gens. For now there's just one caller, but I'm going to add more. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c |4 ++-- dri

[Intel-gfx] [PATCH 2/7] drm/i915: only disable DDI sound if intel_crtc->eld_vld

From: Paulo Zanoni We already have the same check on intel_enable_ddi. This patch prevents "unclaimed register" messages when the power well is disabled. V2: Reset intel_crtc->eld_vld to false after the mode_set function. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_ddi.c |

[Intel-gfx] [PATCH 1/7] drm/i915: don't disable the power well yet

From: Paulo Zanoni We're still not 100% ready to disable the power well, so don't disable it for now. When we disable it we break the audio driver (because some of the audio registers are on the power well) and machines with eDP on port D (because it doesn't use TRANSCODER_EDP). Also, instead of

Re: [Intel-gfx] [PATCH 1/7] drm/i915: don't disable the power well yet

On Fri, Mar 22, 2013 at 3:45 PM, Paulo Zanoni wrote: > From: Paulo Zanoni > > We're still not 100% ready to disable the power well, so don't disable > it for now. > > Also, instead of just reverting the code, add a Kernel option to let > us disable it if we want. This will allow us to keep develo

Re: [Intel-gfx] [PATCH] Revert "drm/i915: write backlight harder"

At Fri, 22 Mar 2013 15:44:46 +0100, Daniel Vetter wrote: > > This reverts commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd. > > Turns out that cargo-culting breaks systems. Note that we can't revert > further, since > > commit 770c12312ad617172b1a65b911d3e6564fc5aca8 > Author: Takashi Iwai > Dat

[Intel-gfx] [PATCH 1/7] drm/i915: don't disable the power well yet

From: Paulo Zanoni We're still not 100% ready to disable the power well, so don't disable it for now. Also, instead of just reverting the code, add a Kernel option to let us disable it if we want. This will allow us to keep developing and testing the feature while it's not enabled. Signed-off-b

[Intel-gfx] [PATCH] Revert "drm/i915: write backlight harder"

This reverts commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd. Turns out that cargo-culting breaks systems. Note that we can't revert further, since commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopen

[Intel-gfx] [PATCH] drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and write the fence from each cpu taking care to serialise memory accesses on each. The usual mb(), or even a mb() on each CPU is not enough to ensure that access

Re: [Intel-gfx] Screen blanking when copying files to USB/SD-Card ??

On Fri, Mar 22, 2013 at 2:57 PM, Fabrice Delente wrote: > I rebooted with drm.debug=0xe but /sys/kernel/debug/dri/0/i915_error_state > is not available, how do I activate it? You need to enable debugfs in the kernel configuration and then also mount it with # mount -t debugfs debugfs /sys/kernel

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

On Fri, Mar 22, 2013 at 12:34:41PM +0100, Takashi Iwai wrote: > At Fri, 22 Mar 2013 12:22:42 +0100, > Daniel Vetter wrote: > > > > On Fri, Mar 22, 2013 at 11:42 AM, Takashi Iwai wrote: > > > At Fri, 22 Mar 2013 11:22:57 +0100, > > > Daniel Vetter wrote: > > >> On Fri, Mar 22, 2013 at 11:13 AM, Da

Re: [Intel-gfx] Screen blanking when copying files to USB/SD-Card ??

I rebooted with drm.debug=0xe but /sys/kernel/debug/dri/0/i915_error_state is not available, how do I activate it? Thanks. 2013/3/22 Fabrice Delente > I'm not at home, and the proxy here stops me from ssh'ing, I'll post the > result around 18 h (french time) when > I get back home. > ​ > Yes,

Re: [Intel-gfx] [PATCH 2/3] Revert "drm/i915: set TRANSCODER_EDP even earlier"

On Fri, Mar 22, 2013 at 09:30:05AM -0300, Paulo Zanoni wrote: > 2013/3/22 Daniel Vetter : > > This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3. > > > > The reason is that Takashi Iwai reported a regression bisected to this > > commit: > > > > http://www.mail-archive.com/intel-gfx@lists.

Re: [Intel-gfx] Screen blanking when copying files to USB/SD-Card ??

I'm not at home, and the proxy here stops me from ssh'ing, I'll post the result around 18 h (french time) when I get back home. ​ Yes, https://bugs.freedesktop.org/show_bug.cgi?id=62629 is my bug, I didn't think of posting the reference, sorry. _

Re: [Intel-gfx] Screen blanking when copying files to USB/SD-Card ??

On Fri, Mar 22, 2013 at 2:21 PM, Fabrice Delente wrote: > Mar 22 12:17:18 slick kernel: [ 2214.212056] [drm:i915_hangcheck_hung] > *ERROR* Hangcheck timer elapsed... GPU hung > Mar 22 12:17:18 slick kernel: [ 2214.212102] [drm:i915_error_work_func], > resetting chip There should be a message some

Re: [Intel-gfx] [PATCH 2/3] Revert "drm/i915: set TRANSCODER_EDP even earlier"

On Fri, Mar 22, 2013 at 10:53 AM, Daniel Vetter wrote: > This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3. > > The reason is that Takashi Iwai reported a regression bisected to this > commit: > > http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html > > His machine

Re: [Intel-gfx] [PATCH 2/3] Revert "drm/i915: set TRANSCODER_EDP even earlier"

2013/3/22 Daniel Vetter : > This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3. > > The reason is that Takashi Iwai reported a regression bisected to this > commit: > > http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html > > His machine has eDP on port D (usual deskt

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

At Fri, 22 Mar 2013 12:22:42 +0100, Daniel Vetter wrote: > > On Fri, Mar 22, 2013 at 11:42 AM, Takashi Iwai wrote: > > At Fri, 22 Mar 2013 11:22:57 +0100, > > Daniel Vetter wrote: > >> On Fri, Mar 22, 2013 at 11:13 AM, Daniel Vetter > >> wrote: > >> > On Fri, Mar 22, 2013 at 11:00 AM, Takashi I

Re: [Intel-gfx] [PATCH] drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

On Thu, Mar 21, 2013 at 03:30:19PM +, Chris Wilson wrote: > In order to fully serialize access to the fenced region and the update > to the fence register we need to take extreme measures on SNB+, and > write the fence from each cpu taking care to serialise memory accesses > on each. The usual

Re: [Intel-gfx] [PATCH xf86-video-intel] Add OpenBSD backlight control implementation

On Fri, Mar 22, 2013 at 11:23:11AM +0100, Mark Kettenis wrote: > From: Mark Kettenis Thank you for the patch, I presume it works ;-) Pushed, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freede

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

On Fri, Mar 22, 2013 at 11:42 AM, Takashi Iwai wrote: > At Fri, 22 Mar 2013 11:22:57 +0100, > Daniel Vetter wrote: >> On Fri, Mar 22, 2013 at 11:13 AM, Daniel Vetter >> wrote: >> > On Fri, Mar 22, 2013 at 11:00 AM, Takashi Iwai wrote: >> >> At Fri, 22 Mar 2013 10:53:41 +0100, >> >> Daniel Vette

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

At Fri, 22 Mar 2013 11:22:57 +0100, Daniel Vetter wrote: > > On Fri, Mar 22, 2013 at 11:13 AM, Daniel Vetter > wrote: > > On Fri, Mar 22, 2013 at 11:00 AM, Takashi Iwai wrote: > >> At Fri, 22 Mar 2013 10:53:41 +0100, > >> Daniel Vetter wrote: > >>> > >>> This reverts the following commits: > >>

Re: [Intel-gfx] [PATCH i-g-t] lib: Make sure we can also use the short form of the subtest options

On Thu, Mar 21, 2013 at 08:14:39PM +0100, Daniel Vetter wrote: > My original thinking behind only allowing the long option name is to > avoid collisions with cmdline options for the test executable itself. > E.g. when we'd teach testdisplay a few different default runs, but you > could still dig in

[Intel-gfx] [PATCH xf86-video-intel] Add OpenBSD backlight control implementation

From: Mark Kettenis Signed-off-by: Mark Kettenis --- src/intel_display.c | 75 - 1 file changed, 69 insertions(+), 6 deletions(-) diff --git a/src/intel_display.c b/src/intel_display.c index 5ee955e..6e6a7a2 100644 --- a/src/intel_display.c +

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

On Fri, Mar 22, 2013 at 11:13 AM, Daniel Vetter wrote: > On Fri, Mar 22, 2013 at 11:00 AM, Takashi Iwai wrote: >> At Fri, 22 Mar 2013 10:53:41 +0100, >> Daniel Vetter wrote: >>> >>> This reverts the following commits: >>> >>> cf0a6584aa6d382f802 drm/i915: write backlight harder >>> 770c12312ad617

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

On Fri, Mar 22, 2013 at 11:00 AM, Takashi Iwai wrote: > At Fri, 22 Mar 2013 10:53:41 +0100, > Daniel Vetter wrote: >> >> This reverts the following commits: >> >> cf0a6584aa6d382f802 drm/i915: write backlight harder >> 770c12312ad617172b1 drm/i915: Fix blank panel at reopening lid >> >> We've come

Re: [Intel-gfx] Screen blanking when copying files to USB/SD-Card ??

On Fri, Mar 22, 2013 at 10:51 AM, Fabrice Delente wrote: > I have noticed this bug of the driver when I copy a big gob of data to > an USB/SD-Card mounted driver, with vfat filesystem: the screen turns > off, and nothing can turn it on again. I can ssh into the machine, > where everything is still

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

At Fri, 22 Mar 2013 10:53:41 +0100, Daniel Vetter wrote: > > This reverts the following commits: > > cf0a6584aa6d382f802 drm/i915: write backlight harder > 770c12312ad617172b1 drm/i915: Fix blank panel at reopening lid > > We've come full-circle in this mess and now broke the originally fixed >

[Intel-gfx] Screen blanking when copying files to USB/SD-Card ??

Hello. I have noticed this bug of the driver when I copy a big gob of data to an USB/SD-Card mounted driver, with vfat filesystem: the screen turns off, and nothing can turn it on again. I can ssh into the machine, where everything is still running ok, so it's really a display problem. I can turn

[Intel-gfx] [PATCH 3/3] drm/i915: Revert backlight cargo-culting

This reverts the following commits: cf0a6584aa6d382f802 drm/i915: write backlight harder 770c12312ad617172b1 drm/i915: Fix blank panel at reopening lid We've come full-circle in this mess and now broke the originally fixed machines again with the new trick. So remove it all and start over. Refer

[Intel-gfx] [PATCH 2/3] Revert "drm/i915: set TRANSCODER_EDP even earlier"

This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3. The reason is that Takashi Iwai reported a regression bisected to this commit: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html His machine has eDP on port D (usual desktop all-in-on setup), which intel_dp.c i

[Intel-gfx] [PATCH 1/3] Revert "drm/i915: dynamic Haswell display power well support"

This reverts commit d6dd9eb1d96d2b7345fe4664066c2b7ed86da898. The current hsw power wells code seems to break audio - the current audio driver presumes that register contents are preserved when disablng an output, which is no longer true with the power wells code. And Takashi Iwai also reported a

Re: [Intel-gfx] Regression: HSW eDP broken on 3.9-rc[12]

On Thu, Mar 14, 2013 at 4:15 PM, Takashi Iwai wrote: > I noticed that a Haswell desktop machine with eDP gets only the blank > screen on the latest Linus tree. It works fine with 3.8, so it's a > regression since 3.9-rc1. Actually, it's not a regression. It's > three regressions in a shot! (I h

Re: [Intel-gfx] [PATCH 10/15] drm/i915: check the power well when capturing error state

On Thu, Mar 21, 2013 at 11:12 PM, Paulo Zanoni wrote: > I don't understand your way of thinking: your argument is that "this > is difficult to maintain", but then you're proposing the addition of a > new i915_read, which IMHO is way much more complex and feels like a > hackish solution to the prob