On Thu, Nov 10, 2011 at 03:55:22PM +0800, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
Wow I reproduced the bug and got a very interesting dmesg:
gfx =[ 4561.287980] [drm:intel_write_eld], ELD on
[CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
On 11/10/11 8:55 AM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
Wow I reproduced the bug and got a very interesting dmesg:
gfx = [ 4561.287980] [drm:intel_write_eld], ELD on
[CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
gfx = [
On Wed, 2011-11-09 at 10:07 -0800, Keith Packard wrote:
On Wed, 09 Nov 2011 17:30:29 +0100, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
Additional note: while I've not touched the line since it does not
affect me, it seems that i915_panel_use_ssc *cannot* be less than 0
since
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:
On 11/10/11 9:55 AM, Christopher White wrote:
On 11/10/11 8:55 AM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
Wow I reproduced the bug and got a very
At Thu, 10 Nov 2011 12:50:11 +0100,
Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:
On 11/10/11 9:55 AM, Christopher White wrote:
On 11/10/11 8:55 AM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 03:33:50PM
On 11/10/11 12:53 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:50:11 +0100,
Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:
On 11/10/11 9:55 AM, Christopher White wrote:
On 11/10/11 8:55 AM, Wu Fengguang wrote:
This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.
The issue can be reproduced easily via the following command:
while ``; do cat
On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:
On 11/10/11 9:55 AM, Christopher White wrote:
On 11/10/11 8:55 AM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at
On 11/10/11 1:56 PM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:
On 11/10/11 9:55 AM, Christopher White wrote:
On 11/10/11 8:55 AM, Wu Fengguang
At Thu, 10 Nov 2011 13:39:00 +0100,
Christopher White wrote:
On 11/10/11 12:53 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:50:11 +0100,
Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:
On 11/10/11 9:55
On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote:
On 11/10/11 1:56 PM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:
On
Hi all,
This is a bit a mixed pile, but I've used all the earlier patches to test
the gen6+ swizzling patch and I like to send out patch series somewhat
resembling the setup I've tested them in.
Patches 1-2 refactor our debugfs code a bit.
Patches 3-5 implement a debugfs interface to simulate a
Only forcewake has an open with special semantics, the other r/w
debugfs only assign the file private pointer.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 +-
1 files changed, 5 insertions(+), 21 deletions(-)
diff
All r/w debugfs files are created equal.
v2: Add some newlines to make the code easier on the eyes as requested
by Ben Widawsky.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 55 +++---
1 files changed, 18
gpu reset is a very important piece of our infrastructure.
Unfortunately we only really it test by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one of the rather complicated pieces of code we
have, consisting of
- hang
- reduce the irq disabled section, even for a debugfs file this was
way too long.
- protect readers of the captured error state from concurrent freeing
of the same by holding dev-struct_mutex.
- always disable irqs when taking the lock.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
This way we can simulate a bunch of gpu hangs and run the error_state
capture code every time (without the need to reload the module).
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff
It looks like the desktop variants of i915 and i945 also have the DCC
register to control dram channel interleave and cpu side bit6
swizzling.
Unfurnately internal Cspec/ConfigDB documentation for these ancient chips
have already been dropped and there seem to be no archives. Also
somebody
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +
drivers/gpu/drm/i915/i915_reg.h | 31 +++
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
This will also come handy for the gen6+ swizzling support, where the
driver is supposed to control swizzling depending upon dram
configuration.
v2: CxDRB3 are 16 bit regs! Noticed by Chris Wilson.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 50
We have to do this manually. Somebody had a Great Idea.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c|2 +-
drivers/gpu/drm/i915/i915_drv.c|4 +++-
drivers/gpu/drm/i915/i915_drv.h|3 ++-
drivers/gpu/drm/i915/i915_gem.c
On Thu, 10 Nov 2011 10:51:26 -0200, Eugeni Dodonov eugeni.dodo...@intel.com
wrote:
This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.
On 11/10/11 2:17 PM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote:
On 11/10/11 1:56 PM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 12:00:53
At Thu, 10 Nov 2011 21:17:53 +0800,
Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote:
On 11/10/11 1:56 PM, Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
On 11/10/11 12:22 PM, Takashi Iwai wrote:
At Thu, 10
Got the delay - it's 72.986623-72.747632 = 239ms.
[ 72.739944] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
[ 72.742541] HDMI status: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=0
[ 72.745082] HDMI hot plug event: Codec=3 Pin=6
On Thu, Nov 10, 2011 at 09:47:46PM +0800, Wu Fengguang wrote:
Got the delay - it's 72.986623-72.747632 = 239ms.
[ 72.739944] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
[ 72.742541] HDMI status: Codec=3 Pin=6 Presence_Detect=1
At Thu, 10 Nov 2011 21:51:50 +0800,
Wu Fengguang wrote:
So maybe the hardware is in some state that is unable to provide the
real ELD content?
That's my guess as well. I think the hardware may still be doing some
form of data negotiation with the HDMI display device at that
This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.
The issue can be reproduced easily via the following command:
while ``; do cat
It looks like the desktop variants of i915 and i945 also have the DCC
register to control dram channel interleave and cpu side bit6
swizzling.
Unfortunately internal Cspec/ConfigDB documentation for these ancient chips
have already been dropped and there seem to be no archives. Also
somebody
This will also come handy for the gen6+ swizzling support, where the
driver is supposed to control swizzling depending upon dram
configuration.
v2: CxDRB3 are 16 bit regs! Noticed by Chris Wilson.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
v3: align case blocks with the switch
On Thu, Nov 10, 2011 at 02:18:00PM +0100, Daniel Vetter wrote:
All r/w debugfs files are created equal.
v2: Add some newlines to make the code easier on the eyes as requested
by Ben Widawsky.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ben Widawsky b...@bwidawsk.net
On 11/10/2011 09:12 AM, Paulo J. Matos wrote:
Hi,
I got a new PC DELL Vostro 360. This is an all-in-one which uses the
Optimus setup. An intel GT1 (Sandybridge) couples with an Nvidia 525m.
Ubuntu out of the box shows a black screen unless I add nomodeset to
kernel options.
That sounds a
On Thu, 10 Nov 2011 14:17:58 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Hi all,
This is a bit a mixed pile, but I've used all the earlier patches to test
the gen6+ swizzling patch and I like to send out patch series somewhat
resembling the setup I've tested them in.
Patches 1-2
There is an error in i915_read_blc_pwm_ctl, where the register values
are not being copied correctly. BLC_PWM_CTL and BLC_PWM_CTL2 are
getting mixed up. This patch fixes that so that saveBLC_PWM_CTL2 and
not saveBLC_PWM_CTL is copied to the BLC_PWM_CTL2 register.
Signed-off-by: Simon Que
Hi,
On Thu, Nov 10, 2011 at 5:50 PM, Simon Que s...@chromium.org wrote:
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 * pwm_max)
The PWM register allows the
On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote:
At Thu, 10 Nov 2011 21:51:50 +0800,
Wu Fengguang wrote:
So maybe the hardware is in some state that is unable to provide the
real ELD content?
That's my guess as well. I think the hardware may still be doing some
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 * pwm_max)
The PWM register allows the max PWM value to be set. So we want to use
the formula, where freq = 200:
Hello,
I recently reported a graphics bug that occurs when running the
Windows versions of Firefox and Thunderbird under Wine. The Wine
developers think that this is probably a bug in the i915 driver. Could
the i915 developers take a look?
http://bugs.winehq.org/show_bug.cgi?id=29027
-Alex
At Fri, 11 Nov 2011 10:29:25 +0800,
Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote:
At Thu, 10 Nov 2011 21:51:50 +0800,
Wu Fengguang wrote:
So maybe the hardware is in some state that is unable to provide
the
real ELD content?
39 matches
Mail list logo
