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>

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>

HDP non surface should cover the whole VRAM but we were misscomputing
the size and we endup in some case not covering the VRAM at all (if
VRAM size were > 1G). Covering more than the VRAM size shouldn't be
an issue.

Fix : https://bugs.freedesktop.org/show_bug.cgi?id=28016

[airlied: add evergreen fix]
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Should fix fdo bug 28331:
https://bugs.freedesktop.org/show_bug.cgi?id=28331Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since the VGA switcheroo, we'd attempt to read the BIOS from VRAM on startup
but on some unposted cards this can cause hangs/crashes.

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

(further problem pointed out by agd5f on IGP systems)

Reported-by: Reilithion on #radeon
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

We were returning 0 in both the success and failure paths. Noticed while
investigating FDO bug 26403.
Signed-off-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Non pooled page allocation should have GFP_USER set so allocation
can wait and reclaim page from other process (ie non atomic).
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This needs similar handling to other compressed textures.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26428

Signed-off-by: sroland@vmware.com
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Code did not handle projected 2d and depth coordinates, meaning potentially
set 3d or cube special handling might stick.
(Not sure what depth coord actually does, but I guess handling it
like a normal coordinate is the right thing to do.)
Might be related to https://bugs.freedesktop.org/show_bug.cgi?id=26428

Signed-off-by: sroland@vmware.com
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=28459

agd5f: apply to r1xx/r2xx as well.
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>
Cc: stable@kernel.org
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This works well enough on a js21, but it would be nice if IBM could supply
more tables for the later Power6/7 machines.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reduced blanking is valid only when doing CVT modes.  Also, generate GTF
modes unless CVT was requested; CVT devices are required to support GTF,
but the reverse is not true.

[airlied: fix typo]
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The transmitter needs to be enabled before the link is trained.
Reported-By: NLars Doelle <lars.doelle@on-line.de>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When suspending, we turn the display hw off, at resume the screen will stay black.
This patch turn it on. Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16180Signed-off-by: NCedric Godin <cedric.godin@skynet.be>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

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