Ben Gamari [Mon, 14 Sep 2009 21:48:41 +0000 (17:48 -0400)]
drm/i915: Check whether chip is wedged in i915_wait_request()
i915_wait_request() only checks mm.wedged after it interacts with the
hardware, generally causing the driver to lock up waiting for a wedged
chip. Make sure we check mm.wedged as the first thing we do.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Li Peng [Tue, 15 Sep 2009 05:03:36 +0000 (13:03 +0800)]
drm/i915: fix opregion backlight chip detect and range
BLC_PWM_CTL2 is for 965+ only, so add device model check for
legacy backlight control.
For native backlight control, it maps the backlight value (0~255)
in opregion ASLE[BCLP] to backlight duty cycle (0~max_backlight)
and set into control register.
It also add support for IGD device, which follows opregion spec.
Signed-off-by: Li Peng <peng.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Zhenyu Wang [Sat, 19 Sep 2009 06:54:09 +0000 (14:54 +0800)]
drm/i915: Fix LVDS panel fitting on Arrandale
Arrandale has new window based method for panel fitting.
This one enables full screen aspect scaling on LVDS. It fixes
standard mode display failure on LVDS for Arrandale.
Cc: Stable Team <stable@kernel.org> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Chris Wilson [Thu, 10 Sep 2009 07:53:04 +0000 (08:53 +0100)]
drm/i915: Only destroy a constructed mmap offset
drm_ht_remove_item() does not handle removing an absent item and the hlist
in particular is incorrectly initialised. The easy remedy is simply skip
calling i915_gem_free_mmap_offset() unless we have actually created the
offset and associated ht entry.
This also fixes the mishandling of a partially constructed offset which
leaves pointers initialized after freeing them along the
i915_gem_create_mmap_offset() error paths.
In particular this should fix the oops found here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/415357/comments/8
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Cc: stable@kernel.org
Eric Anholt [Fri, 11 Sep 2009 00:48:48 +0000 (17:48 -0700)]
agp/intel: Fix the pre-9xx chipset flush.
Ever since we enabled GEM, the pre-9xx chipsets (particularly 865) have had
serious stability issues. Back in May a wbinvd was added to the DRM to
work around much of the problem. Some failure remained -- easily visible
by dragging a window around on an X -retro desktop, or by looking at bugzilla.
The chipset flush was on the right track -- hitting the right amount of
memory, and it appears to be the only way to flush on these chipsets, but the
flush page was mapped uncached. As a result, the writes trying to clear the
writeback cache ended up bypassing the cache, and not flushing anything! The
wbinvd would flush out other writeback data and often cause the data we wanted
to get flushed, but not always. By removing the setting of the page to UC
and instead just clflushing the data we write to try to flush it, we get the
desired behavior with no wbinvd.
This exports clflush_cache_range(), which was laying around and happened to
basically match the code I was otherwise going to copy from the DRM.
Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Brice Goglin <Brice.Goglin@ens-lyon.org> Cc: stable@kernel.org
This patch adds framebuffer compression (good for about ~0.5W power
savings in the best case) support for pre-GM45 chips. GM45+ have a new,
more flexible FBC scheme that will be added in a separate patch.
FBC can't always be enabled: the compressed buffer must be physically
contiguous and reside in stolen space. So if you have a large display
and a small amount of stolen memory, you may not be able to take
advantage of FBC. In some cases, a BIOS setting controls how much
stolen space is available. Increasing this to 8 or 16M can help.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
drm/i915: generate a KMS uevent at lid open/close time
With all the other lid pieces in place, it's easy to generate a uevent
for the LVDS connector just like we do for other outputs. Should make
lid open/close fit in with the rest of a userland based output
reconfiguration scheme.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
drm/i915: use ACPI LID status for LVDS ->detect hook
We can't load or hotplug detect LVDS like we can other outputs, but if
there's a lid device present we can use it as a proxy. This allows the
LFP state to be determined at ->detect time, making configurations
requiring manual intervention today "just work" assuming the lid device
status is correct.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
Some laptop platforms will disable pipes and/or planes at lid close time
and not restore them when the lid is opened again. So catch the lid
event, and if the lid was opened, force a mode restore.
Fixes fdo bug #21230.
Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
Some drivers need to know when a lid event occurs and get the current
status. This can be useful for when a platform firmware clobbers some
hardware state at lid time, and a driver needs to restore things when
the lid is opened again.
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
drm/i915: Write zero to DPLL_MD Reg for non-SDVO output
When the output device is LVDS, maybe the pixel clock of adjusted_mode will be
less than that in mode. In such case it will set the incorrect multipler factor
in DPLL_MD register.
So the dpll_md_reg will be reset when the output type is non-SDVO
drm/i915: Add the brightness property for SDVO-LVDS
When the sdvo device is detected as SDVO-LVDS, we will check whether the
brightness is supported by issue SDVO enhancement command.
If it is supported, we will add the brightness property and then brightness
can be adjusted.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
drm/i915: Add the enhancement property for SDVO-TV
When the sdvo device is detected as SDVO-TV, we will check whether the
sepecific picture enhancement is supported. If it is supported, we will
add the corresponnding property for SDVO-TV. We will add the following
property for the SDVO-TV enhancements if they are supported:
* Contrast/Brightness/Saturation/Hue.
* left/right/top/bottom margin: This is implemented by using the
horizontal/vertical overscan enhancements. When the overscan
enhancements are supported, the above properties will be added. This is
to be compatible with what we have done in integrated-TV.
* horizontal pos/vertical pos.
http://bugs.freedesktop.org/show_bug.cgi?id=22891
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
Eric Anholt [Wed, 9 Sep 2009 18:50:45 +0000 (11:50 -0700)]
drm/i915: Zap mmaps of objects before unbinding them from the GTT.
Otherwise, some other userland writing into its buffer may race to land
writes either after the CPU thinks it's got a coherent view, or after its
GTT entries have been redirected to point at the scratch page. Either
result is unpleasant.
Adam Jackson [Tue, 8 Sep 2009 01:51:46 +0000 (11:51 +1000)]
drm: prune modes when output is disconnected.
When an output was disconnected, its mode list would remain. If you later
plugged into a sink with no EDID (projector, etc), you'd inherit the mode
list from the old sink, which is not what you want.
Dave Airlie [Tue, 4 Aug 2009 01:43:41 +0000 (11:43 +1000)]
drm/i915: get the bridge device once.
The driver gets the bridge device in a number of places, upcoming
vga arb code paths need the bridge device, however they need it in
under a lock, and the pci lookup can allocate memory. So clean
this code up before then and get the bridge once for the driver lifetime.
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
agp/intel: support for new chip variant of IGDNG mobile
drm/i915: Unref old_obj on get_fence_reg() error path
drm/i915: increase default latency constant (v2 w/comment)
drm/kms: add a function that can add the mode for the output device without EDID
Add a function that can be used to add the default mode for the output device
without EDID.
It will add the default mode that meets with the requirements of given
hdisplay/vdisplay limit.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
When we need to add the standard timing mode, we will firstly check whether it
can be found in DMT table by comparing the hdisplay/vdisplay/vfresh_rate.
If it can't be found, then we will use the cvt/gtf to add the required mode.
If it can be found, it will be returned.
At the same time the function of drm_mode_vrefresh is also fixed. It will
return the result of actual refresh_rate plus 0.5.
For example:
When the calculated value is 84.9, then the fresh_rate is 85.
When the calculated value is 70.02, then the fresh_rate is 70.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
When we add a standard timing mode in UMS, we will first check whether it can
be found in default mode table. If it can't be found, then we will use cvt/gtf
to add the standard timing mode.
Add the default mode table so that we can check whether the given mode
can be found in the default mode table as what we have done in UMS mode.
If the status of one output device is connected but there is no EDID, it will
have no correct mode. In such case we can add some default modes for it. Of
course we only add the modes in the default modes list that visible part is not
greater than 1024x768.
The default mode is autogenerated from the DMT spec. And it is copied from
xserver/hw/xfree86/modes/xf86EdidModes.c. But the mode with reduced blank
feature is removed.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 7 Sep 2009 05:26:19 +0000 (15:26 +1000)]
drm/radeon/kms: add LTE/GTE discard + rv515 two sided stencil register.
This adds some rv350+ register for LTE/GTE discard,
and enables the rv515 two sided stencil register.
It also disables the DEPTHXY_OFFSET register which
can be used to workaround the CS checker.
Moves rs690 to proper place in rs600 and uses correct
table on rs600.
Chris Wilson [Sat, 5 Sep 2009 17:07:06 +0000 (18:07 +0100)]
drm/i915: Pad ringbuffer with NOOPs before wrapping
According to the docs, the ringbuffer is not allowed to wrap in the middle
of an instruction.
G45 PRM, Vol 1b, p101:
While the “free space” wrap may allow commands to be wrapped around the
end of the Ring Buffer, the wrap should only occur between commands.
Padding (with NOP) may be required to follow this restriction.
Do as commanded.
[Having seen bug reports where there is evidence of split commands, but
apparently the GPU has continued on merrily before a bizarre and untimely
death, this may or may not fix a few random hangs.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Eric Anholt <eric@anholt.net> Signed-off-by: Eric Anholt <eric@anholt.net>
breaks the build of the gianfar driver because "dev" is undefined in
this function. To quickly test rc9 I changed this to priv->ndev but I do
not know if this is the correct one.
--------------------
Signed-off-by: David S. Miller <davem@davemloft.net>
powerpc: Fix i8259 interrupt driver kernel crash on ML510
This patch fixes a null pointer exception caused by removal of
'ack()' for level interrupts in the Xilinx interrupt driver. A recent
change to the xilinx interrupt controller removed the ack hook for
level irqs.
Signed-off-by: Roderick Colenbrander <thunderbird2k@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm:
dm snapshot: fix on disk chunk size validation
dm exception store: split set_chunk_size
dm snapshot: fix header corruption race on invalidation
dm snapshot: refactor zero_disk_area to use chunk_io
dm log: userspace add luid to distinguish between concurrent log instances
dm raid1: do not allow log_failure variable to unset after being set
dm log: remove incorrect field from userspace table output
dm log: fix userspace status output
dm stripe: expose correct io hints
dm table: add more context to terse warning messages
dm table: fix queue_limit checking device iterator
dm snapshot: implement iterate devices
dm multipath: fix oops when request based io fails when no paths
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
sparc64: Fix bootup with mcount in some configs.
sparc64: Kill spurious NMI watchdog triggers by increasing limit to 30 seconds.
Nicolas Pitre [Sat, 5 Sep 2009 04:25:37 +0000 (00:25 -0400)]
ext2: fix unbalanced kmap()/kunmap()
In ext2_rename(), dir_page is acquired through ext2_dotdot(). It is
then released through ext2_set_link() but only if old_dir != new_dir.
Failing that, the pkmap reference count is never decremented and the
page remains pinned forever. Repeat that a couple times with highmem
pages and all pkmap slots get exhausted, and every further kmap() calls
end up stalling on the pkmap_map_wait queue at which point the whole
system comes to a halt.
Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2:
ocfs2: ocfs2_write_begin_nolock() should handle len=0
ocfs2: invalidate dentry if its dentry_lock isn't initialized.
pty: don't limit the writes to 'pty_space()' inside 'pty_write()'
The whole write-room thing is something that is up to the _caller_ to
worry about, not the pty layer itself. The total buffer space will
still be limited by the buffering routines themselves, so there is no
advantage or need in having pty_write() artificially limit the size
somehow.
And what happened was that the caller (the n_tty line discipline, in
this case) may have verified that there is room for 2 bytes to be
written (for NL -> CRNL expansion), and it used to then do those writes
as two single-byte writes. And if the first byte written (CR) then
caused a new tty buffer to be allocated, pty_space() may have returned
zero when trying to write the second byte (LF), and then incorrectly
failed the write - leading to a lost newline character.
This should finally fix
http://bugzilla.kernel.org/show_bug.cgi?id=14015
Reported-by: Mikael Pettersson <mikpe@it.uu.se> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When translating CR to CRNL in the n_tty line discipline, we did it as
two tty_put_char() calls. Which works, but is stupid, and has caused
problems before too with bad interactions with the write_room() logic.
The generic USB serial driver had that problem, for example.
Now the pty layer had similar issues after being moved to the generic
tty buffering code (in commit d945cb9cce20ac7143c2de8d88b187f62db99bdc:
"pty: Rework the pty layer to use the normal buffering logic").
So stop doing the silly separate two writes, and do it as a single write
instead. That's what the n_tty layer already does for the space
expansion of tabs (XTABS), and it means that we'll now always have just
a single write for the CRNL to match the single 'tty_write_room()' test,
which hopefully means that the next time somebody screws up buffering,
it won't cause weeks of debugging.
But the root of the problem lies in the fact that do_execve() path calls
tracehook_report_exec() which can stop if the tracer sets PT_TRACE_EXEC.
The tracee must not sleep in TASK_TRACED holding this mutex. Even if we
remove ->cred_guard_mutex from mm_for_maps() and proc_pid_attr_write(),
another task doing PTRACE_ATTACH should not hang until it is killed or the
tracee resumes.
With this patch do_execve() does not use ->cred_guard_mutex directly and
we do not hold it throughout, instead:
- introduce prepare_bprm_creds() helper, it locks the mutex
and calls prepare_exec_creds() to initialize bprm->cred.
- install_exec_creds() drops the mutex after commit_creds(),
and thus before tracehook_report_exec()->ptrace_stop().
or, if exec fails,
free_bprm() drops this mutex when bprm->cred != NULL which
indicates install_exec_creds() was not called.
Reported-by: Tom Horsley <tom.horsley@att.net> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: David Howells <dhowells@redhat.com> Cc: Roland McGrath <roland@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
page-allocator: always change pageblock ownership when anti-fragmentation is disabled
On low-memory systems, anti-fragmentation gets disabled as fragmentation
cannot be avoided on a sufficiently large boundary to be worthwhile. Once
disabled, there is a period of time when all the pageblocks are marked
MOVABLE and the expectation is that they get marked UNMOVABLE at each call
to __rmqueue_fallback().
However, when MAX_ORDER is large the pageblocks do not change ownership
because the normal criteria are not met. This has the effect of
prematurely breaking up too many large contiguous blocks. This is most
serious on NOMMU systems which depend on high-order allocations to boot.
This patch causes pageblocks to change ownership on every fallback when
anti-fragmentation is disabled. This prevents the large blocks being
prematurely broken up.
This is a fix to commit 49255c619fbd482d704289b5eb2795f8e3b7ff2e [page
allocator: move check for disabled anti-fragmentation out of fastpath] and
the problem affects 2.6.31-rc8.
Signed-off-by: Mel Gorman <mel@csn.ul.ie> Tested-by: Paul Mundt <lethal@linux-sh.org> Cc: David Howells <dhowells@redhat.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Acked-by: Greg Ungerer <gerg@snapgear.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David Howells [Sat, 5 Sep 2009 18:17:07 +0000 (11:17 -0700)]
nommu: fix error handling in do_mmap_pgoff()
Fix the error handling in do_mmap_pgoff(). If do_mmap_shared_file() or
do_mmap_private() fail, we jump to the error_put_region label at which
point we cann __put_nommu_region() on the region - but we haven't yet
added the region to the tree, and so __put_nommu_region() may BUG
because the region tree is empty or it may corrupt the region tree.
To get around this, we can afford to add the region to the region tree
before calling do_mmap_shared_file() or do_mmap_private() as we keep
nommu_region_sem write-locked, so no-one can race with us by seeing a
transient region.
Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi> Acked-by: Paul Mundt <lethal@linux-sh.org> Cc: Mel Gorman <mel@csn.ul.ie> Acked-by: Greg Ungerer <gerg@snapgear.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cancel_delayed_work() has to use del_timer_sync() to guarantee the timer
function is not running after return. But most users doesn't actually
need this, and del_timer_sync() has problems: it is not useable from
interrupt, and it depends on every lock which could be taken from irq.
Introduce __cancel_delayed_work() which calls del_timer() instead.
The immediate reason for this patch is
http://bugzilla.kernel.org/show_bug.cgi?id=13757
but hopefully this helper makes sense anyway.
As for 13757 bug, actually we need requeue_delayed_work(), but its
semantics are not yet clear.
Merge this patch early to resolves cross-tree interdependencies between
input and infiniband.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Roland Dreier <rdreier@cisco.com> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Stefan Richter [Thu, 3 Sep 2009 21:07:35 +0000 (23:07 +0200)]
firewire: sbp2: fix freeing of unallocated memory
If a target writes invalid status (typically status of a command that
already timed out), firewire-sbp2 attempts to put away an ORB that
doesn't exist. https://bugzilla.redhat.com/show_bug.cgi?id=519772
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter [Fri, 28 Aug 2009 11:26:03 +0000 (13:26 +0200)]
firewire: ohci: fix Ricoh R5C832, video reception
In dual-buffer DMA mode, no video frames are ever received from R5C832
by libdc1394. Fallback to packet-per-buffer DMA works reliably.
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13393/focus=13476
Reported-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter [Fri, 28 Aug 2009 11:25:15 +0000 (13:25 +0200)]
firewire: ohci: fix Agere FW643 and multiple cameras
An Agere FW643 OHCI 1.1 card works fine for video reception from one
camera but fails early if receiving from two cameras. After a short
while, no IR IRQ events occur and the context control register does not
react anymore. This happens regardless whether both IR DMA contexts are
dual-buffer or one is dual-buffer and the other packet-per-buffer.
This can be worked around by disabling dual buffer DMA mode entirely.
http://sourceforge.net/mailarchive/message.php?msg_name=4A7C0594.2020208%40gmail.com
(Reported by Samuel Audet.)
In another report (by Jonathan Cameron), an FW643 works OK with two
cameras in dual buffer mode. Whether this is due to different chip
revisions or different usage patterns (different video formats) is not
yet clear. However, as far as the current capabilities of
firewire-core's isochronous I/O interface are concerned, simply
switching off dual-buffer on non-working and working FW643s alike is not
a problem in practice. We only need to revisit this issue if we are
going to enhance the interface, e.g. so that applications can explicitly
choose modes.
Reported-by: Samuel Audet <samuel.audet@gmail.com> Reported-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
As David Moore noted, a previously correct sizeof() expression became
wrong since the commit changed its argument from an array to a pointer.
This resulted in an oops in ohci_cancel_packet in the shared workqueue
thread's context when an isochronous resource was to be freed.
Reported-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Keith Packard [Fri, 4 Sep 2009 05:07:54 +0000 (13:07 +0800)]
drm/I915: Use the CRT DDC to get the EDID for DVI-connector on Mac
mac Mini's have a single DDC line on the DVI connector, shared between the
analog link and the digital link. So, if DDC isn't detected on GPIOE (the
usual SDVO DDC link), try GPIOA (the usual VGA DDC link) when there isn't a
VGA monitor connected.
Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
Jesse Barnes [Mon, 17 Aug 2009 20:31:43 +0000 (13:31 -0700)]
drm/i915: add dynamic clock frequency control
There are several sources of unnecessary power consumption on Intel
graphics systems. The first is the LVDS clock. TFTs don't suffer from
persistence issues like CRTs, and so we can reduce the LVDS refresh rate
when the screen is idle. It will be automatically upclocked when
userspace triggers graphical activity. Beyond that, we can enable memory
self refresh. This allows the memory to go into a lower power state when
the graphics are idle. Finally, we can drop some clocks on the gpu
itself. All of these things can be reenabled between frames when GPU
activity is triggered, and so there should be no user visible graphical
changes.
Signed-off-by: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
Shaohua Li [Mon, 24 Aug 2009 02:25:23 +0000 (10:25 +0800)]
drm/i915: Support IGD EOS
In the event that any one of the DAC analog outputs (R,G,B) were driven
at full-scale (white video) or some analog level close to full-scale
voltage, and if the video cable were then disconnected, the analog video
voltage level would exceed the maximum electrical overstress limit of the
native (thin-oxide) transistors thus causing a long-term reliability concern.
The electrical overstress condition occurs in this particular case.
This patch address the IGD EOS (electrical overstress condition) issue.
When the EOS interrupt occurs, OS should disable DAC and then disable EOS,
then the normal hotplug operation follows.
TODO: it appears the normal unplug interrupt is missed as reported by Li Peng,
need more checks here.
Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
Zhao Yakui [Mon, 24 Aug 2009 05:50:26 +0000 (13:50 +0800)]
drm/i915: Enable PAL and SECAM format and add the propery for SDVO-TV
Currently SDVO TV only support NTSC-M format. In this patch
we introduce PAL and SECAM formats available and create seting-format
property at init time. When user dynamically chose preferred
format by xrandr command, it will refine all modelines
provided by SDVO device, then instruct SDVO device to execute.
At the same time the property is added for SDVO-TV so that the SDVO-TV mode can be changed
by using xrandr.
Ma Ling [Mon, 24 Aug 2009 05:50:25 +0000 (13:50 +0800)]
drm/i915: select TV format according to connector type
For integrated TV there are 3 connector types: S-VIDEO, Composite and
Component(YprPb). Those tv formats whose component flag is true should
be assigned to Component connector, others are for S-VIDEO and Composite.
The patch intends to find appropriate tv format for each connector.
In such case it will return the correct modeline to user space. Otherwise
it will return the incorrect modeline when S-video/composite is connected.
Signed-off-by: Ma Ling <ling.ma@intel.com>
reviewed-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
Ben Gamari [Thu, 2 Jul 2009 02:26:53 +0000 (22:26 -0400)]
drm/i915: Add i915 register dumping debugfs file
Add a debugfs file to dump the entire register range. Here we
assume that reading write-only/reserved registers won't make the chip
angry. Seems to hold true, thankfully.
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net>
projects / linux-beck.git / log