My TV behaves differently for DVI signals through the HDMI connector,
so I was wondering if it is possible to force sending DVI signal even
though both connectors are HDMI.
I have i5 processor, so Clarkdale GPU.
___
Intel-gfx mailing list
Intel-gfx@lists.
On Sun, 22 Aug 2010 18:23:21 +0100, Chris Wilson
wrote:
> My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
> addin-offset. With the check in place, the panel was declared absent.
Reviewing the history, the addin-offset was added to defend against
incorrect LVDS entries in some VBIO
My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
addin-offset. With the check in place, the panel was declared absent.
Signed-off-by: Chris Wilson
Cc: Zhao Yakui
---
drivers/gpu/drm/i915/intel_lvds.c | 34 +++---
1 files changed, 15 insertions(+), 19
We reset intel_encoder for every matching encoder whilst iterating over
the encoders attached to this crtc when changing mode. As such in a
cloned configuration intel_encoder may not correspond to the correct
is_edp encoder.
By scoping intel_encoder to the loop, not only is the compiler able to
sp
References:
Bug 26864 - Green Screen in LG Projector using HDMI output
https://bugs.freedesktop.org/show_bug.cgi?id=26864
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_hdmi.c | 12
drivers/gpu/drm/i915/intel_sdvo.c | 11 +++
2 files changed, 15 insertio
Parse the EDID looking for a CEA-extension block that details whether
the connected monitor has audio support over HDMI.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_edid.c | 27 +++
include/drm/drm_crtc.h |1 +
2 files changed, 28 insert
The calculation seem backwards as they compute the number of entries
that would be drained during a memory fetch, and but return the opposite
value.
This fixes a common flicker [or even completely scrambled display] on
high resolution outputs (e.g. 1920x1080 with 915GM). However, as we do not
adju
It is recommended that we use the Video BIOS tables that were copied
into the OpRegion during POST when initialising the driver. This saves
us from having to furtle around inside the ROM ourselves and possibly
allows the vBIOS to adjust the tables prior to initialisation.
On some systems, such as
We were failing when trying to allocate the resource for MMIO of the
MCHBAR because we forgot to specify what type of resource we wanted.
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 92d5605..744a2a7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
++
Only stop trying if the aux channel sucessfully reports that the
transmission was completed, otherwise try again. On the 5th failure,
bail and report that something is amiss.
This fixes a sporadic failure in reading the EDID for my external panel
over DP.
Signed-off-by: Chris Wilson
---
drivers
If we need to wait until the next vblank for the register to be updated
and to take effect, make sure the write is actually flushed to the register
prior to sleeping.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_tv.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-
If the VBIOS tells us the mapping of the SDVO device onto the DDC bus,
use it. However, if there is no VBIOS available that mapping is
uninitialised and we should fallback to our earlier guess.
Fix regression introduced in b108 (which in turn is a fix for the
regression caused by the introduct
Adam Hill reported that his Arrandale system required a much longer, up
to 200x500us, wait for the panel to initialise or else modesetting would
fail.
References:
https://bugs.freedesktop.org/show_bug.cgi?id=29141
Signed-off-by: Chris Wilson
Reported-by: Adam Hill
---
drivers/gpu/drm/i915/i
If we don't flush the write then we can not be sure that the border
colour will have taken effect by the time we try to read it back.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_crt.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
The GPU records whether it is currently waiting for a completion of a
WAIT_FOR_EVENT in the RB_WAIT bit in the ringbuffer control registers.
On third generation chipsets and later, a write of 1 to this bit breaks
the hang and returns the GPU to arbitration, i.e. the GPU should
continue executing th
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_sdvo.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 093e914..4f73cb8 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
Lets try to avoid duplicating bugs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 80 --
1 files changed, 9 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b9c6487..13b3292 100644
--- a/drivers/gpu/drm/i915/inte
If we disable the pipe and the GPU is currently waiting on a scanline
WAIT_FOR_EVENT, the GPU will hang. Fortunately, there is a magic bit
which we can write on i915+ to break this wait after disabling the
pipe.
References:
Bug 29252 - [Arrandale] Hung WAIT_FOR_EVENT when running rss-glx-skyroc
i965 uses the Display Registers to compute the offset from the display
base so the new base does not need adjusting when flipping. The older
chipsets use a fence to access the display and so do perceive the
surface as linear and have a single base register which is reprogrammed
using the flip.
Sig
To simplify the IS_GEN[234] macros and to enable switching.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 61 ++-
drivers/gpu/drm/i915/i915_drv.h | 27 -
2 files changed, 34 insertions(+), 54 deletions(-)
diff --git a/d
wait_for() uses msleep() to yield the cpu whilst spinning waiting for a
register to change. kdb asserts that mode changes are atomic and so
prohibits msleep. The alternative would be to use mdelay or to simply
probe the register more often instead of busy waiting.
Signed-off-by: Chris Wilson
---
Add a msleep to intel_wait_for_vblank().
Change intel_wait_for_vblank_off() to repeat *until* timeout.
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
From: Daniel Vetter
ums-gem code correctly cancels the retire work (at lastclose time),
kms does not do so. Fix this by canceling the work right after ideling
the gpu.
While staring at the code I noticed that the work function is not
static. Fix this, too.
Signed-off-by: Daniel Vetter
Signed-o
From: Daniel Vetter
When the module unloads, all users should be gone, hence all bo references
held by userspace, too. This should already result in an idle ringbuffer.
Still, be paranoid and idle gem before starting the unload dance.
Also kill the call to i915_gem_lastclose under an if (kms), i
From: Daniel Vetter
Kill any outstanding unpin_work when destroying the corresponding
crtc. Then flush the workqueue before the gem teardown, in case
any unpin work is still outstanding.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
drivers/gpu/drm/i915/inte
From: Daniel Vetter
idle_work wasn't cleaned up at all. It takes &dev->struct_mutex, but
accesss the mode_config crtc list (without any other locking!). Hence
this work needs to be canceled before calling drm_mode_config_cleanup.
As evidenced by the kernel's object debuggin code, the current cod
From: Daniel Vetter
With kms, interrupts now get disabled in the modesetting cleanup. So
free the error state afterwards, it currently gets allocated in
the interrupt handler.
Signed-off-by: Daniel Vetter
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c |4 ++--
1 files cha
From: Daniel Vetter
hotplug_work is queued by the hotplug interrupt and only either emits
a hotplug uevent or queues a crt poll slow-work. No other locking. So
it's safe to cancel this work _after_ irq's have been turned off. But
before the modesetting objects are destroyed because the hotplug
From: Daniel Vetter
This is the first patch to clean up module unload races due to
outstanding timers/work. Preparatory step: Thou shalt not destroy
the workqueue when new work might still get enqued.
Now error_work gets queued by the hangcheck timer and only (atomically)
reads the chip wedged s
From: Daniel Vetter
struct intel_dp contains both struct intel_encoder at the beginning (as
it's base-class) and an i2c adapater. When initializing, the i2c adapter
gets assigned
intel_encoder->ddc_adaptor = &intel_dp->adapter
and the generic intel_encode_destroy happily calls kfree on
Sorry for the mailbomb. The first attempt was aborted by the relay
part-way through the series, so I am trying a different mail server.
Please refer to 1282474317-14470-1-git-send-email-ch...@chris-wilson.co.uk
for an overview of this series, and note that you can also fetch these
patches from ann
The GPU records whether it is currently waiting for a completion of a
WAIT_FOR_EVENT in the RB_WAIT bit in the ringbuffer control registers.
On third generation chipsets and later, a write of 1 to this bit breaks
the hang and returns the GPU to arbitration, i.e. the GPU should
continue executing th
Add a msleep to intel_wait_for_vblank().
Change intel_wait_for_vblank_off() to repeat *until* timeout.
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
35 matches
Mail list logo
