This allows us to move duplicated code in <asm/atomic.h>
(atomic_inc_not_zero() for now) to <linux/atomic.h>
Signed-off-by: Arun Sharma <asharma@fb.com>
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (135 commits)
drm/radeon/kms: fix DP training for DPEncoderService revision bigger than 1.1
drm/radeon/kms: add missing vddci setting on NI+
drm/radeon: Add a rmb() in IH processing
drm/radeon: ATOM Endian fix for atombios_crtc_program_pll()
drm/radeon: Fix the definition of RADEON_BUF_SWAP_32BIT
drm/radeon: Do an MMIO read on interrupts when not uisng MSIs
drm/radeon: Writeback endian fixes
drm/radeon: Remove a bunch of useless _iomem casts
drm/gem: add support for private objects
DRM: clean up and document parsing of video= parameter
DRM: Radeon: Fix section mismatch.
drm: really make debug levels match in edid failure code
drm/radeon/kms: fix i2c map for rv250/280
drm/nouveau/gr: disable fifo access and idle before suspend ctx unload
drm/nouveau: pass flag to engine fini() method on suspend
drm/nouveau: replace nv04_graph_fifo_access() use with direct reg bashing
drm/nv40/gr: rewrite/split context takedown functions
drm/nouveau: detect disabled device in irq handler and return IRQ_NONE
drm/nouveau: ignore connector type when deciding digital/analog on DVI-I
drm/nouveau: Add a quirk for Gigabyte NX86T
...
DPEncoderService newer than 1.1 can't properly program the DP (display port)
link training. When facing such version use the DIGxEncoderControl method
instead. Fix DP link training on some R7XX.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to add vddci setting to pm init as well as
resume. Fixes hangs on load on some boards.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38754
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge akpm patch series: (122 commits)
drivers/connector/cn_proc.c: remove unused local
Documentation/SubmitChecklist: add RCU debug config options
reiserfs: use hweight_long()
reiserfs: use proper little-endian bitops
pnpacpi: register disabled resources
drivers/rtc/rtc-tegra.c: properly initialize spinlock
drivers/rtc/rtc-twl.c: check return value of twl_rtc_write_u8() in twl_rtc_set_time()
drivers/rtc: add support for Qualcomm PMIC8xxx RTC
drivers/rtc/rtc-s3c.c: support clock gating
drivers/rtc/rtc-mpc5121.c: add support for RTC on MPC5200
init: skip calibration delay if previously done
misc/eeprom: add eeprom access driver for digsy_mtc board
misc/eeprom: add driver for microwire 93xx46 EEPROMs
checkpatch.pl: update $logFunctions
checkpatch: make utf-8 test --strict
checkpatch.pl: add ability to ignore various messages
checkpatch: add a "prefer __aligned" check
checkpatch: validate signature styles and To: and Cc: lines
checkpatch: add __rcu as a sparse modifier
checkpatch: suggest using min_t or max_t
...
Did this as a merge because of (trivial) conflicts in
- Documentation/feature-removal-schedule.txt
- arch/xtensa/include/asm/uaccess.h
that were just easier to fix up in the merge than in the patch series.
The docs say the port has to come on in training pattern 1; at this
point, though, ->DP is in normal mode. The intent here is to wait
until the port is in fact sending data, but that doesn't happen since
we've broken the sequence the hardware expects, and the vblank wait will
time out and kvetch in the log.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The DP spec says training patterns 1 and 2 are to be sent non-scrambled,
and the GPU docs claim that happens (or at least, there's no explicit
scrambling control). But the sink may be confused if we don't
explicitly tell it what we're doing, so play it safe.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect. The
old math would give you:
scaled_width = 1600 * 768; /* 1228800 */
scaled_height = 1360 * 900; /* 1224000 */
if (scaled_width > scaled_height) { /* pillarbox, and true */
width = 1224000 / 768; /* int(1593.75) = 1593 */
x = (1600 - 1593 + 1) / 2; /* 4 */
y = 0;
height = 768;
} /* ... */
This is broken. The total width of scanout would then be 1593 + 4 + 4,
or 1601, which is wider than the panel itself. The hardware very
dutifully implements this, and you end up with a black 45° diagonal from
the top-left corner to the bottom edge of the screen. It's a cool
effect and all, but not what you wanted. Similar things happen for the
letterbox case.
The problem is that you have an integer number of pixels, which means
it's usually impossible to upscale equally on both axes. 1360/768 is
1.7708, 1600/900 is 1.7777. Since we're constrained on the one axis,
the other one wants to come out as an even number of pixels (the panel
is almost certainly even on both axes, and the x/y offsets will be
applied on both sides). In the math above, if 'width' comes out even,
rounding down is correct; if it's odd, you'd rather round up. So just
increment width/height in those cases.
Tested on a Lenovo T500 (Ironlake).
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-By: Daniel Manrique <daniel.manrique@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
Hotplug detection is a mode setting operation and must hold the
struct_mutex or risk colliding with other mode setting operations.
In particular, the display port hotplug function attempts to re-train
the link if the monitor is supposed to be running when plugged back
in. If that happens while mode setting is underway, the link will get
scrambled, leaving it in an inconsistent state.
This is a special case -- usually the driver mode setting entry points
are covered by the upper level DRM code, but in this case the function
is invoked as a work function not under the control of DRM.
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: stable@kernel.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (43 commits)
fs: Merge split strings
treewide: fix potentially dangerous trailing ';' in #defined values/expressions
uwb: Fix misspelling of neighbourhood in comment
net, netfilter: Remove redundant goto in ebt_ulog_packet
trivial: don't touch files that are removed in the staging tree
lib/vsprintf: replace link to Draft by final RFC number
doc: Kconfig: `to be' -> `be'
doc: Kconfig: Typo: square -> squared
doc: Konfig: Documentation/power/{pm => apm-acpi}.txt
drivers/net: static should be at beginning of declaration
drivers/media: static should be at beginning of declaration
drivers/i2c: static should be at beginning of declaration
XTENSA: static should be at beginning of declaration
SH: static should be at beginning of declaration
MIPS: static should be at beginning of declaration
ARM: static should be at beginning of declaration
rcu: treewide: Do not use rcu_read_lock_held when calling rcu_dereference_check
Update my e-mail address
PCIe ASPM: forcedly -> forcibly
gma500: push through device driver tree
...
Fix up trivial conflicts:
- arch/arm/mach-ep93xx/dma-m2p.c (deleted)
- drivers/gpio/gpio-ep93xx.c (renamed and context nearby)
- drivers/net/r8169.c (just context changes)
It's not clear what a sink would do if you wrote zero to this register -
which I guess would mean "I don't support any channel encodings, good
luck" - but let's not find out.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
%hx alone prints 0 as "0", not "00".
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
For parity with radeon and nouveau, and also because I suspect we're
going to need it to get format-conversion dongles right.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
No reason not to see this on g4x, after all.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We should have a read memory barrier between reading the WPTR from
memory and reading ring entries based on that value (ie, we need to
ensure both loads are done in order by the CPU).
It could be argued that the MMIO reads in r600_ack_irq() might be
enough to get that barrier but I prefer keeping an explicit one just
in case.
[airlied: fix evergreen + r/w mixup]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
v6 of the structure was programmed incorrectly:
args.v6.ulCrtcPclkFreq.ulPixelClock = cpu_to_le32(clock / 10);
ulPixelClock is a 24-bit bitfield. This statement would thus
do a 32-bit swap of (clock / 10) and drop the top 8 bits which
are ... the LSB. Not what we want. Instead use masks & shifts.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(Note that this is duplicated under various other names such
as R600_BUF_SWAP_32BIT etc...). At least now all the definitions
agree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When not using MSIs, there is no guarantee that DMA from the device
has been fully flushed to point where it's visible to the CPU when
taking an interrupt. To get this guarantee, we need to perform an
MMIO read from the device, which will flush all outstanding DMAs
from bridges between the device and the system.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The writeback ring pointer and IH ring pointer are read using le32_to_cpu
so we do not want the chip to byteswap them on big-endian.
We still want to byteswap the ring itself and the IBs, so we don't touch
that but we remove setting of the byteswap bits in CP_RB_RPTR_ADDR and
IH_CNTL.
In general, for things like that where we control all the accessors easily,
we are better off doing the swap in SW rather than HW. Paradoxally, it does
keep the code closer to x86 and avoid using poorly tested HW features.
I also changed the use of RADEON_ to R600_ in a couple of cases to be more
consistent with the surrounding code.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just defining rdev->rmmio properly in the first place should do
the trick. In some cases, the cast were also complete dups as
the original variable was already of the right type.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These small changes should allow GEM to be used with non shmem objects as
well as shmem objects. In the GMA500 case it allows the base framebuffer to
appear as a GEM object and thus acquire a handle and work with KMS.
For i915 it ought to be trivial to get back the wasted memory but putting the
system fb back into stolen RAM and in general I can imagine it allowing the
use of GEM and thus KMS with all the older cards that have their framebuffer
firmly placed in video RAM.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Tested-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The video= parameter of the DRM drivers supports some additional flags that
the normal fb drivers do not have. They also allow to limit these flags to
specific outputs. Both things were previously undocumented.
Also the parsing of the line had some oddities:
-A lot of misplaced options were silently ignored or partly rejected instead
of stopping the parsing immediately
-The 'R' option is documented to follow the 'M' option if specified. It is not
documented that 'M' is needed to specify 'R' (also this is the case for normal
fb drivers). In fact the code is correct for normal fb drivers but wrong for
DRM ones.
The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only
if 'M' is given at all which is not needed for the DRM drivers.
-the margins option ('m') was parsed but later ignored even if the later
functions support it.
-specifying multiple enable options at the same time did not lead to an error.
-specifying something bogus for horizontal resolution (i.e. other things as
digits) did not lead to an error but an invalid resolution was used.
If any errors are encountered the position of the faulting string is now
printed to the user and the complete mode is ignored. This gives much
more consistent error behaviour.
I also removed some useless assignments and changed the local flag variables
to be bool.
Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
WARNING: drivers/gpu/drm/radeon/radeon.o(.text+0x5d1fc): Section mismatch in reference from the function radeon_get_clock_info() to the function .devinit.text:radeon_read_clocks_OF()
The function radeon_get_clock_info() references
the function __devinit radeon_read_clocks_OF().
This is often because radeon_get_clock_info lacks a __devinit
annotation or the annotation of radeon_read_clocks_OF is wrong.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Also disable the ascii dump and remove the literal printing of the
KERN_ERR macro in the log:
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
v2: Remove the trailing empty line as well.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/gr: disable fifo access and idle before suspend ctx unload
drm/nouveau: pass flag to engine fini() method on suspend
drm/nouveau: replace nv04_graph_fifo_access() use with direct reg bashing
drm/nv40/gr: rewrite/split context takedown functions
drm/nouveau: detect disabled device in irq handler and return IRQ_NONE
drm/nouveau: ignore connector type when deciding digital/analog on DVI-I
drm/nouveau: Add a quirk for Gigabyte NX86T
drm/nouveau: do not leak in nv20_graph_create
drm/nv50/dp: fix hack to work for macbooks booted via EFI
It may not be necessary to fail in certain cases (such as failing to idle)
on module unload, whereas on suspend it's important to ensure a consistent
state can be restored on resume.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It's completely pointless to save the PGRAPH context when destroying a
channel, so don't bother.
This commit should also fix kernel.org bug 39422, where the DRM channel
state was incorrectly being saved because we left PGRAPH FIFO access
enabled while running the ctxprog.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If the connector table is lying, which it often does on the boards of a
particular manufacturer, we may end up doing the wrong thing. Listen
to the encoder table instead, it's more reliable.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The connector table lies, the card has DVI-I not HDMI
Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=35675
v2: Mention the bugreport
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If we return due to an unknown chipset in
drivers/gpu/drm/nouveau/nv20_graph.c:nv20_graph_create() we'll leak the
memory allocated to 'pgraph'.
This patch should fix the leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Reviewed-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Physically-addressed hardware status pages are initialized early in
the driver load process by i915_init_phys_hws. For UMS environments,
the ring structure is not initialized until the X server starts. At
that point, the entire ring structure is re-initialized with all new
values. Any values set in the ring structure (including
ring->status_page.page_addr) will be lost when the ring is
re-initialized.
This patch moves the initialization of the status_page.page_addr value
to intel_render_ring_init_dri.
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: stable@kernel.org
Failing to pin a scanout buffer will most likely lead to a black
screen, so if the GPU is wedged, then just let the pin happen and hope
that things work out OK.
v2: Just ignore any error from i915_gem_object_wait_rendering, as
suggested by Chris Wilson
Signed-off-by: Keith Packard <keithp@keithp.com>
If a mode set fails we may get a message from drm_crtc_helper if we're lucky,
but it won't tell us anything about *why* we failed to set a mode. So
add a few DRM_ERRORs for the cases that shouldn't happen so we can debug
things more easily.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
All these are instances of
#define NAME value;
or
#define NAME(params_opt) value;
These of course fail to build when used in contexts like
if(foo $OP NAME)
while(bar $OP NAME)
and may silently generate the wrong code in contexts such as
foo = NAME + 1; /* foo = value; + 1; */
bar = NAME - 1; /* bar = value; - 1; */
baz = NAME & quux; /* baz = value; & quux; */
Reported on comp.lang.c,
Message-ID: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com>
Initial analysis of the dangers provided by Keith Thompson in that thread.
There are many more instances of more complicated macros having unnecessary
trailing semicolons, but this pile seems to be all of the cases of simple
values suffering from the problem. (Thus things that are likely to be found
in one of the contexts above, more complicated ones aren't.)
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Align unfenced buffers on older hardware to the power-of-two object
size. The docs suggest that it should be possible to align only to a
power-of-two tile height, but using the already computed fence size is
easier and always correct. We also have to make sure that we unbind
misaligned buffers upon tiling changes.
In order to prevent a repetition of this bug, we change the interface
to the alignment computation routines to force the caller to provide
the requested alignment and size of the GTT binding rather than assume
the current values on the object.
Reported-and-tested-by: Sitosfe Wheeler <sitsofe@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36326
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
The 3D driver need to get the pipe to backend
map to certain things. Add a query to get the
info.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Include the device id in the bus-id to give userspace a way to open
the correct "cardN" when there are multiple device instances.
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We've tried several times to make this machine 'just work', but every
patch that does causes many other machines to fail. This adds a quirk
which special cases this hardware and forces ssc to be
disabled. There's no way to override this from the command line; that
would be a significantly more invasive change.
This patch fixes#36656 on fdo bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=36656
Signed-off-by: Keith Packard <keithp@keithp.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36656
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use the fence of the new frontbuffer, if any.
Generating a new fence could cause us to wait for completely unrelated
rendering to finish before performing the flip.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-next' of ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: (52 commits)
drm/i915: provide module parameter description
drm/i915: add module parameter compiler hints
drm/i915/bios: Avoid temporary allocation whilst searching for downclock
drm/i915: Cache GT fifo count for SandyBridge
i915: Fix opregion notifications
drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
drm/i915: Select correct pipe during TV detect
drm/i915/ringbuffer: Idling requires waiting for the ring to be empty
Revert "drm/i915: enable rc6 by default"
drm/i915: Clean up i915_driver_load failure path
drm/i915: Enable i915 frame buffer compression by default
drm/i915: Share the common work of disabling active FBC before updating
drm/i915: Perform intel_enable_fbc() from a delayed task
drm/i915: Disable FBC across page-flipping
drm/i915: Set persistent-mode for ILK/SNB framebuffer compression
drm/i915: Use of a CPU fence is mandatory to update FBC regions upon CPU writes
drm/i915: Remove vestigial pitch from post-gen2 FBC control routines
drm/i915: Replace direct calls to vfunc.disable_fbc with intel_disable_fbc()
drm/i915: Only export the generic intel_disable_fbc() interface
drm/i915: Enable GPU reset on Ivybridge.
...
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms/evergreen: emit SQ_LDS_RESOURCE_MGMT for blits
agp/intel: Fix typo in G4x_GMCH_SIZE_VT_2M
drm/radeon/kms: fix typo in read_disabled vbios code
drm/radeon/kms: use correct BUS_CNTL reg on rs600
drm/radeon/kms: fix backend map typo on juniper
drm/radeon/kms: fix regression in hotplug
Alan Cox reported a missing check on the kmalloc return value for the
allocation of a temporary mode used for searching for the LVDS downlock
frequency. This allocation is roughly 200 bytes, a little too large to
friviously place on the stack. However, we can simply use the few bytes
we need stored within the original DVO timing data, skip the translation
and do the compare directly between the timing data rather than on a
mode, thus avoiding the need for any temporary allocations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The read back of the available FIFO entries is vital for system
stability, but extremely costly. However, we only need a guide so as to
avoid eating into the reserved entries and since we are the only
consumer we can cache the read of the count from the last write.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
opregion-based platforms will send ACPI video event 0x80 for a range of
notification types for legacy compatibility. This is interpreted as a
display switch event, which may not be appropriate in the circumstances.
When we receive such an event we should make sure that the platform is
genuinely requesting a display switch before passing that event through
to userspace.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Yi Sun <yi.sun@intel.com>
drm_pci_device_is_pcie duplicates the funcationality of pci_is_pcie.
Convert callers of the former to the latter. This has the side benefit
of removing an unnecessary search in the PCI configuration space due to
using a saved PCIe capability offset.
[airlied: update for new callsite]
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Compute drivers may change this, so make sure to emit it to
avoid errors in bo blits.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39119
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915/ringbuffer: Idling requires waiting for the ring to be empty
Revert "drm/i915: enable rc6 by default"
drm/i915: Clean up i915_driver_load failure path
drm/i915: Enable GPU reset on Ivybridge.
drm/i915/dp: manage sink power state if possible
drm/i915/dp: consolidate AUX retry code
drm/i915/dp: remove DPMS mode tracking from DP
drm/i915/dp: try to read receiver capabilities 3 times when detecting
drm/i915/dp: read more receiver capability bits on hotplug
drm/i915/dp: use DP DPCD defines when looking at DPCD values
drm/i915/dp: retry link status read 3 times on failure
...which is measured by the size and not the amount of space remaining.
Waiting upon size-8, did one of two things. In the common case with more
than 8 bytes available to write into the ring, it would return
immediately. Otherwise, it would timeout given the impossible condition
of waiting for more space than is available in the ring, leading to
warnings such as:
[drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring
whilst cleaning up: -16
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit a51f7a66fb.
We still have a few Ironlake and Sandybridge machines which fail when
RC6 is enabled. Better luck next release?
Signed-off-by: Keith Packard <keithp@keithp.com>
i915_driver_load adds a write-combining MTRR region for the GTT
aperture to improve memory speeds through the aperture. If
i915_driver_load fails after this, it would not have cleaned up the
MTRR. This shouldn't cause any problems, except for consuming an MTRR
register. Still, it's best to clean up completely in the failure path,
which is easily done by calling mtrr_del if the mtrr was successfully
allocated.
i915_driver_load calls i915_gem_load which register
i915_gem_inactive_shrink. If i915_driver_load fails after calling
i915_gem_load, the shrinker will be left registered. When called, it
will access freed memory and crash. The fix is to unregister the shrinker in the
failure path using code duplicated from i915_driver_unload.
i915_driver_load also has some incorrect gotos in the error cleanup
paths:
* After failing to initialize the GTT (which cannot happen, btw,
intel_gtt_get returns a fixed (non-NULL) value), it tries to
free the uninitialized WC IO mapping. Fixed this by changing the
target from out_iomapfree to out_rmmap
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Lin Ming <ming.m.lin@intel.com>
BUS_CNTL reg and bits moved between pre-PCIE and PCIE asics.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Skip connectors that do not have an HPD pin.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=39027
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
evergreen+ asics have 2-6 crtcs. Don't access crtc registers
for crtc regs that don't exist as they have very high latency
and may cause problems on some asics. The previous code missed
a few cases and was not fine grained enough (missed the 4 crtc
case for example).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
v2: fix typo noticed by Chris Bandy <cbandy@jbandy.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Tested-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Upon review, all path share the same dependencies for updating the
registers and so we can benefit from sharing the code and checking
early.
This removes the unsightly intel_wait_for_vblank() from the lowlevel
functions and upon further analysis the only path that will require a
wait is if we are performing an instantaneous transition between two
valid FBC configurations. The page-flip path itself will have disabled
FBC registers and will have waited for at least one vblank before
finishing the flip and attempting to re-enable FBC. This wait can be
accomplished simply by delaying the enable until after we are sure that
a vblank will have passed, which we are already doing to make sure that
the display is settled before enabling FBC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
In order to accommodate the requirements of re-enabling FBC after
page-flipping, but to avoid doing so and incurring the cost of a wait
for vblank in the middle of a page-flip sequence, we defer the actual
enablement by 50ms. If any request to disable FBC arrive within that
interval, the enablement is cancelled and we are saved from blocking on
the wait.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Page-flipping updates the scanout address, nukes the FBC compressed
image and so forces an FBC update so that the displayed image remains
consistent. However, page-flipping does not update the FBC registers
themselves, which remain pointing to both the old address and the old
CPU fence. Future updates to the new front-buffer (scanout) are then
undetected!
This first approach to demonstrate the issue and highlight the fix,
simply disables FBC upon page-flip (a recompression will be forced on
every flip so FBC becomes immaterial) and then re-enables FBC in the
page-flip finish work function, so that the FBC registers are now
pointing to the new framebuffer and front-buffer rendering works once
more.
Ideally, we want to only re-enable FBC after page-flipping is complete,
as otherwise we are just wasting cycles and power (with needless
recompression) whilst the page-flipping application is still running.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33487
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Persistent mode is intended for use with front-buffer rendering, such as
X, where it is necessary to detect writes to the scanout either by the
GPU or through the CPU's fence, and recompress the dirty regions on the
fly. (By comparison to the back-buffer rendering, the scanout is always
recompressed after a page-flip.)
References: https://bugs.freedesktop.org/show_bug.cgi?id=33487
References: https://bugs.freedesktop.org/show_bug.cgi?id=31742
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
...and this requirement is enforced by intel_update_fbc() so we can
remove the later check from g4x_enable_fbc() and ironlake_enable_fbc().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The cfb_pitch was only used for 8xx_enable_fbc(), every later routine
was just overwriting the value with itself thanks to a copy'n'paste
error.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
...to ensure that any pending FBC enable tasklet is cancelled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
As the enable/disable routines will be gain additional complexity in
future patches, it is necessary that all callers do not bypass the
generic interface by calling into the chipset routines directly. to do
this we make the chipset routines static, so there is no choice.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
According to the hardware documentation, GDRST is exactly the same as on
Sandybridge. So simply enable the existing code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
On sinks with a DPCD rev of 1.1 or greater, we can send sink power
management commands to address 0x600 per section 5.1.5 of the
DisplayPort 1.1a spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When checking link status during a hot plug event or detecting sink
presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a
DisplayPort spec). Consolidate the retry code into a
native_aux_read_retry function for use by get_link_status and _detect.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We currently use this when a hot plug event is received, only checking
the link status and re-training if we had previously configured a link.
However if we want to preserve the DP configuration across both hot plug
and DPMS events (which we do for userspace apps that don't respond to
hot plug uevents), we need to unconditionally check the link and try to
bring it up on hot plug.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If ->detect is called too soon after a hot plug event, the sink may not
be ready yet. So try up to 3 times with 1ms sleeps in between tries to
get the data (spec dictates that receivers must be ready to respond within
1ms and that sources should try 3 times).
See section 9.1 of the 1.1a DisplayPort spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When a hotplug event is received, we need to check the receiver cap bits
in case they've changed (as they might with a hub or chain config).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Makes it easier to search for DP related constants.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Especially after a hotplug or power status change, the sink may not
reply immediately to a link status query. So retry 3 times per the spec
to really make sure nothing is there.
See section 9.1 of the 1.1a DisplayPort spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Now that we track bpp on a per-pipe basis, we can use the actual value
rather than assuming 24bpp.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This will catch bad fb configs earlier.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
To properly drive a framebuffer with a new depth or bpp, dither settings
and link bandwidth calculations may change, so make sure we go through a
full mode set in that case.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
The Intel HDMI encoder can support 8bpc or 12bpc. Set the appropriate
value based on the pipe bpp when configuring the output.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
The pipe may be driving various bpp values depending on the display
configuration, so take that into account when calculating link bandwidth
requirements.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Updating the planes is device specific, so create a new display callback
and use it in pipe_set_base. (In fact we could go even further, valid
display plane bits have changed with each generation, as has tiled
buffer handling.)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Figuring out which pipe bpp to use is a bit painful. It depends on both
the encoder and display configuration attached to a pipe. For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
on the pipe but also enable dithering. But driving that same
framebuffer to a DisplayPort output on another pipe means using 8bpc and
no dithering.
So split out and enhance the code to handle the various cases, returning
an appropriate pipe bpp as well as whether dithering should be enabled.
Save the resulting pipe bpp in the intel_crtc struct for use by encoders
in calculating bandwidth requirements (defaults to 24bpp on pre-ILK).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This may not be the default value, so pull the bpc out of the pipe reg
and write it to the DP transcoder so proper dithering and signaling
occurs.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This prevents us from setting reserved or incorrect bits on CougarPoint.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
These bits are reserved on ILK+ (ILK+ provides this feature in the
transcoder and pipe configuration instead, which we already set).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Sometimes we could be controlling a device (such as an NVIDIA Tesla) that
has no crtcs/encoders/connectors.
One could argue that the driver should unset DRIVER_MODESET in this case,
but that changes a whole heap of the DRM's other behaviours, and it's much
easier to just be a modesetting driver without any outputs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ib pool weren't free for various newer asic on module unload.
This doesn't cause much arm but still could be candidate for
stable.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
cc: stable@kernel.org
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
Revert "drm/nvc0: recognise 0xdX chipsets as NV_C0"
drm/radeon/kms: fix typo in cayman reg offset
drm/radeon/kms: use correct reg on fusion when reading back mem config
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: apply HWSTAM writes to Ivy Bridge as well
drm/i915: move IRQ function table init to i915_irq.c
drm/i915/overlay: Fix unpinning along init error paths
drm/i915: Don't call describe_obj on NULL pointers
drm/i915: Hold struct_mutex during i915_save_state/i915_restore_state
In an attempt to fix 38862 and 38863.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This lets us make the various IRQ functions static and helps avoid
problems like the one fixed in "drm/i915: Use chipset-specific irq
installers" where one of the exported functions was called rather than
the chipset specific version.
This also fixes a UMS-mode bug -- the correct irq functions for IRL
and later chips were only getting loaded in the KMS path.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
As pointed out by Dan Carpenter, it was seemingly possible to hit an error
whilst mapping the buffer for the regs (except the only likely error
returns should not happen during init) and so leak a pin count on the
bo. To handle this we would need to reacquire the struct mutex, so for
simplicity rearrange for the lock to be held for the entire function.
For extra pedagogy, test that we only call init once.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The vbios rom is >64k on a lot of modern asics. Increase
the fetch size for atrm to make sure we don't miss part
of a larger rom.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
They use the same register interfaces, so we can simply enable the
existing code on IVB.
v2:
- resolve conflict with ring freq scaling, we can enable it too
v3:
- resolve conflict again, this time on drm-intel-next
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reported-by: Pavel Roskin <proski@gnu.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38777
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Lots of register access in these functions, some of which requires the
struct mutex.
These functions now hold the struct mutex across the calls to
i915_save_display and i915_restore_display, and so the internal mutex
calls in those functions have been removed. To ensure that no-one else
was calling them (and hence violating the new required locking
invarient), those functions have been made static.
gen6_enable_rps locks the struct mutex, and so i915_restore_state
unlocks the mutex around calls to that function.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Provide a parameter to disable hanghcheck. This is useful mostly for
developers trying to debug known problems, and probably should not be
touched by normal users.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
The ring frequency scaling table tells the PCU to treat certain GPU
frequencies as if they were a given CPU frequency for purposes of
scaling the ring frequency. Normally the PCU will scale the ring
frequency based on the CPU P-state, but with the table present, it will
also take the GPU frequency into account.
The main downside of keeping the ring frequency high while the CPU is
at a low frequency (or asleep altogether) is increased power
consumption. But then if you're keeping your GPU busy, you probably
want the extra performance.
v2:
- add units to debug table header (from Eric)
- use tsc_khz as a fallback if the cpufreq driver doesn't give us a freq
(from Chris)
v3:
- fix comments & debug output
- remove unneeded force wake get/put
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Konstantin Belousov pointed out that 4697995b98 replaced the generic
i915_driver_irq_*install() functions with chipset specific routines
accessible only through driver->irq_*install(). So update the sanity
check in i915_request_wait() to match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
The failure is as follows:
1. Userspace gets forcewake lock, lock count >=1
2. GPU hang/reset occurs (forcewake bit is reset)
3. count is now incorrect
The failure can only occur when using the forcewake userspace lock.
This has the unfortunate consequence of messing up the driver as well as
userspace, unless userspace closes the debugfs file, the kernel will
never end up waking the GT since the refcount will be > 1.
The solution is to try to recover the correct forcewake state based on
the refcount. There is a period of time where userspace reads/writes may
occur after the reset, before the GT has been forcewaked. The interface
was never designed to be a perfect solution for userspace reads/writes,
and the kernel portion is fixed by this patch.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
When auditing the locking in i915_gem.c (for a prospective change which
I then abandoned), I noticed two places where struct_mutex is not held
across GEM object manipulations that would usually require it.
Since one is in initial setup and the other in driver unload, I'm
guessing the mutex is not required for either; but post a patch in case
it is.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The interface to ->truncate_range is changing very slightly: once "tmpfs:
take control of its truncate_range" has been applied, this can be applied.
For now there is only a slight inefficiency while this remains unapplied,
but it will soon become essential for managing shmem's use of swap.
Change i915_gem_object_truncate() to use shmem_truncate_range() directly:
which should also spare i915 later change if we switch from
inode_operations->truncate_range to file_operations->fallocate.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Soon tmpfs will stop supporting ->readpage and read_cache_page_gfp(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.
Make i915_gem_object_get_pages_gtt() use shmem_read_mapping_page_gfp() in
the one place it's needed; elsewhere use shmem_read_mapping_page(), with
the mapping's gfp_mask properly initialized.
Forget about __GFP_COLD: since tmpfs initializes its pages with memset,
asking for a cold page is counter-productive.
Include linux/shmem_fs.h also in drm_gem.c: with shmem_file_setup() now
declared there too, we shall remove the prototype from linux/mm.h later.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Soon tmpfs will stop supporting ->readpage and read_mapping_page(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.
ttm_tt_swapin() and ttm_tt_swapout() use shmem_read_mapping_page() in
place of read_mapping_page(), since their swap_space has been created with
shmem_file_setup().
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When auditing the locking in i915_gem.c (for a prospective change which I
then abandoned), I noticed two places where struct_mutex is not held
across GEM object manipulations that would usually require it. Since one
is in initial setup and the other in driver unload, I'm guessing the mutex
is not required for either; but post a patch in case it is.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This makes things a little clearer and prevents us from running old code
on a new chipset that may not be supported.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewied-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Two of these error paths returned without freeing "ctx".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
'drm/nouveau: rework vram init/fini ordering a little' changed
the order of instmem.init() and nouveau_mem_vram_init() which
resulted in using ramin_rsvd_vram before it was calculated and
failing to init any accel on pre-NV50 cards.
Since it's only used on <NV50 just calculate it where it's needed
and leave it as default 0 for NV50.
Signed-off-by: Younes Manton <younes.m@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It's a regression from "drm/nouveau: create temp vmas for both src and
dst of bo moves".
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: save/resume forcewake lock fixes
Revert "drm/i915: Kill GTT mappings when moving from GTT domain"
drm/i915: Apply HWSTAM workaround for BSD ring on SandyBridge
drm/i915: Call intel_enable_plane from i9xx_crtc_mode_set (again)
Even if the object is no longer in the GTT domain, there may still be
a user space mapping which needs to be released.
Without this fix, render-based text (mostly in firefox) would
occasionally get corrupted when the system was under load.
Signed-off-by: Keith Packard <keithp@keithp.com>
A voltage value of 0xff01 requires that the driver
look up the max voltage for the board based using the
atom SetVoltage command table.
Setting the proper voltage should fix stability on
some newer asics.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The field is encoded:
0 = 4 banks
1 = 8 banks
2 = 16 banks
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
