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.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes (again) whole-system lockups due to GPU lockups.
Signed-off-by: NEric Anholt <eric@anholt.net>

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: NChris Wilson <chris@chris-wilson.co.uk>
CC: Eric Anholt <eric@anholt.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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: NKeith Packard <keithp@keithp.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

It seems that on IGDNG the same swizzling setup always applys.
And front buffer tiling needs to set address swizzle in display
arb control too.

Fix plane tricle feed setting in v1 which should be disable bit,
and always setup address swizzle to let hardware care for buffer
tiling in all cases.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

And clean up a small whitespace goof-up in the same function, while
I was looking at it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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: NJesse Barnes <jesse.barnes@intel.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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.

https://bugs.freedesktop.org/show_bug.cgi?id=22891Signed-off-by: NMa Ling <ling.ma@intel.com>
review-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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: NMa Ling <ling.ma@intel.com>
reviewed-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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: NBen Gamari <bgamari.foss@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NBen Gamari <bgamari.foss@gmail.com>
[anholt: hand-applied for conflicts]
Signed-off-by: NEric Anholt <eric@anholt.net>

Remember to release the local reference if we fail to wait on
the rendering.

(Also whilst in the vicinity add some whitespace so that the phasing of
the operations is clearer.)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Some i915/i945 platforms have a fairly high memory latency in certain
situations, so increase our constant a bit to avoid FIFO underruns.
The effect should be positive on other platforms as well; we'll have a
bit more insurance against a busy memory subsystem due to the extra
FIFO entries.

Fixes fdo bug #23368.  Needed for 2.6.31.
Tested-by: NSven Arvidsson <sa@whiz.se>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Set accel to none, we really don't want anyone thinking
fb is an accel interface.
Pass pitch not depth to function for intel.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Initially I always meant this code to be shared, but things
ran away from me before I got to it.

This refactors the i915 and radeon kms fbdev interaction layers
out into generic helpers + driver specific pieces.

It moves all the panic/sysrq enhancements to the core file,
and stores a linked list of kernel fbs. This could possibly be
improved to only store the fb which has fbcon on it for panics
etc.

radeon retains some specific codes used for a big endian
workaround.

changes:
fix oops in v1
fix freeing path for crtc_info
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use VBT information to determine which DDC bus to use for CRTDCC.
Fall back to GPIOA if VBT info is not available.
Signed-off-by: NDavid Müller <d.mueller@elsoft.ch>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested on: 855 (David), and 945GM, 965GM, GM45, and G45 (anholt)

The lack of a proper LRU was partially worked around by taking the fence
from the object containing the oldest seqno.  But if there are multiple
objects inactive, then they don't have seqnos and the first fence reg
among them would be chosen.  If you were trying to copy data between two
mappings, this could result in each page fault stealing the fence from
the other argument, and your application hanging.

https://bugs.freedesktop.org/show_bug.cgi?id=23566
https://bugs.freedesktop.org/show_bug.cgi?id=23220
https://bugs.freedesktop.org/show_bug.cgi?id=23253
https://bugs.freedesktop.org/show_bug.cgi?id=23366

Cc: Stable Team <stable@kernel.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Several functions in the GEM kernel API used int as handle type, but
user API has it __u32 which is also the intended type.

Replace int with u32.
Signed-off-by: NPekka Paalanen <pq@iki.fi>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Based on Bspec each encoder has different sharing pipe property,
i.e. Integrated or SDVO TV both will occupy one pipe exclusively,
and sdvo-non-tv and crt are allowed to share one. The patch moves
sharing judgment into differnet output functions, and sets the right
clone bit.

This fixes both HDMI outputs choosing the same pipe.

https://bugs.freedesktop.org/show_bug.cgi?id=22247Signed-off-by: NMa Ling <ling.ma@intel.com>
Reviewed-by : Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

After the following commit is shipped, the SDVO C detection will depend on
the SDVO_C/DP detion bit.
commit 13520b05
Author: Kristian Høgsberg <krh@redhat.com>
Date:   Fri Mar 13 15:42:14 2009 -0400

    drm/i915: Read the right SDVO register when detecting SVDO/HDMI.

According to the spec we should continue to detect the SDVO_B/C based on
the SDVO_B detection bit.  The new detection bit on G4X platform is for
the HDMI_C detection rather than SDVO_C detection.

https://bugs.freedesktop.org/show_bug.cgi?id=20639Signed-off-by: NMa Ling <ling.ma@intel.com>
Acked-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Bit SDVO_OUTPUT_SVID0 was tested twice
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Commit 0c2e3952 is not sufficient to
get fd.o bug #20115 fixed.
In addition intel_find_best_PLL() must not only rely on BIOS settings
for i9xx chips but also for i8xx, so drop the IS_I9XX() check.
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

http://bugs.freedesktop.org/show_bug.cgi?id=21417Signed-off-by: NSean Young <sean@mess.org>
Reviewed-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Now that we're using the scaling property in the Intel driver I noticed
that the names were a bit confusing.  I've corrected them according to
our discussion on IRC and the mailing list, though I've left out
potential new additions for a new scaling property with an integer (or
two) for the scaling factor.  None of the drivers implement that today,
but if someone wants to do it, I think it could be done with the
addition of a single new type and a new property to describe the
scaling factor in the X and Y directions.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

these errors are pretty pointless
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

dev_priv->saveSWF1 is a 16 element array, but this reads up to index 22,
and restored values from the wrong registers.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

We will have to add a prefix when using the macro defintion of DRM_DEBUG_KMS
/DRM_DEBUG_DRIVER/MODE. It is not convenient. We should use the DRM_NAME
as default prefix.
So remove the prefix in the macro definition of DRM_DEBUG_KMS/DRIVER/MODE.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NIan Romanick <ian.d.romanick@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This corresponds to a fix to UMS back in 2007.  Fixes fd.o bug #20115.
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The patch fixed a bug on MP965-D.  When VGA is connected to a DVI-I connector,
it incorrectly shows sdvo dvi as connected.
Signed-off-by: NMa Ling <ling.ma@intel.com>
[anholt: hand-resolved against previous commit and fixed up commit message]
Signed-off-by: NEric Anholt <eric@anholt.net>

Baed on Eric's idea in order to handle multiple sdvo encoders
we implement another approach to dynamically chose real one
encoder after detection, which is contrasted with patch -
drm/i915:Construct all possible sdvo outputs for sdvo encoder.
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

In order to get best possible quality image we chose 640x480 for
NTSC, PAL and 480p, 1280x720 for 720p, 1920x1080 for 1080i/p
TV format respectively.
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

I had one report of flicker due to FIFO underruns on 845G.  Scott was
kind enough to test a few patches and report success with this one.
Looks like 845G measures FIFO size slightly differently than other
chips, and we were also clobbering the FIFO burst length.  Fixing both
of those issues gives him a healthy machine again.

Note that we still only adjust plane A's watermark in the 830/845
case.  If someone is willing to test we could support a bigger variety
of dual-head 830/845 configurations with a bit more code.

Fixes fdo bug #19304 (again).
Reported-by: NScott Hansen <scottandchrystie@comcast.net>
Tested-by: NScott Hansen <scottandchrystie@comcast.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Check FORCE_DETECT bit to be clear for the finish
of hotplug detect process. Also check possible mono
monitor which should also be marked as connected.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>