Fixed brace and spacing coding style issues.
Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixed brace, macro and spacing coding style issues, and a C99 comment.
Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The device name is tightly coupled and created at the same time as the
master->unique address, so we need to free it with the master. Currently
we overwrite it each time we create a new master:

unreferenced object 0xe32c54b0 (size 32):
  comm "Xorg", pid 1455, jiffies 4294721798 (age 3196.879s)
  hex dump (first 32 bytes):
    69 39 31 35 40 70 63 69 3a 30 30 30 30 3a 30 30  i915@pci:0000:00
    3a 30 32 2e 30 00 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  :02.0.kkkkkkkkk.
  backtrace:
    [<c04e5657>] create_object+0x124/0x1f1
    [<c07cf0f0>] kmemleak_alloc+0x4c/0x90
    [<c04db84c>] __kmalloc+0x155/0x175
    [<f8316665>] drm_setversion+0x11d/0x1b1 [drm]
    [<f83148d4>] drm_ioctl+0x29a/0x356 [drm]
    [<c04f27c4>] vfs_ioctl+0x33/0x91
    [<c04f31cf>] do_vfs_ioctl+0x46b/0x496
    [<c04f3240>] sys_ioctl+0x46/0x66
    [<c040325f>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

/* A typical clean-up sequence for objects stored in an idr tree, will
 * use idr_for_each() to free all objects, if necessary, then
 * idr_remove_all() to remove all ids, and idr_destroy() to free
 * up the cached idr_layers.
 */

We were missing the vital idr_rmove_all() step and so were leaking
the used layers for every dri client:

unreferenced object 0xf32133c0 (size 148):
  comm "plymouthd", pid 131, jiffies 4294678490 (age 2308.030s)
  hex dump (first 32 bytes):
    04 00 00 00 00 00 00 00 00 00 00 00 00 40 19 f3  .............@..
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<c04e5657>] create_object+0x124/0x1f1
    [<c07cf100>] kmemleak_alloc+0x4c/0x90
    [<c04db6a9>] kmem_cache_alloc+0xee/0x13c
    [<c05c3d25>] idr_pre_get+0x24/0x61
    [<f8315c9c>] drm_gem_handle_create+0x27/0x7f [drm]
    [<f89925b2>] i915_gem_create_ioctl+0x4f/0x71 [i915]
    [<f83148ac>] drm_ioctl+0x272/0x356 [drm]
    [<c04f27c4>] vfs_ioctl+0x33/0x91
    [<c04f31cf>] do_vfs_ioctl+0x46b/0x496
    [<c04f3240>] sys_ioctl+0x46/0x66
    [<c040325f>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15803Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Trivial fix to set y1 = y2 = 0.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It looks like there is a race condition between unbinding a framebuffer
on a hotplug event and user space trying to flip:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
IP: [<ffffffffa008c7d3>] intel_crtc_page_flip+0xc9/0x39c [i915]
PGD 114724067 PUD 1145bd067 PMD 0
Oops: 0000 [#1] SMP
Pid: 10954, comm: X Not tainted 2.6.35-rc5_stable_20100714+ #1
P5Q-EM/P5Q-EM
RIP: 0010:[<ffffffffa008c7d3>]  [<ffffffffa008c7d3>]
intel_crtc_page_flip+0xc9/0x39c [i915]
RSP: 0018:ffff880114927cc8  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88012df48320 RCX: ffff88010c945600
RDX: ffff880001a109c8 RSI: ffff88010c945840 RDI: ffff88012df48320
RBP: ffff880114927d18 R08: ffff88012df48280 R09: ffff88012df48320
R10: 0000000003c2e0b0 R11: 0000000000003246 R12: ffff88010c945840
R13: ffff88012df48000 R14: 0000000000000060 R15: ffff88012dbb8000
FS:  00007f9e6078e830(0000) GS:ffff880001a00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000058 CR3: 00000001177a8000 CR4: 00000000000406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process X (pid: 10954, threadinfo ffff880114926000, task
ffff88012a4a1690)
Stack:
 ffff88010c945600 ffff880115b176c0 ffff88012db10000 0000000000000246
<0> fffffff40006101c ffff88010c945600 00000000ffffffea ffff88010c945600
<0> ffff88012df48320 ffff88011b4b6780 ffff880114927d78 ffffffffa003bd0e
Call Trace:
 [<ffffffffa003bd0e>] drm_mode_page_flip_ioctl+0x1bc/0x214 [drm]
 [<ffffffffa00311fc>] drm_ioctl+0x25e/0x35e [drm]
 [<ffffffffa003bb52>] ? drm_mode_page_flip_ioctl+0x0/0x214 [drm]
 [<ffffffff810f1c3c>] vfs_ioctl+0x2a/0x9e
 [<ffffffff810f227e>] do_vfs_ioctl+0x531/0x565
 [<ffffffff810f2307>] sys_ioctl+0x55/0x77
 [<ffffffff810e56d6>] ? sys_read+0x47/0x6f
 [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b
Code: 45 d4 f4 ff ff ff 0f 84 e0 02 00 00 48 8b 4d b0 49 8d 9d 20 03 00 00 48
89 df 49 89 4c 24 38 49 8b 07 49 89 44 24 20 49 8b 47 20 <48> 8b 40 58 49 c7 04
24 00 00 00 00 49 c7 44 24 18 a9 a5 08 a0
RIP  [<ffffffffa008c7d3>] intel_crtc_page_flip+0xc9/0x39c [i915]
 RSP <ffff880114927cc8>
CR2: 0000000000000058

References:

  Bug 28811 - [page-flipping] GPU hang when modeset after unplugging
              another monitor (under compiz)
  https://bugs.freedesktop.org/show_bug.cgi?id=28811Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There's no convenient/reliable way for drivers to both obey the dithering
mode property, and to be able to attempt to provide a good default in all
cases.

This commit adds an "auto" method to the property which drivers can default
to if they wish, whilst still allowing the user to override the choice as
they do now.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Unify debug printing so it easier to track what's happening
while debugging.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Original behaviour will be preserved for drivers that don't implement
disable() hooks for an encoder.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that highlevel DRM no longer requires PCI, we can move the requirement
into the lowlevel drivers.
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

More explicit than dpms. Same as the encoder disable function.

Need this to explicity disconnect plls from crtcs for reuse when you
plls:crtcs ratio isn't 1:1.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We don't currently update the DPMS status of the connector (both in the
connector itself and the connector's DPMS property) in the fb helper
code.  This means that if the kernel FB core has blanked the screen,
sysfs will still show a DPMS status of "on".  It also means that when X
starts, it will try to light up the connectors, but the drm_crtc_helper
code will ignore the DPMS change since according to the connector, the
DPMS status is already on.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28436 (the annoying
"my screen was blanked when I started X and now it won't light up" bug).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Connectors with a shared ddc line can be connected to different
encoders.

Reported by Pasi Kärkkäinen <pasik@iki.fi> on dri-devel
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

These helper functions can be used to efficiently scan lru list
for eviction. Eviction becomes a three stage process:
1. Scanning through the lru list until a suitable hole has been found.
2. Scan backwards to restore drm_mm consistency and find out which
   objects fall into the hole.
3. Evict the objects that fall into the hole.

These helper functions don't allocate any memory (at the price of
not allowing any other concurrent operations). Hence this can also be
used for ttm (which does lru scanning under a spinlock).

Evicting objects in this fashion should be more fair than the current
approach by i915 (scan the lru for a object large enough to contain
the new object). It's also more efficient than the current approach used
by ttm (uncoditionally evict objects from the lru until there's enough
free space).
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NThomas Hellstrom <thellstrom@vmwgfx.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are already two copies of this logic. And the new scanning
stuff will add some more. So extract it into a small helper
function.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NThomas Hellstrom <thellstrom@vmwgfx.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Yeah, I've kinda noticed that fl_entry is the free stack. Still
give it (and the memory node list ml_entry) decent names.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NThomas Hellstrom <thellstrom@vmwgfx.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NThomas Hellstrom <thellstrom@vmwgfx.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only ever assigned, never used.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[glisse: I will re-add if needed for range-restricted allocations]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NThomas Hellstrom <thellstrom@vmwgfx.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Repeated ttm_page_alloc_init/fini fails noisily because the pool
manager kobj isn't zeroed out between uses (we could do just that but
statically allocated kobjects are generally considered a bad thing).
Move it to kzalloc'ed memory.

Note that this patch drops the refcounting behavior of the pool
allocator init/fini functions: it would have led to a race condition
in its current form, and anyway it was never exploited.

This fixes a regression with reloading kms modules at runtime, since
page allocator was introduced.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Allows us to track each process that requests and completes events.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Emit a trace point for vblank events.  This can be helpful for mapping
drawing activity against the vblank frequency and period.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The refreshed patch had a copy & paste bug.
Reported-by: NSimon Farnsworth <simon.farnsworth@onelan.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since commit 4bdadb97 ("drm/i915:
Selectively enable self-reclaim"), we've been passing GFP_MOVABLE to the
i915 page allocator where we weren't before due to some over-eager
removal of the page mapping gfp_flags games the code used to play.

This caused hibernate on Intel hardware to result in a lot of memory
corruptions on resume.  See for example

  http://bugzilla.kernel.org/show_bug.cgi?id=13811

Reported-by: Evengi Golov (in bugzilla)
Signed-off-by: NDave Airlie <airlied@redhat.com>
Tested-by: NM. Vefa Bicakci <bicave@superonline.com>
Cc: stable@kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We did this a long time ago in the DDX driver, but now this fix belongs
in the kernel.

Preserving the aspect ratio is a nicer default.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=18033.
Tested-by: NJosh Triplett <josh@freedesktop.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Fixes:

drivers/gpu/drm/i915/i915_dma.c: In function ‘i915_setup_compression’:
drivers/gpu/drm/i915/i915_dma.c:1311: error: ‘compressed_llb’ may be used uninitialized in this function
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

intel_cleanup_ring_buffer() calls drm_gem_object_unreference() (as
opposed to drm_gem_object_unreference_unlocked()) so it needs to be
called with "struct_mutex" held.  If we don't hold the lock, it triggers
a BUG_ON(!mutex_is_locked(&dev->struct_mutex));

I also audited the other places that call intel_cleanup_ring_buffer()
and they all hold the lock so they're OK.

This was introduced in: 8187a2b7 "drm/i915: introduce
intel_ring_buffer structure (V2)" and it's a regression from v2.6.34.

Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16247Signed-off-by: NDan Carpenter <error27@gmail.com>
Reported-by: NBenny Halevy <bhalevy@panasas.com>
Tested-by: NBenny Halevy <bhalevy@panasas.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Commit 7a772c49 has two bugs which
made the hotplug problems on my laptop worse instead of better.

First, it did not, in fact, disable the CRT plug interrupt -- it
disabled all the other hotplug interrupts.  It seems rather doubtful
that that bit of the patch fixed anything, so let's just remove it.
(If you want to add it back, you probably meant ~CRT_HOTPLUG_INT_EN.)

Second, on at least my GM45, setting CRT_HOTPLUG_ACTIVATION_PERIOD_64
and CRT_HOTPLUG_VOLTAGE_COMPARE_50 (when they were previously unset)
causes a hotplug interrupt about three seconds later.  The old code
never restored PORT_HOTPLUG_EN so this could only happen once, but
they new code restores those registers.  So just set those bits when
we set up the interrupt in the first place.
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Signed-off-by: NEric Anholt <eric@anholt.net>

The eDP spec claims a 20% overhead for the 8:10 encoding scheme used
on the wire. Take this into account when picking the lane/clock speed
for the panel.

v3: some panels are out of spec, try our best to deal with them, don't
refuse modes on eDP panels, and try the largest allowed settings if
all else fails on eDP.
v4: fix stupid typo, forgot to git add before amending.

Fixes several reports in bugzilla:

      https://bugs.freedesktop.org/show_bug.cgi?id=28070Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The register offset for FW_BLC_SELF is a totally different set of bits
on Broadwater (it's actually MI_RDRET_STATE), so don't treat it like
FW_BLC_SELF on 965G chips.

Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=26874.

Cc: stable@kernel.org
Tested-by: NNorman Yarvin <yarvin@yarchive.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

If we fill the tail of the physical ring buffer with NOOP when wrapping,
we need to account for the reduction in available space.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Some RV100 cards with 2 VGA ports show up with DVI+VGA, however
some boards with DVI+VGA have the same subsystem ids. Better
to have a VGA port show up as DVI than having a non-useable
DVI port.

reported by DHR in irc.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=28745Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Tested-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re: [Regression, post-2.6.34] Hibernation broken on machines with radeon/KMS and r300)

There is a regression from 2.6.34 related to the recent radeon power
management changes, caused by attempting to cancel a delayed work
item that's never been scheduled.  However, the code as is has some
other issues potentially leading to visible problems.

First, the mutex around cancel_delayed_work() in radeon_pm_suspend()
doesn't really serve any purpose, because cancel_delayed_work() only
tries to delete the work's timer.  Moreover, it doesn't prevent the
work handler from running, so the handler can do some wrong things if
it wins the race and in that case it will rearm itself to do some
more wrong things going forward.  So, I think it's better to wait for
the handler to return in case it's already been queued up for
execution.  Also, it should be prevented from rearming itself in that
case.

Second, in radeon_set_pm_method() the cancel_delayed_work() is not
sufficient to prevent the work handler from running and queing up
itself for the next run (the failure scenario is that
cancel_delayed_work() returns 0, so the handler is run, it waits on
the mutex and then rearms itself after the mutex has been released),
so again the work handler should be prevented from rearming itself in
that case..

Finally, there's a potential deadlock in radeon_pm_fini(), because
cancel_delayed_work_sync() is called under rdev->pm.mutex, but the
work handler tries to acquire the same mutex (if it wins the race).

Fix the issues described above.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some IGP systems specify the system memory clock in the Firmware
table rather than the IGP info table.  Check both and make sure
we have a value system memory clock value.

v2: make sure rs690_pm_info is called on rs780/rs880 as well.

fixes a regression since 07d4190327b02ab3aaad25a2d168f79d92e8f8c2.
Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For some reason on resume, executing the BIOS scripts locks up the whole chipset, by avoiding the dynclk table the machine resumes properly and seems to function okay.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They don't have an atombios so don't attempt to use it for
eng/mem clocks.

Reported by spoonb on #radeon
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=28671Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>