On eDP, DDC requires panel power, but turning that on uses the panel
power sequencing timing values fetch from the DPCD data.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the panel is already off, we'll need to turn VDD on to execute the
(useless) DPMS off code. Yes, it would be better to just not do any of
this, but correctness, and *then* performance.
Signed-off-by: Keith Packard <keithp@keithp.com>
The HPD pin is not reliable for detecting whether a monitor
is connected or not. Skip HPD and just use DDC or load
detection.
Fixes phantom VGA connected bugs.
[Michel: fixes phantom VGA bugs on his llano system.]
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
If there are error flags in the aux status, retry the transaction.
This makes aux much more reliable, especially on llano systems.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
only FIMD yet but we will add HDMI support also in the future.
this patch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-next
commit-id: 88ef4e3f4f
you can refer to our working repository below:
http://git.infradead.org/users/kmpark/linux-2.6-samsung
branch name: samsung-drm
We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
based on Linux framebuffer) but couldn't so because lowlevel codes
of s3c-fb.c are included internally and so FIMD module of this driver has
its own lowlevel codes.
We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
for buffer allocation so we can allocate physically continuous memory
for DMA through it and also we could use CMA later if CMA is applied to
mainline.
Refer to this link for CMA(Continuous Memory Allocator):
http://lkml.org/lkml/2011/7/20/45
this driver supports only physically continuous memory(non-iommu).
Links to previous versions of the patchset:
v1: < https://lwn.net/Articles/454380/ >
v2: < http://www.spinics.net/lists/kernel/msg1224275.html >
v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >
v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >
v5: < http://comments.gmane.org/gmane.comp.video.dri.devel/60802 >
Changelog v2:
DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
this feature maps user address space to physical memory region
once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
DRM: code clean and add exception codes.
Changelog v3:
DRM: Support multiple irq.
FIMD and HDMI have their own irq handler but DRM Framework can regiter
only one irq handler this patch supports mutiple irq for Samsung SoC.
DRM: Consider modularization.
each DRM, FIMD could be built as a module.
DRM: Have indenpendent crtc object.
crtc isn't specific to SoC Platform so this patch gets a crtc
to be used as common object.
created crtc could be attached to any encoder object.
DRM: code clean and add exception codes.
Changelog v4:
DRM: remove is_defult from samsung_fb.
is_default isn't used for default framebuffer.
DRM: code refactoring to fimd module.
this patch is be considered with multiple display objects and
would use its own request_irq() to register a irq handler instead of
drm framework's one.
DRM: remove find_samsung_drm_gem_object()
DRM: move kernel private data structures and definitions to driver folder.
samsung_drm.h would contain only public information for userspace
ioctl interface.
DRM: code refactoring to gem modules.
buffer module isn't dependent of gem module anymore.
DRM: fixed security issue.
DRM: remove encoder porinter from specific connector.
samsung connector doesn't need to have generic encoder.
DRM: code clean and add exception codes.
Changelog v5:
DRM: updated fimd(display controller) driver.
added various pixel formats, color key and pixel blending features.
DRM: removed end_buf_off from samsung_drm_overlay structure.
this variable isn't used and end buffer address would be
calculated by each sub driver.
DRM: use generic function for mmap_offset.
replaced samsung_drm_gem_create_mmap_offset() and
samsung_drm_free_mmap_offset() with generic ones applied
to mainline recentrly.
DRM: removed unnecessary codes and added exception codes.
DRM: added comments and code clean.
Changelog v6:
DRM: added default config options.
DRM: added padding for 64-bit align.
DRM: changed prefix 'samsung' to 'exynos'
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make surfaces swappable. Make sure we honor the maximum amount of surface
memory the device accepts. This is done by potentially reading back surface
contents not used by the current command submission and storing it
locally in buffer objects.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use a list for resources referenced during command submission, instead of
an array.
As long as we don't implement parallell command submission this works fine
and simplifies things a bit.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Previously, query results could be placed in any buffer object, but since
we didn't allow pinned buffer objects, query results could be written when
that buffer was evicted, corrupting data in other buffers.
Now, require that buffers holding query results are no more than two pages
large, and allow one single pinned such buffer. When the command submission
code encounters query result structures in other buffers, the queries in the
pinned buffer will be finished using a query barrier for the last hardware
context using the buffer. Also if the command submission code detects
that a new hardware context is used for queries, all queries of the previous
hardware context is also flushed. Currently we use waiting for a no-op
occlusion query as a query barrier for a specific context.
The query buffer is also flushed and unpinned on context destructions,
master drops and before scanout bo placement.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The execbuf utils may call reference on NULL fence objects.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add / fix some function comments.
Don't move out an fbdev framebuffer when unused. Just unpin.
Only have a single function that computes a SVGAGuestPtr from the buffer's
current placement, and make it more versatile by accepting a
struct ttm_buffer_object
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we hae screen objects we are allowed to place the overlay source
in the GMR area, do this as this will save precious VRAM.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since 3D requires HWv8 and screen objects is always available on those
hosts we only need the screen objects path for surfaces.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On lower versions, the way we mix 2D and 3D may be too slow.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
More preparation for Screen Object support.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In preperation for screen objects, still leaves the delayed workqueue
for surface updates in place.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This will make it easier to execute commands operating on user-space
resources but generated by the kernel.
JB: Added tracking if the sw_context was called from the kernel or userspace.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Most asics just use the hw default value which requires
no explicit programming. For those that need a different
value, the vbios will program it properly. As such,
there's no need to program these registers explicitly
in the driver. Changing MC_SHARED_CHREMAP requires a reload
of all data in vram otherwise its contents will be scambled.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=40103
v2: drop now unused channel_remap functions.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Apart from the obvious cleanup, this should make the line
cursor_end = x - xorigin + w;
correct now.
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>
Fixes cursor disappearing prematurely when moving off a top/left edge which
is not located at the desktop top/left edge.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
The mouse cursor hotspot calculation when the cursor is partially off the
top or left side of the screen was off by one.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41158
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Only disable the pipe if the monitor is physically
disconnected. The previous logic also disabled the
pipe if the link was trained.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41248
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The previous code could potentially loop forever. Limit
the number of DP aux defer retries to 4 for native aux
transactions, same as i2c over aux transactions.
Noticed by: Brad Campbell <lists2009@fnarfbargle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Brad Campbell <lists2009@fnarfbargle.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
An incorrect ordering in the error checking code lead
to DP aux defer being skipped in the aux native write
path. Move the bytes transferred check (ret == 0)
below the defer check.
Tracked down by: Brad Campbell <brad@fnarfbargle.com>
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Brad Campbell <brad@fnarfbargle.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The VDD force bit is turned on before touching the panel, but if it
was enabled, there was no call to turn it back off. Add a call.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard <keithp@keithp.com>
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard <keithp@keithp.com>
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This masks out all interrupts and ack's any pending ones at IRQ
uninstall time to make sure we don't receive any unexpected interrupts
later on.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux:
drm/i915: FBC off for ironlake and older, otherwise on by default
drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
drm/i915: Enable dither whenever display bpc < frame buffer bpc
The reference clock configuration must be done before any mode setting
can occur as all outputs must be disabled to change
anything. Initialize the clocks after turning everything off during
the initialization process.
Also, re-initialize the refclk at resume time.
Signed-off-by: Keith Packard <keithp@keithp.com>
I can't find any reference clocks which run at 96MHz as seems to be
indicated from the comments in this code.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
When trying to use SSC on Ibex Peak without CK505, any non-SSC outputs
(like VGA or TV) get broken. So, do not use SSC on Ibex Peak unless
there is a CK505 available (as specified by the VBT).
On Cougar Point, all clocking is internal, so SSC can always be used,
and there will never be a CK505 available.
This eliminates VGA shimmer on some Ironlake machines which have a
CK505 clock source.
References: https://bugzilla.kernel.org/show_bug.cgi?id=21742
References: https://bugs.freedesktop.org/show_bug.cgi?id=38750
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
The PCH refclk settings are global, so we need to look at all of the
encoders, not just the current encoder when deciding how to configure
it. Also, handle systems with more than one panel (any combination of
PCH/non-PCH eDP and LVDS).
Disable SSC clocks when no panels are connected.
Signed-off-by: Keith Packard <keithp@keithp.com>
Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This includes whether an eDP panel is present, and whether that should
use SSC (and at what frequency)
Signed-off-by: Keith Packard <keithp@keithp.com>
This tells the driver whether a CK505 clock source is available on
pre-PCH hardware. If so, it should be used as the non-SSC source,
leaving the internal clock for use as the SSC source.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wison <chris@chris-wilson.co.uk>
These are all KMS related anyways, so don't hide them under other
debug levels.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
DVOOutputControl checks the value of of bios scratch reg 3
on some tables and assumes the encoder is already enabled
if the DFP2_ACTIVE bit is set. Clear that bit so the table
sets the DDIA enable bit properly.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 18b4fada27.
This code was correct, apologies to anyone who noticed things broke.
revert contents are different due to another commit in between.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for Ironlake and older where it has been seen to
cause trouble with screen updates.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Francis Moreau <francis.moro@gmail.com>
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
Note that this is only tested on single-function DVI-D SDVOs, on two
platforms (965GME and 945GSE), and has not been checked against a
specification document.
With lots of help from Adam Jackson <ajax@redhat.com> on IRC.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
While I think the previous code is correct, it was hard to follow and
hard to debug. Since we already have a ring abstraction, might as well
use it to handle the semaphore updates and compares.
I don't expect this code to make semaphores better or worse, but you
never know...
v2:
Remove magic per Keith's suggestions.
Ran Daniel's gem_ring_sync_loop test on this.
v3:
Ignored one of Keith's suggestions.
v4:
Removed some bloat per Daniel's recommendation.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Test scheme: plug in the HDMI/DP monitor, and run
cat /proc/asound/card0/eld*
to check if the monitor name, HDMI/DP type, etc. show up correctly.
Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.
CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor.
This adds drm_edid_to_eld() for converting EDID to ELD. The converted
ELD will be saved in a new drm_connector.eld[128] data field. This is
necessary because the graphics driver will need to fixup some of the
data fields (eg. HDMI/DP connection type, AV sync delay) before writing
to the hardware ELD buffer. drm_av_sync_delay() will help the graphics
drivers dynamically compute the AV sync delay for fixing-up the ELD.
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be returned by drm_select_eld(). This policy may not be
suitable for all users, but let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor.
According to James, many TVs will either refuse the display anything or
pop-up an OSD warning whenever they receive hdmi audio which they cannot
handle. Eventually we will require configurability and/or per-monitor
audio control even when the video is cloned.
CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
CC: James Cloos <cloos@jhcloos.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We want to enable dithering on any pipe where the frame buffer has
more color resolution than the output device.
The previous code was incorrectly clamping the frame buffer bpc to the
display bpc, effectively disabling dithering all of the time as the
computed frame buffer bpc would never be larger than the display bpc.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6: (353 commits)
drm/nouveau: remove allocations from gart populate() hook
drm/nvc0/fb: slightly improve PMFB intr handling, move out of nvc0_graph.c
drm/nvc0/fifo: avoid touching missing subfifos
drm/nvd9/disp: bail out of mode_set_base if no fb bound to crtc
drm/nvd9/disp: stub some more api hooks so we don't oops on resume
drm/nouveau: fix printk typo in ioremap failure path
drm/nvc0/pm: minor clock readback fixes
drm/nv40/pm: execute memory reset script from vbios
drm/nv50/gr: refactor initialisation
drm/nouveau: if requested, try harder at disabling sysmem pushbufs
drm/nv50/gr: enable ctxprog xfer only when we need it to save power
drm/nouveau/dp: add support for displayport table 0x30
drm/nouveau/dp: return master dp table pointer too when looking up encoder
drm/nouveau/bios: simplify U/d table hash matching func to just match
drm/nouveau/dp: preserve non-pattern bits in DP_TRAINING_PATTERN_SET
drm/nvc0/gr: remove MODULE_FIRMWARE() lines
drm/nouveau/dp: use alternate lane mask for nvaf
drm/nouveau/dp: link rate scripts are selected with a comparison table
drm/nv40/pm: write nv40-specific reclocking routines
drm/nv40/pm: parse geometric delta clock from vbios
...
Since some somewhat questionable changes a while back, TTM provides a
completely empty array of struct dma_address that stays around for the
entire lifetime of the TTM object.
Lets use this array, *always*, rather than wasting yet more memory on
another array who's purpose is identical, as well as yet another bool array
of the same size saying *which* of the previous two arrays to use...
This change will also solve the high order allocation failures seen by
some people while using nouveau.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch adds instructions to ctxprog and by doing, impacts context
switching performance. My testcase showed a 1% performance cost using
glxgears that is a context-switch bound application.
Please test and report bugs/performance/power/other.
Many thanks to Maxim Levitsky for his dedicated work on lowering power
consumption with nouveau.
More patches are coming thanks to his work:
https://bugs.freedesktop.org/show_bug.cgi?id=37922
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Written from observations of my NVD9's vbios, completely untested due to
my NVD9 lacking actual DisplayPort connectors..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Will need to be able to distinguish 2.0/2.1 from 3.0 soon. Also, move
the vbios parsing to nouveau_dp where it belongs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We don't use these by default anymore, and there's been complaints from a
number of places thinking that the firmware blobs are required still.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not 100% perfect yet, but a good start towards what it'll look like in the
end.
Actually seems stable on a NV44 I have here, as much as running around OA
for a fair amount of time constantly switching between performance levels
can prove..
My NV49 isn't quite so happy, and semaphores mess up somehow (sometimes) as
a result of the memory reclocking.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This changes the meaning of what we reported as "core" clock previously.
The shader/rop units are allegedly supposed to be run at the base clock
listed in the perf table, while the geometric clock can be bumped from
this value on some boards.
So that we can report both, we'll report the base clock as "shader" (since
the shaders *do* run at it), and the geometric clock as "core".
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not used currently, but it will be used in preference to pre-determined
lane/bandwidth numbers at a later point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
I'm sure that out there somewhere, someone will need this. We currently
haven't seen an example of LVDS being on a non-0 SOR so far though.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The HW will only accept the DMA_FROM_MEMORY class for DMA_SEMAPHORE without
asking the driver to intervene.
It appears that semaphores will work correctly even without DMA_IN_MEMORY,
so lets avoid the large amount of interrupts generated by x-chan sync.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NV30: Create framework for memtm
NV50: Improve reg creation,
NV50: Use P.version instead of card codename/stepping,
NVC0: Initial memtiming code for Fermi,
Renamed regs for consistency,
Overall redesign to improve readability,
Avoid kfree on null-pointer
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
If we support PGPIO interrupts, and know a hotplug GPIO tag for a
connector we use HPD, otherwise POLL_CONNECT.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The nouveau hwmon temperature support currently only functions when hwmon is
compiled into the kernel. There's no reason why this shouldn't also work when
both hwmon and nouveau are modularised (as is the case with Slackware's stock
kernels).
Signed-off-by: Ken Milmore <ken.milmore@googlemail.com>
Reviewed-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Takes a gamble and presumes that we can safely store something random in
OR_MODE_CTRL+4, the hw doesn't seem to mind...
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
VBIOS does more than this, as does nv50/nvc0 driver in nouveau. Traces
of the NVIDIA binary driver however, show pretty much just this being
done... Seems to work for me, it'll be fine for the moment.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
All the non-stubbed functions should be okay for this chipset, the rest
will be added back as they're figured out.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We previously assumed (incorrectly a lot of the time) that PTIMER would
be programmed at a frequency which'd give its 64-bit timestamps in
nanoseconds.
By programming PTIMER ourselves, we avoid this problem.
Reviewed-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The set will be replaced with a wait on the same flag by a subsequent
commit in order to halt a ctxprog's execution temporarily.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is probably better than having to tell the common code about all the
clocks that exist on every chipset.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We want to enable dithering on any pipe where the frame buffer has
more color resolution than the output device.
The previous code was incorrectly clamping the frame buffer bpc to the
display bpc, effectively disabling dithering all of the time as the
computed frame buffer bpc would never be larger than the display bpc.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Various issues involved with the space character were generating
warnings in the checkpatch.pl file. This patch removes most of those
warnings.
Signed-off-by: Akshay Joshi <me@akshayjoshi.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The BO blit code inconsistenly handled the page size. This wasn't
an issue on system with 4k pages since the GPU's page size is 4k as
well. Switch the driver blit callbacks to take num pages in GPU
page units.
Fixes lemote mipsel systems using AMD rs780/rs880 chipsets.
v2: incorporate suggestions from Michel.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
cur_pages is the number of pages per loop iteration.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a resend from the original, changing the title from PATCH to
RFC(since this is a review for commit, and I should have put that the first go around).
and also removing some of the commit's with ia64 and bash since it is significant.
let me know if I might have missed anything etc..
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Apparently this doesn't always work reliably, e.g. at resume time.
Just initialize to 0, so the ring is considered empty.
Tested with hibernation on Sumo and Cayman cards.
Should fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ .
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes an information leak to userspace, we were handing out un-zeroed pages
for any newly created TTM_PL_TT buffer.
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove the duplicate "return" statement in drm_fb_helper_panic().
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv04/crtc: Bail out if FB is not bound to crtc
drm/nouveau: fix nv04_sgdma_bind on non-"4kB pages" archs
drm/nouveau: properly handle allocation failure in nouveau_sgdma_populate
drm/nouveau: fix oops on pre-semaphore hardware
drm/nv50/crtc: Bail out if FB is not bound to crtc
This commit resolves a possible 'NULL pointer dereference'
It uses the same approach as radeon, intel and nouveau/nv50
Fixes bug 'Nouveau: Kernel oops when unplugging external monitor'
https://bugs.freedesktop.org/show_bug.cgi?id=40336
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nv04_sgdma_bind binds the same page multiple times on
architectures where PAGE_SIZE != 4096.
Let's fix it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not cleaning after alloc failure would result in crash on destroy,
because nouveau_sgdma_clear assumes "ttm_alloced" to be not null when
"pages" is not null.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This was previously done for r300 only. Use %016llX instead of %08X for
printing the table address.
Also fix typos in gart warning messages.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This bumps driver major version as a result of previous incompatible
interface changes.
In addition, a leftover command definition is removed from the
vmwgfx_drm.h header.
Also a strict version check is enforced on the exebuf ioctl.
This is intended to be the last major bump before exiting staging.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Will be needed for queries and drm event-driven throttling.
As a benefit, they help avoid stale user-space fence handles.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Break out on-demand enabling and disabling of fence irqs to make
the function more readable. Also make dev_priv->fence_queue_waiters an int
instead of an atomic_t since we only manipulate it with dev_priv->hw_mutex
held.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is needed before we introduce the fence objects.
Otherwise this will be even more confusing. The plan is to use the following:
seqno: A 32-bit sequence number that may be passed in the fifo.
marker: Objects, carrying a seqno, that track fifo submission time. They
are used for fifo lag based throttling.
fence objects: Kernel space objects, possibly accessible from user-space and
carrying a 32-bit seqno together with signaled status.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since we don't allow user-space to map the fifo anymore,
add a parameter to get fifo hw version and
an ioctl to copy the 3D capabilities.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecranz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was previously used by user-space to check whether a fence
sequence had passed or not.
With fence objects that's not needed anymore.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It doesn't seem like its needed. If this turns out to be an incorrect
assumption, we can reinstate it.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It was only used for bringup debugging, and probably doesn't work
anymore. Remove it.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sink type is always DP for DP bridges and EDID fetch on
DP bridges is always i2c over aux rather than plain i2c.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the bios or OS sets the pci max read request size to 0 or an
invalid value (6,7), it can result in a hang or slowdown. Check
and set it to something sane if it's invalid.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=42162
v2: use pci reg defines from include/linux/pci_regs.h
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Guest Memory Regions 2 is a way to bind pages to the GPU, but using
the FIFO instead of an io-submitted descriptor chain.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When GMR2 is available, make sure we restrict the number of used GMR pages
to the limit indicated by the device.
This is done by failing a GMRID allocation if the total number of GMR pages
exceeds the limit.
As a result TTM will then start evicting buffers in GMR memory on a
LRU basis until the allocation succeeds.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Previously this was not done when any 3D resource was active,
since that meant disabling the fifo with all 3D state lost.
Now, if there are still 3D resources active, we use the svga hide feature.
This fixes X server VT switching with 3D enabled.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Perform all command stream validation in a bounce buffer separate from the
fifo. This makes the fifo available to all validation-generated commands,
which would otherwise attempt to grab the fifo recursively, causing a
deadlock. This is in preparation for GMR2 and swappable surfaces.
Also maintain references to all surfaces in the command stream until the
command stream has been fired in order to avoid racing with surface
destruction taking place after validation but before submission.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The new DRM_RADEON_GEM_WAIT ioctl combines GEM_WAIT_IDLE and GEM_BUSY (there
is a NO_WAIT flag to get the latter) with USAGE_READ and USAGE_WRITE flags
to take advantage of the new ttm_bo_wait changes.
Also bump the DRM version.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
reading that buffer, and a CPU wants to map that buffer for read, it needs to
only wait for the last write. If there were no write, there wouldn't be any
waiting needed.
This, or course, requires user space drivers to send read/write flags
with each relocation (like we have read/write domains in radeon, so we can
actually use those for something useful now).
Now how this patch works:
The read/write flags should passed to ttm_validate_buffer. TTM maintains
separate sync objects of the last read and write for each buffer, in addition
to the sync object of the last use of a buffer. ttm_bo_wait then operates
with one the sync objects.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On some Power rv100 cards, we have no ATY OF table, but we have
no combios table either, and hence we refuse all modes on VGA-0
since we end up with a 0 max pixel clock.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: stable@kernel.org
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
For some reason SPI block is in broken state after module
unloading. This lead to broken rendering after reloading
module. Fix this by reseting SPI block in CP resume function
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>
It is left out the code to decrease the number of connector and encoder
to the cleanup functions.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.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: Fix wrong initializer for "locked" variable in assert_panel_unlocked
i915: do not setup intel_backlight twice
Otherwise it just contains random memory.
Issue detected by cppcheck.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data
to i2c bus for a HDMI connector that is not implemented/existent
on the notebook's board.
Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC Lines
Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook
BugLink: http://bugs.launchpad.net/bugs/826677
Signed-off-by: Thomas Reim <reimth@gmail.com>
Acked-by: Chris Routh <routhy@gmail.com>
Cc: <stable@kernel.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was true for new TTM_PL_SYSTEM and new TTM_PL_TT cases, but wasn't
the case on TTM_PL_SYSTEM<->TTM_PL_TT moves, which causes trouble on some
paths as nouveau's move_notify() hook requires that the dma addresses be
valid at this point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau makes the assumption that if a TTM is bound there will be a mm_node
around for it and the backwards ordering here resulted in a use-after-free
on some eviction paths.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ttm_tt_destroy kfrees passed object, so we need to nullify
a reference to it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The commit "Not all systems expose a firmware or platform mechanism for
changing the backlight intensity on i915, so add native driver support"
adds calls to intel_panel_setup_backlight() from intel_{lvds,dp}_init
so do not call it again from intel_setup_outputs().
BugLink: http://bugs.launchpad.net/bugs/831542
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
ACKed-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
Otherwise these would need to be painstakingly calculated looking at the source
code.
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>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alpha needs to have available the system bus address for the Radeon's
local memory, so that it can be used in ttm_bo_vm_fault(), when building
the PTEs for accessing that VRAM. So, we make bus.addr hold the ioremap()
return, and then we can modify bus.base appropriately for use during page
fault processing.
Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel:
drm/i915: set GFX_MODE to pre-Ivybridge default value even on Ivybridge
Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that
MI_FLUSH would flush the TLBs in addition to the rest of the caches
indicated in the MI_FLUSH command. However starting with Ivybridge, the
register defaults to 0x2800 out of reset, meaning that to invalidate the
TLB we need to use PIPE_CONTROL. Since we're not doing that yet, go
back to the old default so things work.
v2: don't forget to actually *clear* the new bit
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: Cannot set clock gating under UMS
drm/i915: Can't do accurate vblank timestamps with UMS
Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support.
drm/i915: split out PCH refclk update code
drm/i915: show interrupt info on IVB
drm/i915: Remove unused 'reg' argument to dp_pipe_enabled
drm/i915: Fix PCH port pipe select in CPT disable paths
drm/i915: Leave LVDS registers unlocked
drm/i915: Wait for LVDS panel power sequence
The clock gating functions are only assigned under KMS, so don't try
to call them under UMS.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Disable this feature when KMS is not running by setting the
driver->get_vblank_timestamp function pointer to NULL.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com>
Tested-by: Michel Alexandre Salim <salimma@fedoraproject.org>
Tested-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Attempting to try and turn off disconnected display hw in the
hotput handler lead to more problems than it helped. For
now just register an event and only attempt the do something
interesting with DP. Other connectors are just too problematic:
- Some systems have an HPD pin assigned to LVDS, but it's rarely
if ever connected properly and we don't really care about hpd
events on LVDS anyway since it's always connected.
- The HPD pin is wired up correctly for eDP, but we don't really
have to do anything since the events since it's always connected.
- Some HPD pins fire more than once when you connect/disconnect
- etc.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39882
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
At least some Apples program the GPU into a state that wedges the engine
once userspace starts trying to perform accelerated operations. Executing
the Atom init scripts gets the hardware back into a working state. The
same hardware works fine when booted via BIOS emulation, so let's just
execute the init scripts on Apples when we're using EFI.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have two sources of information about panel capabilities on mobile
radeon - the BIOS, which gives us a native mode, and the panel's preferred
mode. In theory these two will always match, but there's some corner cases
where the BIOS hasn't been fully initialised and so the native mode in it
ends up with default values. However, if we get a panel with reasonable
EDID, it's probably the case that the panel's preferred mode does actually
represent the panel capabilities. This patch handles that case by replacing
the native mode with the panel's preferred mode if the resolutions don't
match. Systems without a valid internal panel EDID will still use the BIOS
native mode.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to add support for 4 crtcs when setting the possible crtcs
for the encoders.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we get a hotplug event on an connector that is off, don't
attempt to turn it on or off, it should already be off.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=728228
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
We ought to be calling this from our DPMS routines as well as global
state may change and we need to enable/disable clocks. So split out the
code in preparation for further changes.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
IVB uses the same interrupt reg layout as SNB, so add an IS_GEN7 to the
interrupt debugfs file.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Just an extra parameter which isn't actually needed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
CPT pipe select is different from previous generations (using two bits
instead of one). All of the paths from intel_disable_pch_ports were
not making this distinction.
Mode setting with pipe A turned off would then also force all outputs
on pipe B to get turned off as the disable code would mistakenly
decide that all of these outputs were on pipe A and turn them off.
This is an extension of the CPT DP disable fix (why didn't I fix this then?)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
During mode setting, check to make sure the panel power sequencing has
completed before doing further operations on the device. This
uncovered errors with DPMS not turning the device off as it was left locked.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
for a DVI connector that is not implemented/existent on the board.
Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC Lines
Tested for kernel 2.6.38 on Asus ECS A740GM-M board
BugLink: http://bugs.launchpad.net/bugs/810926
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Log PCI subsystem vendor and subsystem device ID in addition to
PCI vendor and device ID during kernel mode initialisation. This helps
to better identify radeon devices of third-party vendors, e. g. for
bug analysis.
Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some integrated ATI Radeon chipset implementations with add-on HDMI card
(e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even
when the add-on card is not plugged in or HDMI is disabled in BIOS setup.
In this case, drm_get_edid() and drm_edid_block_valid() periodically
dump data and kernel errors into system log files and onto terminals.
For these connectors DDC probing is extended by a check for a correct
EDID header. Only in case a valid EDID header is also found, the
(HDMI or DVI) connector will be used by the Radeon driver. This prevents
the kernel driver from useless flooding of logs and terminal sessions with
EDID dumps and error messages.
This patch adds a flag 'requires_extended_probe' to the radeon_connector
structure. In function radeon_connector_needs_extended_probe() this flag
can be set on a chipset family/vendor/connector type specific basis.
In addition, function radeon_ddc_probe() has been adapted to perform
extended DDC probing if required by the connector's flag.
Requires function drm_edid_header_is_valid() in DRM module provided by
[PATCH] drm: Separate EDID Header Check from EDID Block Check.
Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196
BugLink: http://bugs.launchpad.net/bugs/7228066
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Provides function drm_edid_header_is_valid() for EDID header check
and replaces EDID header check part of function drm_edid_block_valid()
by a call of drm_edid_header_is_valid().
This is a prerequisite to extend DDC probing, e. g. in function
radeon_ddc_probe() for Radeon devices, by a central EDID header check.
Tested for kernel 2.6.35, 2.6.38 and 3.0
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The struct drm_driver has some function pointers for irq. They are
gpu specific and some functions aren't essential things. This can
prevents creation of unnecessary dummy function for irq.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The registered irq should be unregistered by free_irq() if
irq_postinstall() returns the error after request_irq() is called
successfully.
[airlied: add vga switcheroo disable]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reg header files are generated so they are not cleaned automagically.
They need to be added to the clean-files list.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
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: (42 commits)
drm/i915: allow cache sharing policy control
drm/i915/hdmi: HDMI source product description infoframe support
drm/i915/hdmi: split infoframe setting from infoframe type code
drm: track CEA version number if present
drm/i915: Try enabling RC6 by default (again)
Revert "drm/i915/dp: Zero the DPCD data before connection probe"
drm/i915/dp: wait for previous AUX channel activity to clear
drm/i915: don't use uninitialized EDID bpc values when picking pipe bpp
drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend
drm/i915: apply phase pointer override on SNB+ too
drm/i915: Add quirk to disable SSC on Sony Vaio Y2
drm/i915: provide more error output when mode sets fail
drm/i915: add GPU max frequency control file
i915: add Dell OptiPlex FX170 to intel_no_lvds
drm/i915: Ignore GPU wedged errors while pinning scanout buffers
drm/i915/hdmi: send AVI info frames on ILK+ as well
drm/i915: fix CB tuning check for ILK+
drm/i915: Flush other plane register writes
drm/i915: flush plane control changes on ILK+ as well
drm/i915: apply timing generator bug workaround on CPT and PPT
...
The board has an lm63 compatible thermal chip, but no
thermal chip entry in the vbios tables.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39513
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This off by one range check was copy and pasted a couple places.
It's not really harmful, but we should fix it anyway.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Compute cs support was actually added in 2.11.0 rather than
2.10.0, but the patch was written prior. Update comment
to match.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Expose the SNB+ cache sharing policy register in debugfs. The new file,
i915_cache_sharing, has 4 values, 0-3, with 0 being "max uncore
resources" and 3 being the minimum. Exposing this control should make
benchmarking easier and help us choose a good default.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This makes it easier to add support for other infoframes (e.g. SPD,
vendor specific).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Drivers need to know the CEA version number in addition to other display
info (like whether the display is an HDMI sink) before enabling certain
features. So track the CEA version number in the display info
structure.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Jesse Barnes and I found a couple of issues where incorrect mode
setting would cause problems with RC6 enabled. We're hopeful that
fixing those will resolve the outstanding issues with a few machines
that had trouble before 3.0 with rc6.
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Francesco Allertsen <fallertsen@gmail.com>
Cc: Ted Phelps <phelps@gnusto.com>
Cc: Gu Rui <chaos.proton@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38332
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 97cdd71010.
Clearing the dpcd data means that if the fetch fails, any previous
data will be lost. On eDP, this is no fun as we only fetch dpcd at
init time, so the memset will destroy that the next time through.
Before initiating a new read or write on the DP AUX channel, wait for
any outstanding activity to complete. This may happen during normal
retry behavior. If the wait fails (i.e. after 1ms the AUX channel is
still busy) dump a backtrace to make the caller easier to spot.
v2: use msleep instead, and timeout after 3ms (only ever saw 1 retry
with msleep in testing)
v3: fix backtrace check to trigger if the 3ms wait times out
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38136.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The EDID parser will zero out the bpc value, and the driver needs to handle
that case. In our picker, we'll just ignore 0 values as far as bpp
picking goes.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39323.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
At least on a Lenovo X220 the HPD bits of this are enabled at boot but
cleared after resume, which means plug interrupts stop working.
This also happens to fix DP displays re-lighting on resume. I'm quite
certain that's an accident: the first DP link train inevitably fails on
that machine, and it's only serendipity that we're getting multiple plug
interrupts and the second train works. But I shall take my victories
where I get them.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
These bits moved around on SNB and above.
v2: again with the git send-email fail
v3: add macros for getting per-pipe override & enable bits
v4: enable phase sync pointer on SNB and IVB configs as well
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Using the new quirk added to support disabling SSC on Lenovo U160
(#36656, commit 435793dfb8), also register
the Vaio as a special case and disable SSC for it.
This patch fixes#34437 on fdo bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=34437
Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org>
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>
Mainly for use in debugging and benchmarking, this file allows the user
to control the max frequency used by the GPU. Frequency may still vary
based on workload (if the frequency is set to higher than the minimum)
but won't go over the newly set value.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The Dell OptiPlex FX170 claims to have LVDS, but doesn't.
Signed-off-by: Pieterjan Camerlynck <pieterjan.camerlynck@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
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.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
On Ironlake and above, we have per-transcoder DIP registers, so use them
for sending DIPs like AVI infoframes on ILK and above.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
CB tuning is needed to handle potential process variations that might
cause clock jitter for certain PLL settings. However, we were setting
it incorrectly since we were using the wrong M value as a check (M1 when
we needed to use the whole M value). Fix it up, making my HDMI
attached display a little prettier (used to have occasional dots crawl
across the display).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Writes to the plane control register are buffered in the chip until a
write to the DSPADDR (pre-965) or DSPSURF (post-965) register occurs.
This patch adds flushes in:
intel_enable_plane
gen6_init_clock_gating
ivybridge_init_clock_gating
Signed-off-by: Keith Packard <keithp@keithp.com>
After writing to the plane control reg we need to write to the surface
reg to trigger the double buffered register latch. On previous
chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg
that triggers the double buffer latch.
v2: write DSPADDR too to cover pre-965 chipsets
v3: use flush_display_plane instead, that's what it's for
v4: send the right patch
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
On CougarPoint and PantherPoint PCH chips, the timing generator may fail
to start after DP training completes. This is due to a bug in the
FDI autotraining detect logic (which will stall the timing generator and
re-enable it once training completes), so disable it to avoid silent DP
mode setting failures.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This corrects the DPMS mode tracking so that the DPMS code will
actually turn the CRTC off the next time the screen saves.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This reverts commit 885a50147f.
We actually *do* need to track DPMS state so that on hotplug, we don't
retrain the link until DPMS is disabled.
However, that code had avery small bug -- it wouldn't set the
dpms_mode at mode set time, and so link retraining would not actually
occur on monitor hotplug until the monitor had gone through a DPMS
off/DPMS on cycle.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Display port pipe selection on CPT is not done with a bit in the
output register, rather it is controlled by a couple of bits in the
separate transcoder register which indicate which display port output
is connected to the transcoder.
This patch replaces the simplistic macro DP_PIPE_ENABLED with the
rather more complicated function dp_pipe_enabled which checks the
output register to see if that is enabled, and then goes on to either
check the output register pipe selection bit (on non-CPT) or the
transcoder DP selection bits (on CPT).
Before this patch, any time the mode of pipe A was changed, any
display port outputs on pipe B would get disabled as
intel_disable_pch_ports would ensure that the mode setting operation
could occur on pipe A without interference from other outputs
connected to that pch port
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Eliminates an open-coded read and also gains the retry behaviour of
intel_dp_get_dpcd, which seems like a good idea.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This describes the function better, allowing it to be used where the
DPCD value is relevant.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This uses the common dpcd reading routine, i915_dp_detect_common,
instead of open-coding a call to intel_dp_aux_native_read. Besides
reducing duplicated code, this also gains the read retries which
may be necessary when a cable is first plugged back in and the link
needs to be retrained.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
drm_helper_hpd_irq_event queues another work proc to go and deliver
the user-space event, and that function also wants to hold the config
mutex, so we shouldn't hold the mutex across the
drm_helper_hpd_irq_event call.
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
Many (all?) of the coefficients related to calculating the
correct temperature are signed integers
This patch correcly parses and stores those values
It also ensures that the default offset is 0 (previously 1)
Affected cards - the original nv50 and the nv40 family
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit "drm/nouveau: add some debug output if nouveau_mm busy at destroy time"
revealed an issue where vram mm takedown would actually fail due to there
still being nodes present, causing nouveau to leak a small amount of memory
on module unload.
This splits TTM/nouveau_mm a bit more cleanly and ensures nouveau_mm fini
isn't done until all gpuobjs are also destroyed.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GPU virtual addresses are constant now so this should never be getting hit
anyway and userspace shouldn't break from them being ignored.
This is being done in preference to teaching the code how to deal with BOs
that exist at different virtual addresses within separate VMs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Greatly simplifies a number of things, particularly once per-client GPU
address spaces are involved.
May add this back later once I know what things'll look like.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Was previously assuming a page size of 4KiB unless a VMA was present to
override it. Eventually, a buffer won't necessarily have a VMA at all at
some stages of its life, so we need to store this info elsewhere.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Abuses existing gpuobj_new() chan argument for this, which in turn forces
all NVOBJ_FLAG_VM allocations to be done from the global heap, not
suballocated from the channel's private heap. Not a problem though in
practise.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Userspace hasn't passed us a channel_hint for a long long time now, and
there isn't actually a need to do so anymore anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On chipsets using nouveau_vm, the virtual address stays constant, so
the value set at bo creation time is fine.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's lots of boards (all recent ones) that don't have this anymore, so
punt the message to debug loglevel.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not a clue what it is yet, but we get the same numbers as NVIDIA now.
My 465 didn't seem to care to greatly *what* I bashed into these registers..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The ability to use NVIDIA's fuc has been retained *temporarily* in order
to better debug any issues that may be lingering in our initial attempt
at writing this ucode. Once I'm fairly confident we're okay, it'll be
removed.
There's a number of things not implemented by this fuc currently, but
most of it is sets of state that our context setup would not have used
anyway. No doubt we'll find out what they're for at some point, and
implement it if required.
This has been tested on 0xc0/0xc4 thus far, and from what I could tell
it worked as well as NVIDIA's. It's also been tested on 0xc1, but even
with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet.
0xc3/0xc8/0xce should in theory be supported too, but I don't have the
hardware to check that.
There's no doubt numerous bugs to squash yet, please report any!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need the physical VRAM address in vinst, even for objects mapped into
a vm, as the gpuobj suspend/resume code uses PMEM to access the object.
Previously, vinst was overloaded to mean "VRAM address" for !VM objects,
and "VM address" for VM objects, causing the wrong data to be accessed
during suspend/resume.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Until we know these should work properly, would much rather default to
noaccel than risk giving people corruption/hangs out of the box..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's issues with certain 3D apps still, unknown whether this is a kernel
issue or not.. It does appear that it may be in the 3D driver however.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes DMAR faults during accel, more than likely a similar problem to what
was solved on nv50 previously.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The lock must be held for the saving and restoring of VGA state.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
CC: Alexander Zhaunerchyk <alex.vizor@gmail.com>
CC: Andrey Rahmatullin <wrar@wrar.name>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 4a684a4117.
Userland has always been required to set the object's domain to GTT
before using it through a GTT mapping, it's not something that the
kernel is supposed to enforce. (The pagefault support is so that we
can handle multiple mappings without userland having to pin across
them, not so that userland can use GTT after GPU domains without
telling the kernel).
Fixes 19.2% +/- 0.8% (n=6) performance regression in cairo-gl
firefox-talos-gfx on my T420 latop.
Signed-off-by: Keith Packard <keithp@keithp.com>
...we need to apply exactly the same workaround for missing interrupts
from BSD as for the BLT ring, apparently.
See also commit 498e720b96
(drm/i915: Fix gen6 (SNB) missed BLT ring interrupts).
Reported-and-tested-by: nkalkhof@web.de
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38529
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
- Add some new compute regs
- Add new dispatch packets for evergreen/cayman
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
. and some comments to make it easier to understand.
Ackedby: Randy Dunlap <randy.dunlap@oracle.com>
[v2: Added some more updates from Randy Dunlap]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No need to assign the same copy callback for both
copy blit and dma.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau is going to use these hooks to map/unmap objects from a client's
private GPU address space.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
0xff01 is not an actual voltage value, but a flag
for the driver. If the power state as that value,
skip setting the voltage.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Many stupid corrections of duplicated includes based on the output of
scripts/checkincludes.pl.
Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: fix assumption that semaphore dmaobj is valid in x-chan sync
drm/nv50/disp: fix gamma with page flipping overlay turned on
drm/nouveau/pm: Prevent overflow in nouveau_perf_init()
drm/nouveau: fix big-endian switch
Since we were calling the wptr function before checking if the IH was
even enabled, or the GPU wasn't shutdown, we'd get spam in the logs when
the GPU readback 0xffffffff. This reorders things so we return early
in the no IH and GPU shutdown cases.
Reported-and-tested-by: ManDay on #radeon
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is used during phy init to set up the phy for DP. This may
fix DP problems on DCE3.2 cards.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Certain revisions of the vbios on DCE3.2 cards have a bug
in the transmitter control table which prevents duallink from
being enabled properly on some cards. The action switch statement
jumps to the wrong offset for the OUTPUT_ENABLE action. The fix
is to use the ENABLE action rather than the OUTPUT_ENABLE action
on the affected cards. In fixed version of the vbios, both
actions jump to the same offset, so the change should be safe.
Reported-and-tested-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DDX modifies DMA_SEMAPHORE on nv50 in order to implement sync-to-vblank,
things will go very wrong for cross-channel sync after this.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
While parsing the perf table, there is no check if
the num of entries read from the vbios is less than
the currently allocated number.
In case of a buggy vbios this will cause overwriting
of kernel memory, causing aditional problems.
Add a simple check in order to prevent the case
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The failure appeared in dmesg as:
[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
ring idle [waiting on 35064155, at 35064155], missed IRQ?
This works around that problem on by making the blitter command
streamer write interrupt state to the Hardware Status Page when a
MI_USER_INTERRUPT command is decoded, which appears to force the seqno
out to memory before the interrupt happens.
v1->v2: Moved to prior interrupt handler installation and RMW flags as
per feedback.
v2->v3: Removed RMW of flags (by anholt)
Cc: stable@kernel.org
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1]
Tested-by: Eric Anholt <eric@anholt.net> [v1,v3]
(incidence of the bug with a testcase went from avg 2/1000 to
0/12651 in the latest test run (plus more for v1))
Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394
Signed-off-by: Dave Airlie <airlied@redhat.com>
The existing code assumed scratch registers in a number
of places while in most cases we are be using writeback
and events rather than scratch registers.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
DP clock and lanes were not set properly for DP bridges.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to set the external transmitter type properly in
AdjustPixelClock to get the properly output.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
They need to be treated like eDP rather than DP.
May fix:
https://bugzilla.kernel.org/show_bug.cgi?id=34822
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to set up the bridge for DDC prior to the
i2c over aux transaction.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This should give us more reliable results if the table
is called before an active device is set.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Revert commit 8f9a3f9b63. This fixes a
hang when loading the eeprom driver (see bug #35572.) GMBUS will be
re-enabled later, differently.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reported-by: Marek Otahal <markotahal@gmail.com>
Tested-by: Yermandu Patapitafious <yermandu.dev@gmail.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since printk_ratelimit() shouldn't be used anymore (see comment in
include/linux/printk.h), replace it with printk_ratelimited.
Signed-off-by: Christian Dietrich <christian.dietrich@informatik.uni-erlangen.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some RS690 chipsets seem to end up with floating connectors, either
a DVI connector isn't actually populated, or an add-in HDMI card
is available but not installed. In this case we seem to get a NULL byte
response for each byte of the i2c transaction, so we detect this
case and if we see it we don't do anymore DDC transactions on this
connector.
I've tested this on my RS690 without the HDMI card installed and
it seems to work fine.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
this puts the header and followup at the same loglevel as the
hex dump code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
I don't think Apple offered any other cards for
this mac, so I doubt this will be an issue, but just
to be on the safe side, check the pci ids as well.
v2: fix spelling in commit message
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Joachim Henke <j-o@users.sourceforge.net>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 8410ea (drm: rework PCI/platform driver interface) implemented
drm_pci_irq_by_busid() but forgot to make it available in the
drm_pci_bus-struct.
This caused a freeze on my Radeon9600-equipped laptop when executing glxgears.
Thanks to Michel for noticing the flaw.
[airlied: made function static also]
Reported-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Drivers using multiple framebuffers got broken by commit
41c2e75e60 which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real offsets could not always be handed over for comparison.
Instead of ignoring the offset we will compare the lower 32 bit. Drivers
using multiple framebuffers should just make sure that the lower 32 bit
are different. The existing drivers in question are practically limited
to 32-bit systems so that should be fine for them.
It is assumed that current drivers always specify a correct framebuffer
map offset, even if this offset was ignored since above commit. So this
patch should not change anything for drivers using only one framebuffer.
Drivers needing multiple framebuffers with 64-bit map offsets will need
to cook up something, for instance keeping an ID in the lower bit which
is to be aligned away when it comes to using the offset.
All of above applies to _DRM_REGISTERS as well.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It seems to me that we are leaking 'user_pages' in
drivers/gpu/drm/i915/i915_gem.c::i915_gem_shmem_pread_slow() if
read_cache_page_gfp() fails.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
To my knowledge, the limit is 16 on r300.
(the docs don't say what the limit is)
The lack of bounds checking can be abused to do all sorts of things
(from bypassing parts of the CS checker to crashing the kernel).
Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=36745
Cc: stable@kernel.org
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Apple uses the same subsystem pci ids for lots of
hardware much of which is wired up differently. In
this case, the G5 imac and the G5 tower.
Only apply the quirk configuration to G5 towers.
Reported-by: Joachim Henke <j-o@users.sourceforge.net>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Joachim Henke <j-o@users.sourceforge.net>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove an obsolete Alpha adjustment in the drm for MGA on Alpha.
Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
Tested-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove an obsolete Alpha adjustment, and modify another,
to go with the current Alpha architecture support.
Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
Tested-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
the code always returns ret regardless, so if(ret) check is unnecessary.
v2: fixed up the spelling.
Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Reviewed-by: Nicolas Kaiser <nikai@nikai.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Improves full-screen openarena on my laptop 20.3% +/- 4.0% (n=3)
Improves 800x600 nexuiz on my laptop 12.3% +/- 0.1% (n=3)
We have more room to improve with doing LLC caching for display using
GFDT, and in doing LLC+MLC caching, but this was an easy performance
win and incremental improvement toward those two.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The simplest and common method for ensuring scanout coherency on all
chipsets is to mark the scanout buffers as uncached (and for
userspace to remember to flush the render cache every so often).
We can improve upon this for later generations by marking scanout
objects as GFDT and only flush those cachelines when required. However,
we start simple.
[v2: Move the set to uncached above the clflush. Otherwise, we'd skip
the clflush and try to scan out data that was still sitting in the
cache.]
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to perform a few operations in order to move the object into the
display plane (where it can be accessed coherently by the display
engine) that are important for future safety to forbid whilst pinned. As a
result, we want to need to perform some of the operations before pinning,
but some are required once we have been bound into the GTT. So combine
the pinning performed by all the callers with set_to_display_plane(), so
this complication is contained within the single function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[anholt v2: Don't forget that when going from cached to uncached, we
haven't been tracking the write domain from the CPU perspective, since
we haven't needed it for GPU coherency.]
[ickle v3: We also need to make sure we relinquish any fences on older
chipsets and clear the GTT for sane domain tracking.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... in preparation for changing the cache level (and thus the flags upon
the PTEs) dynamically.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like its siblings finish_gpu(), this function clears the object from the
GTT domain forcing it to be trigger a domain invalidation should we ever
need to use via the GTT again.
Note that the most important side-effect of finishing the GTT domain
(aside from clearing the tracking read/write domains) is that it imposes
an memory barrier so that all accesses are complete before it returns,
which is important if you intend to be modifying translation tables
shortly afterwards. The second most important side-effect is that it
tears down the GTT mappings forcing a page-fault and invalidation on
next user access to the object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... reincarnated from i915_gem_object_flush_gpu(). The semantic
difference is that after calling finish_gpu() the object no longer
resides in any GPU domain, and so will cause the GPU caches to be
invalidated if it is ever used again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
debug statement for GUI idle interrupt is wrong and incorrectly
reports CP EOP interrupt; trivial issue, but confusing for
someone trying to distinguish interrupt sources while debugging
... fixed
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Filter out modes that are higher than the max pixel
clock.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On my x86_64 system with >4GB of ram and swiotlb instead of
a hardware iommu (because I have a VIA chipset), the call
to pci_set_dma_mask (see below) with 40bits returns an error.
But it seems that the radeon driver is designed to have
need_dma32 = true exactly if pci_set_dma_mask is called
with 32 bits and false if it is called with 40 bits.
I have read somewhere that the default are 32 bits. So if the
call fails I suppose that need_dma32 should be set to true.
And indeed the patch fixes the problem I have had before
and which I had described here:
http://choon.net/forum/read.php?21,106131,115940
Acked-by: Alex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Wierdly the kms parser never initialised the family, it wasn't really used
much, but the fmt checker patch started using it and it fell over.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/nv40: fall back to paged dma object for the moment
drm/nouveau: fix leak of gart mm node
drm/nouveau: fix vram page mapping when crossing page table boundaries
drm/nv17-nv40: Fix modesetting failure when pitch == 4096px (fdo bug 35901).
drm/nouveau: don't create accel engine objects when noaccel=1
drm/nvc0: recognise 0xdX chipsets as NV_C0
drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007
drm/i915: Share the common force-audio property between connectors
drm/i915: Remove unused enum "chip_family"
drm/915: fix relaxed tiling on gen2: tile height
drm/i915/crt: Explicitly return false if connected to a digital monitor
drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0
drm/i915: Only print out the actual number of fences for i915_error_state
drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/
drm: i915: correct return status in intel_hdmi_mode_valid()
drm/i915: fix regression after clock gating init split
drm/i915: fix if statement in ivybridge irq handler
* 'drm-radeon-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms/atom: fix PHY init
drm/radeon/kms: add missing Evergreen texture formats to the CS parser
drm/radeon/kms: viewport height has to be even
drm/radeon/kms: remove duplicate reg from r600 safe regs
drm/radeon/kms: add support for Llano Fusion APUs
drm/radeon/kms: add llano pci ids
drm/radeon/kms: fill in asic struct for llano
drm/radeon/kms: add family ids for llano APUs
drm/radeon: fix oops in ttm reserve when pageflipping (v2)
drm/radeon/kms: clean up the radeon kms Kconfig
drm/radeon/kms: fix thermal sensor reading on juniper
drm/radeon/kms: add missing case for cayman thermal sensor
drm/radeon/kms: add blit support for cayman (v2)
drm/radeon/kms/blit: workaround some hw issues on evergreen+
* 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next:
drm/nv40: fall back to paged dma object for the moment
drm/nouveau: fix leak of gart mm node
drm/nouveau: fix vram page mapping when crossing page table boundaries
drm/nv17-nv40: Fix modesetting failure when pitch == 4096px (fdo bug 35901).
drm/nouveau: don't create accel engine objects when noaccel=1
drm/nvc0: recognise 0xdX chipsets as NV_C0
PCI(E)GART isn't quite stable it seems, fall back to old method until I get
the time to sort it out properly.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Should hopefully get modesetting at least from this, it appears these are
GF119 chipsets. Accel will come eventually, once I order a board.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The PHY was not initialized correctly after
ac89af1e10 since
the function bailed early as an encoder was not
assigned. The encoder isn't necessary for PHY init
so just assign to 0 for init so that the table
is executed.
Reported-by: Ari Savolainen <ari.m.savolainen@gmail.com>
Tested-by: Ari Savolainen <ari.m.savolainen@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I found this while figuring out why gnome-shell would not run on my
Asus EeeBox PC EB1007. As a standalone "pc" this device cleary does not have
an internal panel, yet it claims it does. Add a quirk to fix this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
Make the audio property creation routine common and share the single
property between the connectors.
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>
Superseded by the tracking the render generation in the chipset
capabiltiies struct.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Userspace was broken and assumed 8 rows. Chris Wilson noted that the
kernel unfortunately can't reliable check that because libdrm rounds
up the size to the next bucket.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Rather than proceed on and silently return false by default, mention why
we rejected the presence of an EDID as implying the presence of a VGA
monitor. (The question arises whether there is a broken EDID which falsely
reports a digital connection when attached by VGA.)
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 computation of the first-level watermarks for g4x and gen5+ are
based on the same algorithm, so we can refactor those code paths to
use a single function.
Note that g4x_compute_wm0 takes a 'plane' argument while
ironlake_compute_wm0 took a 'pipe' argument. Both should have used a
'plane' argument, so this patch fixes that as well (not that it caused
a problem; ironlake always uses pipe == plane).
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>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
Convert our open coded offset_in_page() to the common macro.
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>
During the refactoring in revision 6067aaeadb,
the intel_enable_clock_gating was split up into several functions that are
then called indirectly. However, which function to call was not specified for
the IS_PINEVIEW() case. This patch specifies the correct gating function.
Signed-off-by: Jason Stubbs <jasonbstubbs@gmail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The extra semicolon was not intended.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
BC6 and BC7 are described in ARB_texture_compression_bptc.
No idea what FMT_32_AS_32_32_32_32 is good for.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to take a reference to this object, pinning doesn't take a reference
so if userspace deletes the object it can disappear even if pinned.
v2: fix error paths to unreference properly also.
should fix:
https://bugzilla.kernel.org/show_bug.cgi?id=32402
and
https://bugzilla.redhat.com/show_bug.cgi?id=680651
Acked-By: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Uses a different method than other evergreen asics.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.
v2: fix copy paste typo
Reported-by: Nils Wallménius <nils.wallmenius@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Change each shrinker's API by consolidating the existing parameters into
shrink_control struct. This will simplify any further features added w/o
touching each file of shrinker.
[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: fix warning]
[kosaki.motohiro@jp.fujitsu.com: fix up new shrinker API]
[akpm@linux-foundation.org: fix xfs warning]
[akpm@linux-foundation.org: update gfs2]
Signed-off-by: Ying Han <yinghan@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Acked-by: Pavel Emelyanov <xemul@openvz.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
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: (169 commits)
drivers/gpu/drm/radeon/atom.c: fix warning
drm/radeon/kms: bump kms version number
drm/radeon/kms: properly set num banks for fusion asics
drm/radeon/kms/atom: move dig phy init out of modesetting
drm/radeon/kms/cayman: fix typo in register mask
drm/radeon/kms: fix typo in spread spectrum code
drm/radeon/kms: fix tile_config value reported to userspace on cayman.
drm/radeon/kms: fix incorrect comparison in cayman setup code.
drm/radeon/kms: add wait idle ioctl for eg->cayman
drm/radeon/cayman: setup hdp to invalidate and flush when asked
drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked
agp/uninorth: Fix lockups with radeon KMS and >1x.
drm/radeon/kms: the SS_Id field in the LCD table if for LVDS only
drm/radeon/kms: properly set the CLK_REF bit for DCE3 devices
drm/radeon/kms: fixup eDP connector handling
drm/radeon/kms: bail early for eDP in hotplug callback
drm/radeon/kms: simplify hotplug handler logic
drm/radeon/kms: rewrite DP handling
drm/radeon/kms/atom: add support for setting DP panel mode
drm/radeon/kms: atombios.h updates for DP panel mode
...
udelay() doesn't like 8-bit arguments:
drivers/gpu/drm/radeon/atom.c: In function 'atom_op_delay':
drivers/gpu/drm/radeon/atom.c:653: warning: comparison is always false due to limited range of data type
while we're there, use msleep() rather than open-coding it.
Cc: David Airlie <airlied@linux.ie>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Matt Turner <mattst88@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It only needs to be called once at startup, not for every
modeset.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
b43: fix comment typo reqest -> request
Haavard Skinnemoen has left Atmel
cris: typo in mach-fs Makefile
Kconfig: fix copy/paste-ism for dell-wmi-aio driver
doc: timers-howto: fix a typo ("unsgined")
perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c
md, raid5: Fix spelling error in comment ('Ofcourse' --> 'Of course').
treewide: fix a few typos in comments
regulator: change debug statement be consistent with the style of the rest
Revert "arm: mach-u300/gpio: Fix mem_region resource size miscalculations"
audit: acquire creds selectively to reduce atomic op overhead
rtlwifi: don't touch with treewide double semicolon removal
treewide: cleanup continuations and remove logging message whitespace
ath9k_hw: don't touch with treewide double semicolon removal
include/linux/leds-regulator.h: fix syntax in example code
tty: fix typo in descripton of tty_termios_encode_baud_rate
xtensa: remove obsolete BKL kernel option from defconfig
m68k: fix comment typo 'occcured'
arch:Kconfig.locks Remove unused config option.
treewide: remove extra semicolons
...
cayman is reporting the wrong tile config value to userspace, this
causes piglit mipmap generation tests to fail.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was leading to a bogus value being programmed to the backend
routing register.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
None of the latest GPUs had this hooked up, this is necessary for
correct operation in a lot of cases, however we should test this on a few
GPUs in these families as we've had problems in this area before.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
On cayman we need to set the bit to cause HDP flushes to invalidate the
HDP cache also.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This needs to be explicitly set on btc. It's set by default
on evergreen/fusion, so it fine to just unconditionally enable it for
all chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
If the ss clock is external, the CLK_REF bit needs to be set
in the SetPixelClock parameters. This should fix DP failures
in the channel equalization loop.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Don't try and en/disable the port as it may be a hpd event from
powering up/down the panel during a modeset or dpms.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the hotplug handler, just use the drm dpms functions.
If the monitor is plugged in, turn it on, if it's not,
turn it off. This also reduces power usage by turning
off the encoder and crtc when the monitor is unplugged.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- reorganize the functions based on use
- clean up function naming
- rework link training to better match what we use internally
- add initial support for DP 1.2 (no MST yet)
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fusion hardware often has DP to VGA/LVDS/TMDS bridges to
handle non-DP encoders. Internally we treat them mostly
like DP.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
eDP is usually used as an LVDS replacement, so treat
it more like LVDS from the user perspective.
v2: encoder mode is always DP for eDP.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In DP mode, the DP ref clock can come from PPLL, DCPLL, or ext clock,
depending on the asic. The crtc virtual pixel clock is derived from
the DP ref clock.
- DCE4: PPLL or ext clock
- DCE5: DCPLL or ext clock
Setting ATOM_PPLL_INVALID will cause SetPixelClock to skip
PPLL/DCPLL programming and only program the DP DTO for the
crtc virtual pixel clock.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- properly mask the ss type
- don't enable ss if type is external or percentage is 0
- if ss enabled and type is external, set ref_div_src to ext clock
- prefer ASIC_INTERNAL_SS_ON_DP to LCD_Info SS_Id for eDP
- fix ss amount calculation
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'keithp/drm-intel-next' of ../drm-next:
drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge
drm/i915/sdvo: Reorder i2c initialisation before ddc proxy
drm/i915: FDI link training broken on Ironlake by Ivybridge integration
drm/i915: enable rc6 by default
drm/i915: add fbc enable flag, but disable by default
drm/i915: clean up unused ring_get_irq/ring_put_irq functions
drm/i915: fix user irq miss in BSD ring on g4x
It's not used on Ironlake, but is used on later generations, so make
sure it exists before we try to use it in the interrupt handlers.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The ddc proxy depends upon the underlying i2c bus being selected. Under
certain configurations, the i2c-adapter functionality is queried during
initialisation and so may trigger an OOPS during boot. Hence, we need to
reorder the initialisation of the ddc proxy until after we hook up the i2c
adapter for the SDVO device.
The condition under which it fails is when the i2c_add_adapter calls
into i2c_detect which will attempt to probe all valid addresses on the
adapter iff there is a pre-existing i2c_driver with the same class as
the freshly added i2c_adapter.
So it appears to depend upon having compiled in (or loaded such a
module before i915.ko) an i2c-driver that likes to futz over the
i2c_adapters claiming DDC support.
Reported-by: Mihai Moldovan <ionic@ionic.de>
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>
Commit 357555c00f split out IVB-specific
register definitions for FDI link training, but a piece of that commit
stopped executing some critical code on Ironlake systems while leaving
it running on Sandybridge.
Turn that code back on both Ironlake and Sandybridge
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With FBC disabled by default, it should be safe to enable RC6. So let's
give it a try.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
FBC has too many corner cases that we don't currently deal with, so
disable it by default so we can enable more important features like RC6,
which conflicts in some configurations.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31742
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch depends on patch "drm/i915: fix user irq miss in BSD ring on
g4x".
Once the previous patch apply, ring_get_irq/ring_put_irq become unused.
So simply remove them.
Signed-off-by: Feng, Boqun <boqun.feng@intel.com>
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
On g4x, user interrupt in BSD ring is missed.
This is because though g4x and ironlake share the same bsd_ring,
their interrupt control interfaces have _two_ differences.
1.different irq enable/disable functions:
On g4x are i915_enable_irq and i915_disable_irq.
On ironlake are ironlake_enable_irq and ironlake_disable_irq.
2.different irq flag:
On g4x user interrupt flag in BSD ring on is I915_BSD_USER_INTERRUPT.
On ironlake is GT_BSD_USER_INTERRUPT
Old bsd_ring_get/put_irq call ring_get_irq and ring_get_irq.
ring_get_irq and ring_put_irq only call ironlake_enable/disable_irq.
So comes the irq miss on g4x.
To fix this, as other rings' code do, conditionally call different
functions(i915_enable/disable_irq and ironlake_enable/disable_irq)
and use different interrupt flags in bsd_ring_get/put_irq.
Signed-off-by: Feng, Boqun <boqun.feng@intel.com>
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:
[ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[ 17.772458] Hardware name: Latitude E6400
[ 17.772460] Modules linked in: ....
[ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8
[ 17.772584] Call Trace:
[ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82
[ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: Frederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix build errors when CONFIG_ACPI is enabled but MXM_WMI is not enabled
by selecting both MXM_WMI and ACPI_WMI (the latter just for kconfig
dependencies):
nouveau_acpi.c:(.text+0x2400c8): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2400cf): undefined reference to `mxm_wmi_call_mxds'
nouveau_acpi.c:(.text+0x2400fe): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2402ba): undefined reference to `mxm_wmi_supported
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next: (55 commits)
drm/nouveau: make cursor_set implementation consistent with other drivers
drm/nva3/clk: better pll calculation when no fractional fb div available
drm/nouveau/pm: translate ramcfg strap through ram restrict table
drm/nva3/pm: allow use of divisor 16
drm/nvc0/pm: parse clock for pll 0x0a (0x137020) from perf table
drm/nvc0/pm: correct core/mem/shader perflvl parsing
drm/nouveau/pm: remove memtiming support check when assigning to perflvl
drm/nva3: support for memory timing map table
drm/nouveau: Associate memtimings with performance levels on cards <= nv98
drm/nva3/pm: initial pass at set_clock() hook
drm/nvc0/gr: calculate some more of our magic numbers
drm/nv50: respect LVDS link count from EDID on SPWG panels
drm/nouveau: recognise DCB connector type 0x41 as LVDS
drm/nouveau: fix uninitialised variable warning
drm/nouveau: Fix a crash at card takedown for NV40 and older cards
drm/nouveau: Free nv04 instmem ramin heap at card takedown
drm/nva3: somewhat improve clock reporting
drm/nouveau: pull refclk from vbios on limits 0x40 boards
drm/nv40/gr: oops, fix random bits getting set in engine obj
drm/nv50: improve nv50_pm_get_clock()
...
When xorg state tracker wants to hide the cursor it calls set_cursor
with NULL buffer_handle and size=0x0, but nouveau refuses to hide it
because size is not 64x64... which is a bit odd. Both radeon and intel
check buffer_handle before validating size of cursor, so make nouveau
implementation consistent with them.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The core/mem/shader clocks don't support the fractional feedback divider,
causing our calculated clocks to be off by quite a lot in some cases. To
solve this we will switch to a search-based algorithm when fN is NULL.
For my NVA8 at PL3, this actually generates identical cooefficients to
the binary driver. Hopefully that's a good sign, and that does not
break VPLL calculation for someone..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Hopefully this is how we're supposed to correctly handle when the RAMCFG
strap is above the number of entries in timing-related tables.
It's rather difficult to confirm without finding a configuration where
the ram restrict table doesn't map 8-15 back onto 0-7 anyway. There's
not a single vbios in the repo which is configured differently..
In any case, this is probably still better than potentially reading
outside of the bounds of various tables..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to parse some of these other entries still, but I've yet to
determine exactly which PLLs the rest map to.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Really not necessary here, we want to be able to see if/how we managed to
match a timingset to a performance level, even if we can't currently
program it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Again, doesn't quite match NVIDIA's, but not sure it really matters. This
will however, match the same rules we use to calculate the other related
grctx magics.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
After looking at a number of different logs, it appears 0x41 likely
indicates the presense of an LVDS panel following the SPWG spec
(http://www.spwg.org/)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NV40 and older cards (pre NV50) reserve a vram bo for the vga memory at
card init. This bo is then freed at card shutdown. The problem is that
the ttm bo vram manager was already freed. So a crash occurs when the
vga bo is freed. The fix is to free the vga bo prior to freeing the ttm
bo vram manager. There might be other solutions but this seemed the
simplest to me.
Signed-off-by: Jimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Definitely not 100% correct, but, for the configurations I've seen used
it'll read back the correct clocks now.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Many of the nv50 cards have their shader and/or memory pll
disabled at some stage.
This patch addresses those cases, so that the function
returns the correct frequency.
When the shader pll is disabled, the blob reports 2*core clock
Whereas for memory, the data stored in the vbios. This action
is incorrect as some vbioses store a clock value that is less
than the refference clock of the pll.
Thus we are reporting the reff_clk as it is the frequency the
pll actually operates
v2 - Convert NV_INFO() messages to NV_DEBUG()
Provide more information in the actuall message
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Reported-by: Stratos Psomadakis <psomas@ece.ntua.gr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The nouveau_wait_for_idle() call should hopefully not have been actually
necessary, we *do* wait for the channel to go idle already. If it's
an issue somehow, the chipset-specific hooks can wait for idle themselves
before taking the lock.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In the very least VPE (PMPEG and friends) also has this style of tile
region regs, lets make them just work if/when they get added.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This needs a massive cleanup, but to catch bugs from the interface changes
vs the engine code cleanup, this will be done later.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's lots of more-or-less independant engines present on NVIDIA GPUs
these days, and we generally want to perform the same operations on them.
Implementing new ones requires hooking into lots of different places,
the aim of this work is to make this simpler and cleaner.
NV84:NV98 PCRYPT moved over as a test.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Explanation is in the commit. If anyone has an example of where this is
*not* the case, please report it!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Improves the parsing of the memory timing table on NV50-NV98revA1 chipsets.
Added stepping to drm_nouveau_private to make sure newer NV98 (105M) is
zero rather than incorrect.
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch fixes messages such as
ERROR: space required after that ','
ERROR: spaces required around that '='
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Fix 'ERROR: that open brace { should be on the previous line'
Fix 'ERROR: else should follow close brace }'
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Fix 'ERROR: trailing whitespace',
Fix 'ERROR: do not use C99 // comments'
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Fix 'ERROR: code indent should use tabs where possible'
Fix 'ERROR: space required before the open parenthesis ('
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
* 'keithp/drm-intel-next' of /ssd/git/drm-next: (301 commits)
drm/i915: split PCH clock gating init
drm/i915: add Ivybridge clock gating init function
drm/i915: Update the location of the ringbuffers' HWS_PGA registers for IVB.
drm/i915: Add support for fence registers on Ivybridge.
drm/i915: Use existing function instead of open-coding fence reg clear.
drm/i915: split clock gating init into per-chipset functions
drm/i915: set IBX pch type explicitly
drm/i915: add Ivy Bridge PCI IDs and driver feature structs
drm/i915: add PantherPoint PCH ID
agp/intel: add Ivy Bridge support
drm/i915: ring support for Ivy Bridge
drm/i915: page flip support for Ivy Bridge
drm/i915: interrupt & vblank support for Ivy Bridge
drm/i915: treat Ivy Bridge watermarks like Sandy Bridge
drm/i915: manual FDI training for Ivy Bridge
drm/i915: add swizzle/tiling support for Ivy Bridge
drm/i915: Ivy Bridge has split display and pipe control
drm/i915: add IS_IVYBRIDGE macro for checks
drm/i915: add IS_GEN7 macro to cover Ivy Bridge and later
drm/i915: split enable/disable vblank code into chipset specific functions
...
My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work. Setting i915.semaphore=0 fixes it.
Semaphores were disabled in a1656b9090
in 2.6.38 and were re-enabled by
commit 47ae63e0c2
Merge: c59a333467cffb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 7 12:32:44 2011 +0000
Merge branch 'drm-intel-fixes' into drm-intel-next
Apply the trivial conflicting regression fixes, but keep GPU semaphores
enabled.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem_execbuffer.c
(It's worth noting that the offending change is i915_drv.c,
which is not a conflict.)
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the requested device is already active, ignore the request.
This restores the original behaviour of the interface. The change was
probably an unintended side effect of
commit 66b37c6777 vga_switcheroo: split switching into two stages
which did not take into account to duplicate the !active check in the split-off
stage2.
Fix this by factoring that check out of stage1 into the debugfs_write routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=34252
Reported-by: Igor Murzov <e-mail@date.by>
Tested-by: Igor Murzov <e-mail@date.by>
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ibex Peak and CougarPoint already require a different setting (added
here), and future chips will likely follow that precedent.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Some of the bits have changed, including one we were setting that enables
a VGA test mode, preventing pipe B from working at all. So add a new
IVB specific function with the right bits.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
They have been moved from the ringbuffer groups to their own group it
looks like. Fixes GPU hangs on gnome startup.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The registers are the same as on Sandybridge. Fixes scrambled display
in X when it does software drawing to the GTT, and scans the results
out as tiled.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is once less place to miss a new INTEL_INFO(dev)->gen update now.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This helps contain the mess to init_display() instead.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a little less confusing than relying on the implicit zeroing of
the dev_priv.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
There are several variants, set feature bits appropriately for both
mobile and desktop parts.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We can treat PantherPoint as CougarPoint as far as display goes.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Use Sandy Bridge paths in a few places.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Treat Ivy Bridge like previous chips as far as flip submission is
concerned.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Add new interrupt handling functions for Ivy Bridge.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Not fully tested.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
A0 stepping chips need to use manual training, but the bits have all
moved. So fix things up so we can at least train FDI for VGA links.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Treat it like Ironlake and Sandy Bridge.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Ivy Bridge has a similar split display controller to Sandy Bridge, so
use HAS_PCH_SPLIT. And gen7 also has the pipe control instruction, so
use HAS_PIPE_CONTROL as well.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Note: IS_GEN* are for render related checks. Display and other checks
should use IS_MOBILE, IS_$CHIPSET or test for specific features.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This makes the Ironlake+ code trivial and generally simplifies things.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Set the IRQ handling functions in driver load so they'll just be used
directly, rather than branching over most of the code in the chipset
functions.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Rather than branching in ironlake_pch_enable, add a new train_fdi
function to the display function pointer struct and use it instead.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Forcewake needs to register itself with drm to use the remove function.
The file also should be read only.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
On rev <= 1.1 tables, the offset is absolute,
on newer tables, it's relative.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=700326
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The location of MC_ARB_RAMCFG changed on fusion.
I've diffed all the other regs in evergreend.h and this
is the only other reg that changed.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 49183b2818.
Quoth Franz Melchior:
"This patch introduces a bug on my infamous "Acer Travelmate
5735Z-452G32Mnss": when KMS takes over, the frame buffer contents get
completely garbled up on screen, with colored stripes and unreadable
text (photo on request). Only when X11 is started, the screen gets
restored again. Closing and re-opening the lid partly cures the
mess, too: it makes the font readable, though horizontally stretched."
Acked-by: Keith Packard <keithp@keithp.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Xen changes were using DMA_ERROR_CODE which isn't defined on a few
platforms, however we reverted the Xen patch that caused use to try and
use this code path earlier in 2.6.39 cycle, so for now lets just force
the code to never take this path and allow it to build again on alpha.
The proper long term answer is probably to store if the dma_addr has
been assigned to alongside the dma_addr in the higher level code,
though I think Thomas wanted to rewrite most of this anyways properly.
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The TCC disable setup was incorrect. This
prevents the GPU from hanging when draw commands
are issued.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We are accessing totally the wrong struct in this case, and putting
uninitialised values into the GPU, which it doesn't like unsurprisingly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
forcewake is controlled by the open and close of the debugfs file. This
assures that buggy applications cannot cause the GT to stay on forever.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
The render P-state handling code requires reading from a GT register.
This means that FORCEWAKE must be written to, a resource which is shared
and should be protected by struct_mutex. Hence we can not manipulate
that register from within the interrupt handling and so must delegate
the task to a workqueue.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Found by the new strict checking for the mutex being held whilst
manipulating the forcewake status.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Provide a reference count to track the forcewake state of the GPU and
give a safe mechanism for userspace to wake the GT. This also potentially
saves a UC read if the GT is known to be awake already.
The reference count is atomic, but the register access and hardware wake
sequence is protected by struct_mutex.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Moved the macros around to properly do reads and writes for the given
GPU. This is to address special requirements for gen6 (SNB) reads and
writes.
Registers in the range 0-0x40000 on gen6 platforms require special
handling. Instead of relying on the callers to pick the registers
correctly, move the logic into the read and write functions.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the outputs are active and continuing to access the GATT when we
teardown the PTEs, then there is a potential for us to hang the GPU.
The hang tends to be a PGTBL_ER with either an invalid host access or
an invalid display plane fetch.
v2: Reorder IRQ initialisation to defer until after GEM is setup.
Reported-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (855GM)
Tested-by: Pekka Enberg <penberg@kernel.org>
# note that this doesn't fix the underlying problem of the
PGTBL_ER and pipe underruns being reported immediately upon
init on his 965GM MacBook
Reported-and-tested-by: Rick Bramley <richard.bramley@hp.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35635
Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36048
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Rely on the GPU snooping into the CPU cache for appropriately bound
objects on MI_FLUSH. Or perhaps one day we will have a cache-coherent
CPU/GPU package...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
... to clarify just how we use it inside the driver and remove the
confusion of the poorly matching agp_type names. We still need to
translate through agp_type for interface into the fake AGP driver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
Currently this is only useful for the rc6 stuff. But this would also be
useful when I finally get around to the logical context + ppgtt stuff.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
For debug & testing.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is a race condition between setting PWRCTXA and executing
MI_SET_CONTEXT. PWRCTXA must not be set until a valid context has been
written (or else the GPU could possible go into rc6, and return to an
invalid context).
Reported-and-Tested-by: Gu Rui <chaos.proton@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Added a new function which waits for the ringbuffer space to be equal to
(total - 8). This is the empty condition of the ringbuffer, and
equivalent to head==tail.
Also modified two users of this functionality elsewhere in the code.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the failure cases during rc6 initialization, both the power context
and render context may get !refcount without holding struct_mutex.
However, on rc6 disabling, the lock is held by the caller.
Rearranged the locking so that it's safe in both cases.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
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>
They're used in one place, and not providing any descriptive value,
with their names just being approximately the conjunction of the
struct name and the struct field.
This diff was produced with gcc -E, copying the new struct definitions
out, moving a couple of the old comments into place in the new
structs, and reindenting.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We used to have these from the product of (pch, non-pch) * (pipe a,
pipe b). Now we can just use the nice per-pipe reg macros in the
split out crtc_mode_sets.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
While g4x had DP, eDP came with Ironlake, so we don't need that code here.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This path, which shouldn't be *that* complicated, is now so littered
with per-chipset tweaks that it's hard to trace the order of what
happens. HAS_PCH_SPLIT() is the most radical change across chipsets,
so it seems like a natural split to simplify the code.
This first commit just copies the existing code without changing
anything.
v2: updated to track removal of call to intel_enable_plane from i9xx_crtc_mode_set
Signed-off-by: Eric Anholt <eric@anholt.net>
Hella-acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to ensure that we feed valid memory into the display plane
attached to the pipe when switching the pipe on. Otherwise, the display
engine may read through an invalid PTE and so throw an PGTBL_ER
exception.
As we need to perform load detection before even the first object is
allocated for the fbdev, there is no pre-existing object large enough
for us to borrow to use as the framebuffer. So we need to create one
and cleanup afterwards. At other times, the current fbcon may be large
enough for us to borrow it for duration of load detection.
Found by assert_fb_bound_for_plane().
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
As we now never attempt to steal a crtc for load detection, we either
set a mode on a new pipe, or change the dpms mode on an existing pipe.
Never both, so we can simplify the code slightly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
As we only allow the use of a disabled CRTC, we don't need to handle the
case where we are reusing an already enabled pipe.
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>
... and the no longer relevant comment. The code ceased stealing a pipe
for load detection a long time ago.
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>
Keep all the state required for undoing and restoring the previous pipe
configuration together in a single struct passed from
intel_get_load_detect_pipe() to intel_release_load_detect_pipe() rather
than stuffing them inside the common encoder structure.
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>
Check the return value from drm_crtc_set_mode(), report the failure
via a debug message and propagate the error back to the caller. This
prevents us from blissfully continuing to do the load detection on a
disabled pipe. Fortunately actual failure for modesetting is very rare,
and reported failures even rarer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
... and so remove the confusion as to whether to use the returned crtc
or intel_encoder->base.crtc with the subsequent load-detection. Even
though they were the same, the two instances of load-detection code
disagreed over which was the more correct.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Required so that we don't obliterate the queue if initialising the
rings after the global IRQ handler is installed.
[Jesse, you recently looked at refactoring the IRQ installation
routines, does moving the initialisation of ring buffer data structures away
from that routine make sense in your grand scheme?]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915/lvds: Only act on lid notify when the device is on
drm/i915: fix intel_crtc_clock_get pipe reads after "cleanup cleanup"
drm/i915: Only enable the plane after setting the fb base (pre-ILK)
drm/i915/dp: Be paranoid in case we disable a DP before it is attached
drm/i915: Release object along create user fb error path
If we're using vga switcheroo, the device may be turned off
and poking it can return random state. This provokes an OOPS fixed
separately by 8ff887c847 (drm/i915/dp: Be paranoid in case we disable a
DP before it is attached). Trying to use and respond to events on a
device that has been turned off by the user is in principle a silly thing
to do.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
Despite the fixes in 548f245ba6 (drm/i915: fix per-pipe reads after
"cleanup"), we missed one neighbouring read that was mistakenly replaced
with the reg value in 9db4a9c (drm/i915: cleanup per-pipe reg usage).
This was preventing us from correctly determining the mode the BIOS left
the panel in for machines that neither have an OpRegion nor access to
the VBT, (e.g. the EeePC 700).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
When enabling the plane, it is helpful to have already pointed that
plane to valid memory or else we may incur the wrath of a PGTBL_ER.
This code preserved the behaviour from the bad old days for unknown
reasons...
Found by assert_fb_bound_for_plane().
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
* korg/drm-nvidia-switch-fixes:
mxm/wmi: add MXMX interface entry point.
nouveau: add optimus detection to DSM code.
vgaarb: use bridges to control VGA routing where possible.
nouveau/acpi: hook up to the MXM method for mux switching.
platform/x86: add MXM WMI driver.
The virtual i2c to real i2c channel mappings weren't setting
the right id in some cases.
Spotted by: Andrew Randrianasulu
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
if object pin or object lookup in radeon_cursor_set fail, the function
could leave inconsistent mouse width and hight values in radeon_crtc
fixed by moving cursor width and height assignments after all
checks have passed
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The looping helper didn't do anything due to a superficial
semicolon. Furthermore one of the two dump functions suffered
from copy&paste fail.
While staring at the code I've also noticed that the replace
helper (currently unused) is a bit broken.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we switch the display mux, also switch
the i2c mux. Also use the start and finish
methods to let the sbios know that the switch
is happening.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=35398
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
NV40 and older cards (pre NV50) reserve a vram bo for the vga memory at
card init. This bo is then freed at card shutdown. The problem is that
the ttm bo vram manager was already freed. So a crash occurs when the
vga bo is freed. The fix is to free the vga bo prior to freeing the ttm
bo vram manager. There might be other solutions but this seemed the
simplest to me.
Signed-off-by: Jimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Given that the hardware may be left in a random condition by the BIOS,
it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
without us ever enabling/attaching the DP encoder to a pipe. Thus
causing a NULL deference when we attempt to wait for a vblank on that
crtc.
Reported-and-tested-by: Bryan Christ <bryan.christ@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456
Reported-and-tested-by: Bo Wang <bo.b.wang@intel.com>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
Reported-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
This is unbalanced and probably more fitting for the client
to take care of. Remove it.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So in a lot of modern systems, a GPU will always be below a parent bridge that won't share with any other GPUs. This means VGA arbitration on those GPUs can be controlled by using the bridge routing instead of io/mem decodes.
The problem is locating which GPUs share which upstream bridges. This patch attempts to identify all the GPUs which can be controlled via bridges, and ones that can't. This patch endeavours to work out the bridge sharing semantics.
When disabling GPUs via a bridge, it doesn't do irq callbacks or touch the io/mem decodes for the gpu.
Signed-off-by: Dave Airlie <airlied@redhat.com>
this hooks up nouveau to the MXM mux switching method.
With this in place I can switch the LVDS MUX on my T410s,
I expect we need a bit more work for other laptops.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix the vbios mapping and only add the actual
buses that the cards have. The existing code was
mostly correct. Just clean up a few cases on r2xx/r3xx
and document that buses the hw actually has.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The most common use of the radeon i2c buses is for ddc.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The previous commit to move the parsing into the core drm created a
new situation and a soft dependency on the CONFIG_FB. We really don't
want to make this a hard dependency so just wrap the one place that
actually needs an fb symbol.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Out of the entire GART/VM subsystem, the hw designers changed
the location of 3 regs.
v2: airlied: add parameter for userspace to work from.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the least-bad behaviour. It means that we signal the
vblank event before it actually happens, but since we're disabling
vblanks there's no guarantee that it will *ever* happen otherwise.
This prevents GL applications which use WaitMSC from hanging
indefinitely.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since fafcf94e2b introduced an edid size, it seems to have broken this path.
This manifest as oops on T500 Lenovo laptops with dual graphics primarily.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33812
cc: stable@kernel.org
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the absence of configuration data for providing the fixed mode for
a panel, I would like to be able to pass such modes along a separate
module paramenter. To do so, I then need to parse a modeline from a
string, which drm is already capable of. Export that capability to the
drivers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
and fix fallout.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reduce drm text size ~1% by using drm_err and
printf extension %pV to emit error messages.
Remove unused macro DRM_MEM_ERROR.
$ size drivers/gpu/drm/built-in.o*
text data bss dec hex filename
361159 9663 256 371078 5a986 drivers/gpu/drm/built-in.o.new
365416 9663 256 375335 5ba27 drivers/gpu/drm/built-in.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:
[ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[ 17.772458] Hardware name: Latitude E6400
[ 17.772460] Modules linked in: ....
[ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8
[ 17.772584] Call Trace:
[ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82
[ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: Frederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
[airlied: tweaked to fix inter-patch dependency]
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
i915 calls the panic handler function on last close to reset the modes,
however this is a really bad idea for multi-gpu machines, esp shareable
gpus machines. So add a new entry point for the driver to just restore
its own fbcon mode.
v2: move code into fb helper, fix panic code to block mode change on
powered off GPUs.
[airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx
so really I signed it off twice ;-).]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Multi-gpu/switcheroo relies on this option to get the console on the
correct GPU at bootup, some distros enable it but it seems some get
it wrong.
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
agp: fix arbitrary kernel memory writes
agp: fix OOM and buffer overflow
drm/radeon/kms: fix IH writeback on r6xx+ on big endian machines
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: Initialise g4x watermarks for disabled pipes
drm/i915: Sanitize the output registers after resume
drm/i915/tv: Fix modeset flickering introduced in 7f58aabc3
drm/i915/tv: Only poll for TV connections
drm/i915/tv: Remember the detected TV type
Commit 73412c3854 ("drm/nouveau: allocate
kernel's notifier object at end of block") intended to align end of
notifier block to page boundary, but start of block was miscalculated
to be off by -16 bytes. Fix it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes,
so after commit 73412c3854 ("drm/nouveau: allocate
kernel's notifier object at end of block") we started to overwrite some memory
after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't
matter it was a value in bytes).
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Reported-by: Nigel Cunningham <lkml@nigelcunningham.com.au>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Pekka Paalanen <pq@iki.fi>
Cc: stable@kernel.org [2.6.38]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Wasn't aware they even existed, apparently they do! They're actually
AGP chips with a bridge as far as I can tell, which puts them in the
same boat as nv40/nv45.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes a possible lock ordering reversal between context_switch_lock
and ramin_lock.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This patch fixes two issues:
- A disabled crtc does not use any lb, so return 0 for
lb size. This makes the display priority calculation
more exact.
- Only use 1/2 and whole lb partitions. Using smaller
partitions can cause underflow to one of the displays
if you have multiple large displays on the same lb.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=34534
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sometimes the i2c test in i2c_bit_add_bus fails
if this happens we fail to register the i2c adapter and
eventually fail to add the connector. If i2c fails,
add the connector to the user can at least force
it on.
Note that some distros set i2c-algo-bit.bit_test to 1 by
default which sometimes fails preventing the ddc i2c adapter
from being added. The i2c adapter works even if the bit test
fails, probably due to pre/post_xfer not getting called in
the test_bit function. I have another patch to follow
up on that.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=36221
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were using uninitialised watermarks values for disabled pipes which
were combined into a single WM register and so corrupting the values for
the enabled pipe and upsetting the display hardware.
Reported-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 0a0883c843.
this was in my tree by accident, I meant to rebase it out and
didn't realise in time.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 69a07f0b11.
We've tracked a number of problems back to this, and Thomas
thinks we should redesign this for .40/41 anyways so I'm
happy to revert it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
fix Kconfig warning:
(DRM_I915 && STUB_POULSBO) selects ACPI_VIDEO which has unmet direct dependencies
(ACPI && X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL && INPUT)
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Change vddci as well as vddc when changing power modes
on evergreen/ni. Also, properly set vddci on boot up
for ni cards. The vbios only sets the limited clocks
and voltages on boot until the mc ucode is loaded. This
should fix stability problems on some btc cards.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is needed for setting voltages other than vddc.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
btc and cayman asics use the same callback for
pcie port registers.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Apparently only rv515 asics need the workaround
added in f24d86f1a4
(drm/radeon/kms: fix resume regression for some r5xx laptops).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=34709
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
As per Konrad's original patch, the dummy page used
by the gart code and allocated in radeon_gart_init()
was not freed properly in radeon_gart_fini().
At the same time r6xx and newer allocated and freed the
dummy page on their own. So to do Konrad's patch one
better, just remove the allocation and freeing of the
dummy page in the r6xx, 7xx, evergreen, and ni code and
allocate and free in the gart_init/fini() functions for
all asics.
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Similar to booting, we need to inspect the state left by the BIOS and
remove any conflicting bits before we take over. The example reported by
Seth Forshee is very similar to the bug we encountered with the state left
by grub2, that the crtc pipe<->planning mapping was reversed from our
expectations and so we failed to turn off the outputs when booting or,
in this case, resuming. This may be in fact the same bug, but triggered
at resume time.
This patch rearranges the code we already have to clear up the
conflicting state upon init and calls it from reset (which is called
after we have lost control of the hardware, i.e. along both the boot and
resume paths) instead.
Reported-and-tested-by: Seth Forshee <seth.forshee@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The tidy ups in 7f58aabc36 ("drm/i915:
cleanup per-pipe reg usage") changed intel_crtc->plane to intel_crtc->pipe in
intel_tv_mode_set(). This caused the screen to quickly turn off before
returning whenever modesetting/mode probing took place on my 915GM EeePC
900 creating a flickering effect. This patch changes intel_crtc->pipe back
to intel_crtc->plane which solves the problem for me.
References: https://bugs.freedesktop.org/show_bug.cgi?id=35903
Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Humbly-acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
As a probe for a TV connection modifies the TV_CTL register, it causes a
loss of sync and a regular glitch on the output. This is highly
undesirable when using the TV, so only poll for TV connections and wait
for an explicit query for detecting the disconnection event.
Reported-by: Mathew McKernan <matmckernan@rauland.com.au>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977
Signed-off-by: Mathew McKernan <matmckernan@rauland.com.au>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
During detect() we would probe the connection bits to determine if
there was a TV attached, and what video input type (Component, S-Video,
Composite, etc) to use. However, we promptly discarded this vital bit of
information and never propagated it to where it was used to determine
the correct modes and setup the control registers. Fix it!
This fixes a regression from 7b334fcb45.
Reported-and-tested-by: Mathew McKernan <matmckernan@rauland.com.au>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977
Signed-off-by: Mathew McKernan <matmckernan@rauland.com.au>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
* 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next:
drm/nvc0: improve vm flush function
drm/nv50-nvc0: remove some code that doesn't belong here
drm/nv50: use "nv86" tlb flush method on everything except 0x50/0xac
drm/nouveau: quirk for XFX GT-240X-YA
drm/nv50-nvc0: work around an evo channel hang that some people see
drm/nouveau: implement init table opcode 0x5c
drm/nouveau: fix oops on unload with disabled LVDS panel
nv30: Fix parsing of perf table
drm/nouveau: correct memtiming table parsing for nv4x
There's no need to pass kref_put() the address of a function (just the
function will do just fine) nor to cast its unused return to void.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Switch some errors to debug output. These are generally harmless
and tend to confuse users.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is necessary even with PCI(e) GART, and it makes writeback work even with
AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth
and other AGP bridges though.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Reviewed-by: Alex Deucher <alex.deucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This has always used a big hammer, but that hammer is probably
too big, I'm also not sure its necessary but at least this
should be safe.
Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=23592
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a revert of 428d2e828c.
This is broken in the same manner as for VGA: trying to write to an
invalid address on the (currently 7-bit) i2c bus.
One notable failure appears to be for MacBooks. The scary part was that
it gave the appearance of working (i.e. reporting the absence of the
panel) on various all-in-one machines with ghost LVDS panels and not
failing for laptops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a moral revert of 6ec3d0c0e9.
Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that the code
is broken. Shock.
There are a number of issues, but following a key insight from Dave
Airlie, that 0xA0 is an invalid address on a 7-bit bus (though not if we
were to enable 10-bit addressing), and would look like the EDID port
0x50, it is possible to see where the confusion starts.
In short, a write to 0xA0 is accepted by the GMBUS controller which we
interpreted as meaning the existence of a connection (a slave on the
other end of the wire ACKing the write). That was false.
During testing with a broken GMBUS implementation, which never reset an
earlier NAK, this test always reported a NAK and so we proceeded on to
the next test.
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35904
Reported-and-tested-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Keith Packard <keithp@keithp.com>
It has been reported that this greatly improves (and possibly fixes
completely) the stability of NVA3+ chipsets. In traces of my NVA8,
NVIDIA now appear to be doing this too.
The most recent traces of 0x50 and 0xac I could find don't show NVIDIA
checking PGRAPH status on these flushes, so for now, we won't either.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Perf tables v 1.2 and 1.3 (seen on Geforce FX/ 5) are not long enough
to store the voltage label/id
v2 - Remove comment from the code
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In line with envytools, verified on 4 or 5 BIOS'es.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Avoid touching the flip setup regs while
acceleration is running. Set them at modeset
rather than during pageflip. Touching these
regs while acceleration is active caused hangs
on pre-avivo chips. These chips do not seem
to be affected, but better safe than sorry,
plus it avoids repeatedly reprogramming the
regs every flip.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'keithp/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915: Reset GMBUS controller after NAK
drm/i915: Busy-spin wait_for condition in atomic contexts
drm/i915/lvds: Always return connected in the absence of better information
Nouveau needs access to this structure to build an ELD block for use
by the HDA audio codec.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.
If we don't clear the NAK, then all future GMBUS xfers will fail,
including DDC probes and EDID retrieval.
v2: Add some comments as suggested by Keith Packard.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: "Mengmeng Meng" <mengmeng.meng@intel.com>
During modesetting, we need to wait for the hardware to report
readiness by polling the registers. Normally, we call msleep() between
reads, because some state changes may take a whole vblank or more
to complete. However during a panic, we are in an atomic context and
cannot sleep. Instead, busy spin polling the termination condition.
References: https://bugzilla.kernel.org/show_bug.cgi?id=31772
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/vblank: update recently added vbl interface to be more future proof.
drm radeon: Return -EINVAL on wrong pm sysfs access
drm/radeon/kms: fix hardcoded EDID handling
Revert "drm/i915: Don't save/restore hardware status page address register"
drm/i915: Avoid unmapping pages from a NULL address space
drm/i915: Fix use after free within tracepoint
drm/i915: Restore missing command flush before interrupt on BLT ring
drm/i915: Disable pagefaults along execbuffer relocation fast path
drm/i915: Fix computation of pitch for dumb bo creator
drm/i915: report correct render clock frequencies on SNB
drm/i915/dp: Correct the order of deletion for ghost eDP devices
drm/i915: Fix tiling corruption from pipelined fencing
drm/i915: Re-enable self-refresh
drm/i915: Prevent racy removal of request from client list
drm/i915: skip redundant operations whilst enabling pipes and planes
drm/i915: Remove surplus POSTING_READs before wait_for_vblank
drm/radeon/kms: prefer legacy pll algo for tv-out
drm: check for modesetting on modeset ioctls
drm/kernel: vblank wait on crtc > 1
drm: Fix use-after-free in drm_gem_vm_close()
The LVDS connector should default to connected. We tried our best to
verify the claims of the BIOS that the hardware exists during init(),
and then during detect() we then try to verify that the panel is open.
In the event of an unsuccessful query, we should then always report
that the LVDS panel is connected. This was only the case for gen2/3,
later generations leaked the return value from the panel probe instead.
Reported-and-tested-by: Alessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
This makes the interface a bit cleaner by leaving a single gap in the
vblank bit space instead of creating two gaps.
Suggestions from Michel on mailing list/irc.
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Throw an error if someone tries to fill this with
wrong data, instead of simply ignoring the input.
Now you get:
echo hello >/sys/../power_method
-bash: echo: write error: Invalid argument
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Alexander.Deucher@amd.com
CC: dri-devel@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On some servers there is a hardcoded EDID provided
in the vbios so that the driver will always see a
display connected even if something like a KVM
prevents traditional means like DDC or load
detection from working properly. Also most
server boards with DVI are not actually DVI, but
DVO connected to a virtual KVM service processor.
If we fail to detect a monitor via DDC or load
detection and a hardcoded EDID is available, use
it.
Additionally, when using the hardcoded EDID, use
a copy of it rather than the actual one stored
in the driver as the detect() and get_modes()
functions may free it if DDC is successful.
This fixes the virtual KVM on several internal
servers.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-fixes' of ../drm-next:
Revert "drm/i915: Don't save/restore hardware status page address register"
drm/i915: Avoid unmapping pages from a NULL address space
drm/i915: Fix use after free within tracepoint
drm/i915: Restore missing command flush before interrupt on BLT ring
drm/i915: Disable pagefaults along execbuffer relocation fast path
drm/i915: Fix computation of pitch for dumb bo creator
drm/i915: report correct render clock frequencies on SNB
drm/i915/dp: Correct the order of deletion for ghost eDP devices
drm/i915: Fix tiling corruption from pipelined fencing
drm/i915: Re-enable self-refresh
drm/i915: Prevent racy removal of request from client list
drm/i915: skip redundant operations whilst enabling pipes and planes
drm/i915: Remove surplus POSTING_READs before wait_for_vblank
This reverts commit a7a75c8f70.
There are two different variations on how Intel hardware addresses the
"Hardware Status Page". One as a location in physical memory and the
other as an offset into the virtual memory of the GPU, used in more
recent chipsets. (The HWS itself is a cacheable region of memory which
the GPU can write to without requiring CPU synchronisation, used for
updating various details of hardware state, such as the position of
the GPU head in the ringbuffer, the last breadcrumb seqno, etc).
These two types of addresses were updated in different locations of code
- one inline with the ringbuffer initialisation, and the other during
device initialisation. (The HWS page is logically associated with
the rings, and there is one HWS page per ring.) During resume, only the
ringbuffers were being re-initialised along with the virtual HWS page,
leaving the older physical address HWS untouched. This then caused a
hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried
to synchronise the GPU as the breadcrumbs were never being updated.
Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Jan Niehusmann <jan@gondor.com>
Reported-and-tested-by: Justin P. Mattock <justinmattock@gmail.com>
Reported-and-tested-by: Michael "brot" Groh <brot@minad.de>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This reverts commit a7a75c8f70.
There are two different variations on how Intel hardware addresses the
"Hardware Status Page". One as a location in physical memory and the
other as an offset into the virtual memory of the GPU, used in more
recent chipsets. (The HWS itself is a cacheable region of memory which
the GPU can write to without requiring CPU synchronisation, used for
updating various details of hardware state, such as the position of
the GPU head in the ringbuffer, the last breadcrumb seqno, etc).
These two types of addresses were updated in different locations of code
- one inline with the ringbuffer initialisation, and the other during
device initialisation. (The HWS page is logically associated with
the rings, and there is one HWS page per ring.) During resume, only the
ringbuffers were being re-initialised along with the virtual HWS page,
leaving the older physical address HWS untouched. This then caused a
hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried
to synchronise the GPU as the breadcrumbs were never being updated.
Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Jan Niehusmann <jan@gondor.com>
Reported-by: Justin P. Mattock <justinmattock@gmail.com>
Reported-and-tested-by: Michael "brot" Groh <brot@minad.de>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We always skipped flushing the BLT ring if the request flush did not
include the RENDER domain. However, this neglects that we try to flush
the COMMAND domain after every batch and before the breadcrumb interrupt
(to make sure the batch is indeed completed prior to the interrupt
firing and so insuring CPU coherency). As a result of the missing flush,
incoherency did indeed creep in, most notable when using lots of command
buffers and so potentially rewritting an active command buffer (i.e.
the GPU was still executing from it even though the following interrupt
had already fired and the request/buffer retired).
As all ring->flush routines now have the same preconditions, de-duplicate
and move those checks up into i915_gem_flush_ring().
Fixes gem_linear_blit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35284
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: mengmeng.meng@intel.com
Along the fast path for relocation handling, we attempt to copy directly
from the user data structures whilst holding our mutex. This causes
lockdep to warn about circular lock dependencies if we need to pagefault
the user pages. [Since when handling a page fault on a mmapped bo, we
need to acquire the struct mutex whilst already holding the mm
semaphore, it is then verboten to acquire the mm semaphore when already
holding the struct mutex. The likelihood of the user passing in the
relocations contained in a GTT mmaped bo is low, but conceivable for
extreme pathology.] In order to force the mm to return EFAULT rather
than handle the pagefault, we therefore need to disable pagefaults
across the relocation fast path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix up the debug file to report the right frequencies. On SNB, we program
the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU
side. But GFX only runs at half that, so report it as such to avoid
confusion.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
The order of the calls does matter indeed. Swapping the call order of
intel_dp_destroy() and intel_dp_encoder_destroy() fixes the problem.
This is because i2c_del_adapter unregisters the device which parent is
intel_connector, and connectors are removed in intel_dp_destroy(). Thus
intel_dp_encoder_destroy() must be called before intel_dp_destroy().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
... even though it was disabled. A mistake in the handling of fence reuse
caused us to skip the vital delay of waiting for the object to finish
rendering before changing the register. This resulted in us changing the
fence register whilst the bo was active and so causing the blits to
complete using the wrong stride or even the wrong tiling. (Visually the
effect is that small blocks of the screen look like they have been
interlaced). The fix is to wait for the GPU to finish using the memory
region pointed to by the fence before changing it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Note for 2.6.38-stable, we need to reintroduce the interruptible passing]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Dave Airlie <airlied@linux.ie>
A broken implementation of is_pot() prevented the detection of when a
singular pipe was enabled. Eric Anholt pointed out the existence of
is_power_of_2() so use that instead of our broken code!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402
Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com>
Tested-by: xunx.fang@intel.com
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client,
the client_list for that request may already be removed in i915_gem_release.
So we may call twice list_del(&request->client_list), resulting in an
oops like this report:
[126167.230394] BUG: unable to handle kernel paging request at 00100104
[126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000
[126167.231314] Oops: 0002 [#1] SMP
[126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
[126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci
[126167.232018]
[126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway MC7833U /
[126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0
[126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100
[126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
[126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000)
[126167.232018] Stack:
[126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85
[126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040
[126167.232018] f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214
[126167.232018] Call Trace:
Unfortunately the call trace reported was cut, but looking at debug
symbols the crash is at __list_del, when probably list_del is called
twice on the same request->client_list, as the dereferenced value is
LIST_POISON1 + 4, and by looking more at the debug symbols before
list_del call it should have being called by
i915_gem_request_remove_from_client
And as I can see in the code, it seems we indeed have the possibility
to remove a request->client_list twice, which would cause the above,
because we do list_del(&request->client_list) on both
i915_gem_request_remove_from_client and i915_gem_release
As Chris Wilson pointed out, it's indeed the case:
"(...) I had thought that the actual insertion/deletion was serialised
under the struct mutex and the intention of the spinlock was to protect
the unlocked list traversal during throttling. However, I missed that
i915_gem_release() is also called without struct mutex and so we do need
the double check for i915_gem_request_remove_from_client()."
This change does the required check to avoid the duplicate remove of
request->client_list.
Bugzilla: http://bugs.launchpad.net/bugs/733780
Cc: stable@kernel.org # 2.6.38
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay. Similarly if it is already disabled
when we want to disable it, we can also skip it.
This fixes a regression from b24e717988, which caused the LVDS
output on one PineView machine to become corrupt after changing
orientation several times.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: mengmeng.meng@intel.com
... as wait_for_vblank (and friends) will do a flush of the MMIO writes
anyway.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We may eventually end up with per-connector backlights, especially with
ddcci devices. Make sure that the parent node for the backlight device is
the connector rather than the PCI device.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
[mjg@redhat.com: updated to add backlight type and make the connector the parent device]
Signed-off-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Acked-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There may be multiple ways of controlling the backlight on a given
machine. Allow drivers to expose the type of interface they are
providing, making it possible for userspace to make appropriate policy
decisions.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The below patch fixes a typo occationally to occasionally.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Noticed this while working on some other things, helps if we check for modeset
enabled on modesetting ioctls.
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two threads:
http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.htmlhttp://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
can be represented. It also adds a new capability to drm_getcap ioctl so
that the user space can check whether the new interface to drm_wait_vblank
is supported (and fall back to the legacy interface if not)
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>
Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (47 commits)
doc: CONFIG_UNEVICTABLE_LRU doesn't exist anymore
Update cpuset info & webiste for cgroups
dcdbas: force SMI to happen when expected
arch/arm/Kconfig: remove one to many l's in the word.
asm-generic/user.h: Fix spelling in comment
drm: fix printk typo 'sracth'
Remove one to many n's in a word
Documentation/filesystems/romfs.txt: fixing link to genromfs
drivers:scsi Change printk typo initate -> initiate
serial, pch uart: Remove duplicate inclusion of linux/pci.h header
fs/eventpoll.c: fix spelling
mm: Fix out-of-date comments which refers non-existent functions
drm: Fix printk typo 'failled'
coh901318.c: Change initate to initiate.
mbox-db5500.c Change initate to initiate.
edac: correct i82975x error-info reported
edac: correct i82975x mci initialisation
edac: correct commented info
fs: update comments to point correct document
target: remove duplicate include of target/target_core_device.h from drivers/target/target_core_hba.c
...
Trivial conflict in fs/eventpoll.c (spelling vs addition)
Simplify the way the return value is set a number of times (mostly on
error).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge list_del() + list_add_tail() to list_move_tail().
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit changed an internal radeon structure, that meant a new driver
in -next had to be fixed up, merge in the commit and fix up the driver.
Also fixes a trivial nouveau merge.
Conflicts:
drivers/gpu/drm/nouveau/nouveau_mem.c
Usually EDID retrieval is fine. However, sometimes, especially when the
machine is loaded, it fails, but succeeds after a few retries.
Based on a patch by Michael Buesch.
Reported-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Typo in the aspect scale setup.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next:
drm/nouveau: fix __nouveau_fence_wait performance
drm/nv40: attempt to reserve just enough vram for all 32 channels
drm/nv50: check for vm traps on every gr irq
drm/nv50: decode vm faults some more
drm/nouveau: add nouveau_enum_find() util function
drm/nouveau: properly handle pushbuffer check failures
drm/nvc0: remove vm hack forcing large/small pages to not share a PDE
Commit 21e86c1c8a ("drm/nouveau: remove
cpu_writers lock") turned on lazy waits. Unfortunately
__nouveau_fence_wait was not optimized for this case and on HZ=100
kernel wasted up to 10 ms per call.
Depending on application, it led to 10-30% FPS regression.
Fix it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
This also makes the fact we're giving 512MiB of GART space to all PCIE
boards explicit, although the vast majority (if not all) of them will
now have a ramin_rsvd_vram larger than 2MiB anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Appears to be fixed with commit:
"drm/nv50-nvc0: make sure vma is definitely unmapped when destroying bo"
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
At least on my HP 2540p this is wrong at bootup, fine
at any other time once a lid event has occured. This is due to
_REG vs _INI ordering in the ACPI tables.
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-next' of ../drm-next: (755 commits)
drm/i915: Only wait on a pending flip if we intend to write to the buffer
drm/i915/dp: Sanity check eDP existence
drm/i915: Rebind the buffer if its alignment constraints changes with tiling
drm/i915: Disable GPU semaphores by default
drm/i915: Do not overflow the MMADDR write FIFO
Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
drm/i915: Don't save/restore hardware status page address register
drm/i915: don't store the reg value for HWS_PGA
drm/i915: fix memory corruption with GM965 and >4GB RAM
Linux 2.6.38-rc7
Revert "TPM: Long default timeout fix"
drm/i915: Re-enable GPU semaphores for SandyBridge mobile
drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#"
Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU"
drm/i915: Allow relocation deltas outside of target bo
drm/i915: Silence an innocuous compiler warning for an unused variable
fs/block_dev.c: fix new kernel-doc warning
ACPI: Fix build for CONFIG_NET unset
mm: <asm-generic/pgtable.h> must include <linux/mm_types.h>
x86: Use u32 instead of long to set reset vector back to 0
...
Conflicts:
drivers/gpu/drm/i915/i915_gem.c
So we used to use lpfn directly to restrict VRAM when we couldn't
access the unmappable area, however this was removed in
93225b0d7b as it also restricted
the gtt placements. However it was only later noticed that this
broke on some hw.
This removes the active_vram_size, and just explicitly sets it
when it changes, TTM/drm_mm will always use the real_vram_size,
and the active vram size will change the TTM size used for lpfn
setting.
We should re-work the fpfn/lpfn to per-placement at some point
I suspect, but that is too late for this kernel.
Hopefully this addresses:
https://bugs.freedesktop.org/show_bug.cgi?id=35254
v2: fix reported useful VRAM size to userspace to be correct.
Signed-off-by: Dave Airlie <airlied@redhat.com>
We've been getting reports of complete system lockups with rv3xx hw on
AGP and PCIE when running gnome-shell or kwin with compositing.
It appears the hw really doesn't like setting these registers while
stuff is running, this moves the setting of the registers into the modeset
since they aren't required to be changed anywhere else.
fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183
Reported-and-tested-by: Álmos <aaalmosss@gmail.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Looks like these got passed over with both being merged at the same
time but not quite meeting in the middle.
should fix: https://bugs.freedesktop.org/show_bug.cgi?id=34137
along with Michael's phoronix article.
Reported-by: Chi-Thanh Christopher Nguyen
Article-written-by: Michael Larabel @ phoronix
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 951f3512db
drm/i915: Do not handle backlight combination mode specially
since this commit introduced other regressions due to untouched LBPC
register, e.g. the backlight dimmed after resume.
In addition to the revert, this patch includes a fix for the original
issue (weird backlight levels) by removing the wrong bit shift for
computing the current backlight level.
Also, including typo fixes (lpbc -> lbpc).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Acked-by: Indan Zupancic <indan@nul.nu>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ickle/drm-intel-fixes:
drm/i915: Rebind the buffer if its alignment constraints changes with tiling
drm/i915: Disable GPU semaphores by default
drm/i915: Do not overflow the MMADDR write FIFO
Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
The per-vm mutex doesn't prevent this completely, a flush coming from the
BAR VM could potentially happen at the same time as one for the channel
VM. Not to mention that if/when we get per-client/channel VM, this will
happen far more frequently.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
TTM assumes an error condition from man->func->get_node() means that
something went horribly wrong, and causes it to bail.
The driver is supposed to return 0, and leave mm_node == NULL to
signal that it couldn't allocate any memory.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some hardware claims to have both an LVDS panel and an eDP output.
Whilst this may be true in a rare case, more often it is just broken
hardware. If we see an eDP device we know that it must be connected and
so we can confirm its existence with a simple probe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34165
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Early gen3 and gen2 chipset do not have the relaxed per-surface tiling
constraints of the later chipsets, so we need to check that the GTT
alignment is correct for the new tiling. If it is not, we need to
rebind.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09
down to the use of GPU semaphores, and we already know that they appear
broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling
GPU semaphores is simply hiding another bug by the latency and
side-effects of the additional device interaction it introduces...)
However, use of semaphores is a massive performance improvement... Only
as long as the system remains stable. Enable at your peril.
Reported-by: Andi Kleen <andi-fd@firstfloor.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst the GT is powered down (rc6), writes to MMADDR are placed in a
FIFO by the System Agent. This is a limited resource, only 64 entries, of
which 20 are reserved for Display and PCH writes, and so we must take
care not to queue up too many writes. To avoid this, there is counter
which we can poll to ensure there are sufficient free entries in the
fifo.
"Issuing a write to a full FIFO is not supported; at worst it could
result in corruption or a system hang."
Reported-and-Tested-by: Matt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34056
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit c2e0eb1670.
As it turns out, userspace already depends upon being able to enable
tiling on existing bo which it promises to be large enough for its
purposes i.e. it will not access beyond the end of the last full-tile
row.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35016
Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We're coming to see a need to have a set of generic capability checks in
the core DRM, in addition to the driver-specific ioctls that already
exist.
This patch defines an ioctl to do as such, but does not yet define any
capabilities.
[airlied: drop the driver callback for now.]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The nv30/nv40 3d driver is about to start using DMA_FENCE from the 3D
object which, it turns out, doesn't like its DMA object to not be
aligned to a 4KiB boundary.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
hdmi 1.3 raises the max clock from 165 Mhz to 340 Mhz.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These should be handled by the clear_state setup, but set them
directly as well just to be sure.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cayman is different enough from evergreen to warrant it's own functions.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cayman asics have 3 ring buffers:
ring 0 supports both gfx and compute
rings 1 and 2 are compute only
At the moment we only support ring 0.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch sets up the gart in legacy mode. We
probably want to switch to full VM mode at some point.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The MC ucode is no longer loaded by the vbios
tables as on previous asics. It now must be loaded
by the driver.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cayman is DCE5 display plus a new 4-way shader block.
3D state programming is similar to evergreen.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's cleaned before saving and re-initialized after restoring.
So don't need to save/restore it. And also new chip has new address
for hardware status page register, don't write to old address.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On a Thinkpad x61s, I noticed some memory corruption when
plugging/unplugging the external VGA connection. The symptoms are that
4 bytes at the beginning of a page get overwritten by zeroes.
The address of the corruption varies when rebooting the machine, but
stays constant while it's running (so it's possible to repeatedly write
some data and then corrupt it again by plugging the cable).
Further investigation revealed that the corrupted address is
(dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
the hardware status page of the i965 graphics card, cut to 32 bits.
So it seems that for some memory access, the hardware uses only 32 bit
addressing. If the hardware status page is located >4GB, this
corrupts unrelated memory.
Signed-off-by: Jan Niehusmann <jan@gondor.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
This seems to be running stably on my test laptop, so hopefully the
reported hangs where just symptoms of other bugs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I stumbled over this magic bit in the gen3 INSTPM:
Bit11 Interrupt-Based AGPBUSY# Enable:
‘0’ = Pending GMCH interrupts will not cause AGPBUSY# assertion.
‘1’ = Pending GMCH interrupts will cause AGPBUSY# assertion and hence
can cause the CPU to exit C3. There is no suppression of cacheable
writes.
Note that in either case in C3 the interrupts are not lost. They will be
forwarded to the ICH when the GMCH is out of C3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Using PM latency request turns out to be very fragile and only works for
some systems, depending upon the ACPI implementation. However, I've
stumbled across a promising bit in INSTPM: "Interrupt-Based AGPBUSY#".
This reverts commit b0b544cd37.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Userspace has a legitimate requirement to use a delta that points to
outside of the target bo, and so we need to enable this. (As this is an
abi break, albeit a relaxation of the current restrictions, mark the change
with a new flag.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
drivers/gpu/drm/i915/i915_irq.c: In function ‘ironlake_irq_postinstall’:
drivers/gpu/drm/i915/i915_irq.c:1618: warning: unused variable ‘pipe’
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Somehow fixes a misrendering + hang at GDM startup on my NVA8...
My first guess would have been stale TLB entries laying around that a new
bo then accidentally inherits. That doesn't make a great deal of sense
however, as when we mapped the pages for the new bo the TLBs would've
gotten flushed anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
have to read values from the IB in order as we could cross
a page boundary at any time and won't be able to go backwards.
Signed-off-by: Dave Airlie <airlied@redhat.com>
There are a bunch of off by one errors in the sanity checks here.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The immediate benefit of doing this is that on NV50 and up, the GPU
virtual address of any buffer is now constant, regardless of what
memtype they're placed in.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This adds a table of known nvc0 memtypes, and modifies the validity check
to allow any non-compressed type. Support for Z compression will come at
a later point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Upcoming patches are going to enable full support for buffers that keep
a constant GPU virtual address whenever they're validated for use by
the GPU.
In order for this to work properly while keeping support for large pages,
we need to know if it's ever going to be possible for a buffer to end
up in GART, and if so, disable large pages for the buffer's VMA.
This is a new restriction that's not present in earlier kernel's, but
should not break userspace as the current code never attempts to validate
buffers into a memtype other than it was created with.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
'mappable' isn't really used at all, nor is it necessary anymore as the
bo code is capable of moving buffers to mappable vram as required.
'no_vm' isn't necessary anymore either, any places that don't want to be
mapped into a GPU address space should allocate the VRAM directly instead.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The code was supposed to print registers around 0x405018 (which is read
earlier), not 0x405818.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The hw doesn't really appear to be designed to be used the way we have to
use it due to DRI2's design. This leads us to having to keep the flipped
fb support active at all times.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Also imports a couple of helper functions that'll be used to implement
page flipping in the following commits..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This should prevent a number of races from occuring, the most obvious of
which will be exposed when we start making use of the "display sync" evo
channel for page flipping. The DS channel will reject any command stream
that doesn't completely agree with the current "master" state.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to be able to have the bh run while possibly spinning waiting for
the EVO notifier to signal. This apparently happens in some circumstances
with preempt disabled, so our workqueue was never being run.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The nv50 display isr bh needs to be converted to a tasklet, which means
we can't sleep anymore. The places we execute vbios init tables are
rare, and not in any way performance critical, so this isn't a huge
problem.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
With cmwq, there's no reason for nouveau to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead. Each work item is sync
flushed when the containing structure is unregistered/destroyed.
Note that this change also makes sure that nv50_gpio_handler is not
freed while the contained work item is still running.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This gives a small, but noticeable performance gain at lower performance
levels, and unchanged at the higher ones.
With this commit, we're now using the same timeslice size as the NVIDIA
binary driver currently does, and dropping an unknown bit that NVIDIA
no longer appear to set.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We may well be making more use of semaphores in the future, having the
entire VM available makes requiring DMA objects for each and every
semaphore block unnecessary.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
And also, don't disable PFIFO IRQs completely whenever we recieve one,
just when we don't know about it already.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These are the same semaphores nvc0 will use, and they potentially allow
us to do much cooler things than our current inter-channel sync impl.
Lets switch to them where possible now for some testing.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In preparation for the addition of a new nv40 backend, we'll need to be
able to distinguish between a paged dma object and the on-chip GART.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
After disabling, we're meant to teardown the bo used for the contexts,
not recurse into ourselves again and preventing module unload.
Reported-and-tested-by: Ben Widawsky <bwidawsk@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
drm/i915: fix corruptions on i8xx due to relaxed fencing
drm/i915: skip FDI & PCH enabling for DP_A
agp/intel: Experiment with a 855GM GWB bit
drm/i915: don't enable FDI & transcoder interrupts after all
drm/i915: Ignore a hung GPU when flushing the framebuffer prior to a switch
It looks like gen2 has a peculiar interleaved 2-row inter-tile
layout. Probably inherited from i81x which had 2kb tiles (which
naturally fit an even-number-of-tile-rows scheme to fit onto 4kb
pages). There is no other mention of this in any docs (also not
in the Intel internal documention according to Chris Wilson).
Problem manifests itself in corruptions in the second half of the
last tile row (if the bo has an odd number of tiles). Which can
only happen with relaxed tiling (introduced in a00b10c360).
So reject set_tiling calls that don't satisfy this constrain to
prevent broken userspace from causing havoc. While at it, also
check the size for newer chipsets.
LKML: https://lkml.org/lkml/2011/2/19/5
Reported-by: Indan Zupancic <indan@nul.nu>
Tested-by: Indan Zupancic <indan@nul.nu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 5a893fc28f.
This causes a use after free in the ttm free alloc pages path,
when it tries to get the be after the be has been destroyed.
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'stable/ttm.pci-api.v5' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
ttm: Include the 'struct dev' when using the DMA API.
nouveau/ttm/PCIe: Use dma_addr if TTM has set it.
radeon/ttm/PCIe: Use dma_addr if TTM has set it.
ttm: Expand (*populate) to support an array of DMA addresses.
ttm: Utilize the DMA API for pages that have TTM_PAGE_FLAG_DMA32 set.
ttm: Introduce a placeholder for DMA (bus) addresses.
Using an order 19 drm_ht for the mmap offsets is a little obscene. That
means that will a fully populated GTT with every single object mmaped at
least once in its lifetime, there will be exactly one object in each
bucket.
Typically systems only have at most a few thousand objects, though you
may see a KDE desktop hit 50000. And most of those should never be
mapped... On my systems, just using an order 10 ht would still have an
average occupancy less than 1, so apply a small safety factor and
use an order 12 ht, like the other mmap offset ht.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... and fixup some methods to accept the constant argument.
Now that constant module arrays are loaded into read-only memory, using
const appropriately has some benefits beyond warning the programmer
about likely mistakes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
the texture checking code didn't work for block formats like s3tc,
this overhauls it to work for all types.
v2: add texture array support.
v3: add subsampled formats
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau doesn't have enough information at ttm_backend_func.bind() time
to implement things like tiled GART, or to keep a buffer at a constant
address in the GPU virtual address space no matter where in physical
memory it's placed.
To resolve this, nouveau will handle binding of all buffers to the GPU
itself from the move_notify() hook. This commit ensures it's called
for all buffer moves.
Talked to Dave about the impact on radeon, which uses move_notify, it
doesn't look like anything should break there.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thomas@shipmail.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If there is an alpha channel, need to mask in 1's in the alpha channel
to prevent the fb from being completely transparent.
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now all the asic specific stuff ist mostly hid in radeon_asic.*
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... and switch it to container_of upcasting.
v2: converted new pageflip code-paths.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Unconditionally initialize the drm gem object - it's not
worth the trouble not to for the few kernel objects.
This patch only changes the place of the drm gem object,
access is still done via pointers.
v2: Uncoditionally align the size in radeon_bo_create. At
least the r600/evergreen blit code didn't to this, angering
the paranoid gem code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With the switch to implicit free space accounting one pointer
got unused when scanning. Use it to create a single-linked list
to ensure correct unwinding of the scan state.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The old api has a two-step process: First search for a suitable
free hole, then allocate from that specific hole. No user used
this to do anything clever. So drop it for the embeddable variant
of the drm_mm api (the old one retains this ability, for the time
being).
With struct drm_mm_node embedded, we cannot track allocations
anymore by checking for a NULL pointer. So keep track of this
and add a small helper drm_mm_node_allocated.
Also add a function to move allocations between different struct
drm_mm_node.
v2: Implement suggestions by Chris Wilson.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The idea is to track free holes implicitly by marking the allocation
immediatly preceeding a hole.
To avoid an ugly corner case add a dummy head_node to struct drm_mm
to track the hole that spans to complete allocation area when the
memory manager is empty.
To guarantee that there's always a preceeding/following node (that might
be marked as hole_follows == 1), move the mm->node_list list_head to the
head_node.
The main allocator and fair-lru scan code actually becomes simpler.
Only the debug code slightly suffers because free areas are no longer
explicit.
Also add drm_mm_for_each_node (which will be much more useful when
struct drm_mm_node is embeddable).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau was checking drm_mm internals on teardown to see whether the
memory manager was initialized. Hide these internals in a small
inline helper function.
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some userspaces can emit a whole packet without disabling AA resolve
by the looks of it, so we have to deal with them.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Jorg Otte <jrg.otte@googlemail.com>
r100_gpu_init() was dropped in 90aca4d ("drm/radeon/kms: simplify &
improve GPU reset V2") but here it was only commented out.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Testing showed the current code can already handle doublescan
video modes just fine. A trivial tweak makes it work for interlaced
scanout as well.
Tested and shown to be precise on Radeon rv530, r600 and
Intel 945-GME.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Documentation/atomic_ops.txt tells us that there are memory
barriers optimized for atomic_inc and other atomic_t ops.
Use these instead of smp_wmb(), and also to make the required
memory barriers around vblank counter increments more explicit.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use of abs() wrongly wrapped diff_ns to 32 bit, which gives a 1/4000
probability of a missed vblank increment at each vblank irq reenable
if the kms driver doesn't support high precision vblank timestamping.
Not a big deal in practice, but let's make it nice.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this aligns the height of the fb allocation so it doesn't trip
over the size checks later when we use this from userspace to
copy the buffer at X start.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit a6f9761743.
Remove this commit as it is no longer necessary. The relevant bugs
were fixed properly in:
drm/radeon/kms: hopefully fix pll issues for real (v3)
5b40ddf888
drm/radeon/kms: add missing frac fb div flag for dce4+
9f4283f49f
This commit also broke certain ~5 Mhz modes on old arcade monitors,
so reverting this commit fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29502
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This makes the accounting when using 'debug_dma_dump_mappings()'
and CONFIG_DMA_API_DEBUG=y be assigned to the correct device
instead of 'fallback'.
No functional change - just cosmetic.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Merge in the conflicting eDP fix.
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/intel_display.c
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to prevent "crushed blacks" on TVs, the range of the RGB output
may be limited to 16-235. This used to be available through Xorg under
the "Broadcast RGB" option, so reintroduce support for KMS.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code paths for modesetting are growing in complexity as we may need
to move the buffers around in order to fit the scanout in the aperture.
Therefore we face a choice as to whether to thread the interruptible status
through the entire pinning and unbinding code paths or to add a flag to
the device when we may not be interrupted by a signal. This does the
latter and so fixes a few instances of modesetting failures under stress.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we just need a temporary array whilst performing the relocations for
the execbuffer, first attempt to allocate using kmalloc even if it is
not of order page-0. This avoids the overhead of remapping the
discontiguous array and so gives a moderate boost to execution
throughput.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Seems like we are forever to be cursed with buggy firmware, so allow the
user to explicitly set the panel connection status.
Of secondary utility for cases where I run laptops with the lid closed,
but still want to configure the LVDS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Dave Airlie spotted that we had a potential bug should we ever rearrange
the drm_i915_gem_object so not the base drm_gem_object was not its first
member. He noticed that we often convert the return of
drm_gem_object_lookup() immediately into drm_i915_gem_object and then
check the result for nullity. This is only valid when the base object is
the first member and so the superobject has the same address. Play safe
instead and use the compiler to convert back to the original return
address for sanity testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In a few places I replaced reads of per-pipe registers with the actual
register offsets themselves (converting I915_READ(reg) to _PIPE(reg)).
Alexey caught this on his 9xx machine because the cursor control write
was affected. A quick audit showed a few more places where I'd borked
a read, so here's a patch to fix things up.
Reported-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: compilation fix]
Tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 633f2ea266 and the
attempted fix dcbe6f2b3d.
There is a single clock source used for both SSC (some LVDS and DP) and
non-SSC (VGA, DVI) outputs. So we need to be careful to only enable SSC
as necessary. However, fiddling with DREFCLK was causing DP links to be
dropped and we do not have a fix ready, so revert.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
problems. So avoid FDI training and PCH PLL enabling in that case.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can enable some safely, but FDI and transcoder interrupts can occur
and block other interrupts from being detected (like port hotplug
events). So keep them disabled by default (they can be re-enabled for
debugging display bringup, but should generally be off).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the gpu is hung, then whatever was inside the render cache is lost
and there is little point waiting for it. Or complaining if we see an
EIO or EAGAIN instead. So, if the GPU is indeed in its death throes when
we need to rewrite the registers for a new framebuffer, just ignore the
error and proceed with the update.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The current code does not follow Intel documentation: It misses some things
and does other, undocumented things. This causes wrong backlight values in
certain conditions. Instead of adding tricky code handling badly documented
and rare corner cases, don't handle combination mode specially at all. This
way PCI_LBPC is never touched and weird things shouldn't happen.
If combination mode is enabled, then the only downside is that changing the
brightness has a greater granularity (the LBPC value), but LBPC is at most
254 and the maximum is in the thousands, so this is no real functional loss.
A potential problem with not handling combined mode is that a brightness of
max * PCI_LBPC is not bright enough. However, this is very unlikely because
from the documentation LBPC seems to act as a scaling factor and doesn't look
like it's supposed to be changed after boot. The value at boot should always
result in a bright enough screen.
IMPORTANT: However, although usually the above is true, it may not be when
people ran an older (2.6.37) kernel which messed up the LBPC register, and
they are unlucky enough to have a BIOS that saves and restores the LBPC value.
Then a good kernel may seem to not work: Max brightness isn't bright enough.
If this happens people should boot back into the old kernel, set brightness
to the maximum, and then reboot. After that everything should be fine.
For more information see the below links. This fixes bugs:
http://bugzilla.kernel.org/show_bug.cgi?id=23472http://bugzilla.kernel.org/show_bug.cgi?id=25072
Signed-off-by: Indan Zupancic <indan@nul.nu>
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the TTM layer has used the DMA API to setup pages that are
TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the
DMA API for pages that have TTM_PAGE_FLAG_DMA32 set"), lets
use it when programming the GART in the PCIe type cards.
This patch skips doing the pci_map_page (and pci_unmap_page) if
there is a DMA addresses passed in for that page. If the dma_address
is zero (or DMA_ERROR_CODE), then we continue on with our old
behaviour.
[v2: Added a review-by tag]
Reviewed-by: Thomas Hellstrom <thomas@shipmail.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
If the TTM layer has used the DMA API to setup pages that are
TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
array for pages that are to in DMA32 pool."), lets use it
when programming the GART in the PCIe type cards.
This patch skips doing the pci_map_page (and pci_unmap_page) if
there is a DMA addresses passed in for that page. If the dma_address
is zero (or DMA_ERROR_CODE), then we continue on with our old
behaviour.
[v2: Fixed an indentation problem, added reviewed-by tag]
[v3: Added Acked-by Jerome]
Acked-by: Jerome Glisse <j.glisse@gmail.com>
Reviewed-by: Thomas Hellstrom <thomas@shipmail.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next:
drm/nouveau: fix suspend/resume on GPUs that don't have PM support
drm/nouveau: flips/flipd need to always set 'evict' for move_accel_cleanup()
drm/nv40: fix tiling-related setup for a number of chipsets
drm/nouveau: fix non-EDIDful native mode selection
drm/nouveau: Fix detection of DDC-based LVDS on DCB15 boards.
drm/nv04-nv40: Fix NULL dereference when we fail to find an LVDS native mode.
drm/nv10: Fix crash when allocating a BO larger than half the available VRAM.
The fixed ref/post dividers are set by the AdjustPll table
rather than the ss info table on dce4+. Make sure we enable
the fractional feedback dividers when using a fixed post
or ref divider on them as well.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29272
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
We free the temporary binding before leaving this function, so we also have
to wait for the move to actually complete.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Due to the default case handling the older chipsets, a bunch of the newer
ones ended up having the wrong tiling regs used. This commit switches the
default case to handle the newest chipsets.
This also makes nv4e touch the "extra" tiling regs. "nv" doesn't touch
them for C51 but traces of the NVIDIA binary driver show it being done
there.
I couldn't find NV41/NV45 traces to confirm the behaviour there, but an
educated guess was taken at each of them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The DRM core fills this value, but at too late a stage for this to work,
possibly resulting in an undesirable mode being selected.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reported-by: Alex Buell <alex.buell@munted.org.uk>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reported-by: Alex Buell <alex.buell@munted.org.uk>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Grab the latest stabilisation bits from -fixes and some suspend and
resume fixes from linus.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_irq.c
Share the lid detection code for the all panels for consistent behaviour
and a single place to add the eventual quirks for crap hardware.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can enable some safely, but FDI and transcoder interrupts can occur
and block other interrupts from being detected (like port hotplug
events). So keep them disabled by default (they can be re-enabled for
debugging display bringup, but should generally be off).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the gpu is hung, then whatever was inside the render cache is lost
and there is little point waiting for it. Or complaining if we see an
EIO or EAGAIN instead. So, if the GPU is indeed in its death throes when
we need to rewrite the registers for a new framebuffer, just ignore the
error and proceed with the update.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The problematic boards have a recommended reference divider
to be used when spread spectrum is enabled on the laptop panel.
Enable the use of the recommended reference divider along with
the new pll algo.
v2: testing options
v3: When using the fixed reference divider with LVDS, prefer
min m to max p and use fractional feedback dividers.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=28852https://bugzilla.kernel.org/show_bug.cgi?id=24462https://bugzilla.kernel.org/show_bug.cgi?id=26552
MacbookPro issues reported by Justin Mattock <justinmattock@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915: Fix resume regression from 5d1d0cc
drm/i915/tv: Use polling rather than interrupt-based hotplug
drm/i915: Trigger modesetting if force-audio changes
drm/i915/sdvo: If we have an EDID confirm it matches the mode of the connection
drm/i915: Disable RC6 on Ironlake
drm/i915/lvds: Restore dithering on native modes for gen2/3
drm/i915: Invalidate TLB caches on SNB BLT/BSD rings
Makes debugging CS rejections much easier.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is an important security fix because we allowed arbitrary values
to be passed to AARESOLVE_OFFSET. This also puts the right buffer address
in the register.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not only is linear aligned supposedly more performant,
linear general is only supported by the CB in single
slice mode. The texture hardware doesn't support
linear general, but I think the hw automatically
upgrades it to linear aligned.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not only is linear aligned supposedly more performant,
linear general is only supported by the CB in single
slice mode. The texture hardware doesn't support
linear general, but I think the hw automatically
upgrades it to linear aligned.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
My evergreen has been in a remote PC for week and reset has never once
saved me from certain doom, I finally relocated to the box with a
serial cable and noticed an oops when the GPU resets, and the TTM
delayed delete thread tries to remove something from the GTT.
This stops the delayed delete thread from executing across the GPU
reset handler, and woot I can GPU reset now.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Based on 6xx/7xx endian fixes from Cédric Cano.
v2: fix typo in shader
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
agd5f: minor cleanups
Signed-off-by: Cédric Cano <ccano@interfaceconcept.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
agd5f: minor cleanups
Signed-off-by: Cédric Cano <ccano@interfaceconcept.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The colorbuffer, zbuffer, and texture states are checked only once when
they get changed. This improves performance in the apps which emit
lots of draw packets and few state changes.
This drops performance in glxgears by a 1% or so, but glxgears is not
a benchmark we care about.
The time spent in the kernel when running Torcs dropped from 33% to 23%
and the frame rate is higher, which is a good thing.
r600 might need something like this as well.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the continuing effort to avoid kernel addresses leaking to unprivileged
users, this patch switches to %pK for /proc/dri/*/vma.
Signed-off-by: Kees Cook <kees.cook@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
PPC Mac cards do not provide connector tables in
their vbios. Their connector/encoder configurations
must be hardcoded in the driver.
verified by nyef on #radeon
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
drivers/gpu/drm/radeon/mkregtable.c:parser_auth() almost always remembers
to fclose(file) before returning, but it misses two spots.
This is not really important since the process will exit shortly after and
thus close the file for us, but being explicit prevents static analysis
tools from complaining about leaked memory and missing fclose() calls and
it also seems to be the prefered style of the existing code to explicitly
close the file.
So, here's a patch to add the two missing fclose() calls.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- set scaler table clears the interleave bit, need to
reset it in encoder quirks, this was already done for
pre-dce4.
- remove the interleave settings from set_base() functions
this is now handled in the encoder quirks functions, and
isn't technically part of the display base setup.
- rename evergreen_do_set_base() to dce4_do_set_base() since
it's used on both evergreen and NI asics.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=28182
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The old code dereferenced a value, the new code just needs to pass
the ptr.
fixes an oops looking at files in debugfs.
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Disable any PCH ports associated with a pipe when disabling it. This
should prevent transcoder disable failures due to ports still being on.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: introduce *_PIPE_ENABLED() macro]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... so we handle that for i915_gem_fault() in the same manner as
ERESTARTSYS, or we send a SIGBUS to the faulting application.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The irony of the patch to fix the resume regression on PineView causing
a further regression on Ironlake is not lost on me.
Reported-by: Jeff Chua <jeff.chua.linux@gmail.com>
Reported-by: Björn Schließmann <chronoss@gmx.de>
Tested-by: Björn Schließmann <chronoss@gmx.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28802
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The documentation recommends that we should use a polling method for TV
detection as this is more power efficient than the interrupt based
mechanism (as the encoder can be completely switched off). A secondary
effect is that leaving the hotplug enabled seems to be causing pipe
underruns as reported by Hugh Dickins on his Crestline.
Tested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[This is a candidate for stable, but needs minor porting to 2.6.37]
If the user changes the force-audio property and it no longer reflects
the current configuration, then we need to trigger a mode set in order
to update the registers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have an EDID for a digital panel, but we are probing a non-TMDS
connector then we know that this is a false detection, and vice versa.
This should reduce the number of bogus outputs on multi-function
adapters that report the same output on multiple connectors.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34101
Reported-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
The automatic powersaving feature is once again causing havoc, with 100%
reliable hangs on boot and resume on affected machines.
Reported-by: Francesco Allertsen <fallertsen@gmail.com>
Reported-by: Gui Rui <chaos.proton@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We had some conversions over to the _PIPE macros, but didn't get
everything. So hide the per-pipe regs with an _ (still used in a few
places for legacy) and add a few _PIPE based macros, then make sure
everyone uses them.
[update: remove usage of non-existent no-op macro]
[update 2: keep modesetting suspend/resume code, update to new reg names]
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: stylistic cleanups for checkpatch and taste]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A lot of minor tweaks to fix the tracepoints, improve the outputting for
ftrace, and to generally make the tracepoints useful again. It is a start
and enough to begin identifying performance issues and gaps in our
coverage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By returning EAGAIN upon a wedged GPU before attempting to wait, we
would hit an infinite loop of repeating operation without ever
progressing. Instead this needs to be EIO so that userspace knows that
the GPU is truly wedged and not in the process of error recovery.
Similarly, we need to handle the error recovery during i915_gem_fault.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The PCH can drive several reference clocks simultaneously, and needs to
with multiple display configurations. So we can't just clobber the
existing state everytime we set a mode, we need to take into account
what the other CRTCs are doing at the time.
Doing so fixes an issue where you'd lose the LVDS display at boot if you
had an LVDS+DP config.
[updated: init bools and check CRTC status correctly]
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When a transcoder is disabled, any ports pointing at it should also be
disabled. If they're not, we may fail to disable the transcoder,
leading to blank displays.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These bits have a different meaning on ILK+, where planes are hardwired
to pipes. Fixing this avoid some spurious assertion failures.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This adds an initial framework to plug USB graphics devices
into the drm/kms subsystem.
I've started writing a displaylink driver using this interface.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This abstracts the pci/platform interface out a step further,
we can go further but this is far enough for now to allow USB
to be plugged in.
The drivers now just call the init code directly for their
device type.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.
It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.
Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.
Signed-off-by: Dave Airlie <airlied@redhat.com>
SMP i810 systems were practically nonexistent and the configuration
was not officially supported by Intel at the time when Pentium-III
was common.
With this change, it is still possible to build a distribution kernel
that has support for SMP and includes the i810 driver without the BKL.
As a precaution, check for the theoretical SMP case at run time and
refuse to load the driver.
We also need to disable CONFIG_PREEMPT builds for this driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This driver is one of the last users of the big kernel
lock, which is going away. All the hardware supported
by this driver also works with the newer i915 driver,
and recent X.org releases only work with that driver
anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (27 commits)
gpu/stub: fix acpi_video build error, fix stub kconfig dependencies
drm/radeon/kms: dynamically allocate power state space
drm/radeon/kms: fix s/r issues with bios scratch regs
agp: ensure GART has an address before enabling it
Revert "agp: AMD AGP is used on UP1100 & UP1500 alpha boxen"
amd-k7-agp: remove non-x86 code
drm/radeon/kms/evergreen: always set certain VGT regs at CP init
drm/radeon/kms: add updated ib_execute function for evergreen
drm/radeon: remove 0x4243 pci id
drm/radeon/kms: Enable new pll calculation for avivo+ asics
drm/radeon/kms: add new pll algo for avivo asics
drm/radeon/kms: add pll debugging output
drm/radeon/kms: switch back to min->max pll post divider iteration
drm/radeon/kms: rv6xx+ thermal sensor fixes
drm/nv50: fix display on 0x50
drm/nouveau: correctly pair hwmon_init and hwmon_fini
drm/i915: Only bind to function 0 of the PCI device
drm/i915: Suppress spurious vblank interrupts
drm: Avoid leak of adjusted mode along quick set_mode paths
drm: Simplify and defend later checks when disabling a crtc
...
In drm_crtc_helper_set_config, instead of always forcing all outputs
to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a
mode set, as any mode set will turn all outputs on.
This fixes https://lkml.org/lkml/2011/1/24/457
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: stable@kernel.org (2.6.37)
Reported-and-tested-by: Carlos R. Mafra <crmafra2@gmail.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The comments under "config STUB_POULSBO" are close to correct,
but they are not being followed. This patch updates them to reflect
the requirements for THERMAL.
This build error is caused by STUB_POULSBO selecting ACPI_VIDEO
when ACPI_VIDEO's config requirements are not met.
ERROR: "thermal_cooling_device_register" [drivers/acpi/video.ko] undefined!
ERROR: "thermal_cooling_device_unregister" [drivers/acpi/video.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Tested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We previously used a static array, but some new systems
had more states then we had array space, so dynamically
allocate space based on the number of states in the vbios.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33851
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The accelerate mode bit gets checked by certain atom
command tables to set up some register state. It needs
to be clear when setting modes and set when not.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=26942
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
These should be handled by the clear_state setup, but set them
directly as well just to be sure.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Adds new packet to disable DX9 constant emulation.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Based on the vbios code. This should hopefully
fix the pll problems on a number of avivo asics
once it's enabled.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some fixes to the thermal sensor code:
- handle negative numbers
- properly handle temp calculation on different asics
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915: Only bind to function 0 of the PCI device
drm/i915: Suppress spurious vblank interrupts
drm: Avoid leak of adjusted mode along quick set_mode paths
drm: Simplify and defend later checks when disabling a crtc
drm: Don't switch fb when disabling an output
drm/i915: Reset crtc after resume
drm/i915/crt: Force the initial probe after reset
drm/i915: Reset state after a GPU reset or resume
drm: Add an interface to reset the device
drm/i915/sdvo: If at first we don't succeed in reading the response, wait
Accidently busted a while back. We'll be creating objects that aren't
necessary here, but, they're never used so no harm..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
I broke this with my commit
07cfe0e7a8
This fixes fdo #33434
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The comments under "config STUB_POULSBO" are close to correct,
but they are not being followed. This patch updates them to reflect
the requirements for THERMAL.
This build error is caused by STUB_POULSBO selecting ACPI_VIDEO
when ACPI_VIDEO's config requirements are not met.
ERROR: "thermal_cooling_device_register" [drivers/acpi/video.ko] undefined!
ERROR: "thermal_cooling_device_unregister" [drivers/acpi/video.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Early chipsets (gen2/3) used function 1 as a placeholder for multi-head.
We used to ignore these since they were not assigned to
PCI_CLASS_DISPLAY_VGA. However with 934f992c7 we attempt to bind to all
Intel PCI_CLASS_DISPLAY devices (and functions) to work in multi-gpu
systems. This fails hard on gen2/3.
Reported-by: Ferenc Wágner <wferi@niif.hu>
Tested-by: Ferenc Wágner <wferi@niif.hu>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
With the recent SDVO fix, this is working on all the machines I have to
hand - except for an 845G.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Judging by comments in the BIOS, if the SDVO LVDS option h40 is enabled,
then we are supposed to query the real panel type via Int15. We don't do
this and so for the Sony Vaio VGC-JS210J which has otherwise default
values, we choose the wrong mode.
This patch adds a driver option, i915.vbt_sdvo_panel_type, which can be
used to override the value in the VBT.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33691
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hugh Dickins found that characters in xterm were going missing and oft
delayed. Being the curious type, he managed to associate this with the
new high-precision vblank patches; disabling these he found, restored
the orderliness of his characters.
The oddness begins when one realised that Hugh was not using vblanks at
all on his system (fvwm and some xterms). Instead, all he had to go on
were warning of a pipe underrun, curiously enough at around 60Hz. He
poked and found that in addition to the underrun warning, the hardware
was flagging the start of a new frame, a vblank, which in turn was
kicking off the pending vblank processing code.
There is little we can do for the underruns on Hugh's machine, a
Crestline [965GM], which must have its FIFO watermarks set to 8.
However, we do not need to process the vblank if we know that they are
disabled...
Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By setting the FB of a CRTC to NULL, we are turning off the CRTC (and so
disable the unused encoders and connectors). As such we can simplify the
later tests by making sure the set->mode is NULL. Setting the
num_connectors to zero means that we do not need to loop over the unused
connectors.
All current usage appears correct, this only builds additional defense
into the routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=27722
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In drm_crtc_helper_set_config, we call drm_crtc_helper_set_mode which
may return early and do no operation if the crtc is to be disabled. In
this case we merrily swap to the new fb, discarding the old_fb believing
that it has been cleaned up. However, due to the early return, the
old_fb was not presented to the backend for correct reaping, and nor was
the new one - which is about to be reaped via the
drm_helper_disable_unused_functions(), leading to incorrect refcounting
of the pinned objects.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27722
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29230
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This error is reported by cppcheck:
drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over || always evaluates to true. Did you intend to use && instead?
It looks like cppcheck is correct, so fix this. No test was run.
Cc: David Airlie <airlied@linux.ie>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/nv50: fix regression on IGPs
drm/radeon/kms: re-emit full context state for evergreen blits
drm/radeon/kms: release CMASK access in preclose_kms
drm/radeon/kms: fix r6xx+ scanout on BE systems
drm/radeon/kms: clean up some magic numbers
drm/radeon/kms: only enable HDMI mode if radeon audio is enabled
radeon/kms: fix dp displayport mode validation
drm/nvc0/grctx: correct an off-by-one
drm/nv50: Fix race with PFIFO during PGRAPH context destruction.
drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200.
drm/nvc0: implement irq handler for whatever's at 0x14xxxx
drm/nvc0: fix incorrect TPC register setup
drm/nouveau: probe for adt7473 before f75375
drm/nouveau: remove dead function definition
clear state doesn't seem to work properly in some cases
Fixes hangs in heavy 3D on some evergreen cards reported on
IRC.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=33381
possibly others.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
We pass in the array of ttm pages to be populated in the GART/MM
of the card (or AGP). Patch titled: "ttm: Utilize the DMA API for
pages that have TTM_PAGE_FLAG_DMA32 set." uses the DMA API to make
those pages have a proper DMA addresses (in the situation where
page_to_phys or virt_to_phys do not give use the DMA (bus) address).
Since we are using the DMA API on those pages, we should pass in the
DMA address to this function so it can save it in its proper fields
(later patches use it).
[v2: Added reviewed-by tag]
Reviewed-by: Thomas Hellstrom <thellstrom@shipmail.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
For pages that have the TTM_PAGE_FLAG_DMA32 flag set we
use the DMA API. We save the bus address in our array which we
use to program the GART (see "radeon/ttm/PCIe: Use dma_addr if TTM
has set it." and "nouveau/ttm/PCIe: Use dma_addr if TTM has set it.").
The reason behind using the DMA API is that under Xen we would
end up programming the GART with the bounce buffer (SWIOTLB)
DMA address instead of the physical DMA address of the TTM page.
The reason being that alloc_page with GFP_DMA32 does not allocate
pages under the the 4GB mark when running under Xen hypervisor.
Under baremetal this means we do the DMA API call earlier instead
of when we program the GART.
For details please refer to:
https://lkml.org/lkml/2011/1/7/251
[v2: Fixed indentation, revised desc, added Reviewed-by]
Reviewed-by: Thomas Hellstrom <thomas@shipmail.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
This is right now limited to only non-pool constructs.
[v2: Fixed indentation issues, add review-by tag]
Reviewed-by: Thomas Hellstrom <thomas@shipmail.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Instead of reporting EIO upfront in the entrance of an ioctl that may or
may not attempt to use the GPU, defer the actual detection of an invalid
ioctl to when we issue a GPU instruction. This allows us to continue to
use bo in video memory (via pread/pwrite and mmap) after the GPU has hung.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
R6xx+ have per-block swappers. BE content in the
framebuffer will now be swapped properly during scanout.
Untested, however, the same code is reported working in
the UMS ddx.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Force DVI mode if the user specifies radeon.audio=0. The driver
doesn't handle HDMI mode properly in some cases.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=27731
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Check if there is a big enough dp clock & enough dp lane to
drive the video mode provided.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-By: Alex Deucher <alexdeucher@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6:
drm/nvc0/grctx: correct an off-by-one
drm/nv50: Fix race with PFIFO during PGRAPH context destruction.
drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200.
drm/nvc0: implement irq handler for whatever's at 0x14xxxx
drm/nvc0: fix incorrect TPC register setup
drm/nouveau: probe for adt7473 before f75375
drm/nouveau: remove dead function definition
The -rt patches change the console_semaphore to console_mutex. As a
result, a quite large chunk of the patches changes all
acquire/release_console_sem() to acquire/release_console_mutex()
This commit makes things use more neutral function names which dont make
implications about the underlying lock.
The only real change is the return value of console_trylock which is
inverted from try_acquire_console_sem()
This patch also paves the way to switching console_sem from a semaphore to
a mutex.
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert]
Signed-off-by: Torben Hohn <torbenh@gmx.de>
Cc: Thomas Gleixner <tglx@tglx.de>
Cc: Greg KH <gregkh@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Based on a patch by Takashi Iwai.
Reported-by: Matthias Hopf <mat@mshopf.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27272
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Upon resume, like after a cold boot, we need to forcibly probe the
analog connector and cannot rely on the hotplug status.
Based on a patch by Takashi Iwai.
Reported-by: Stefan Dirsch <sndirsch@suse.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=26952
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Call drm_mode_config_reset() after an invalidation event to restore any
cached state to unknown.
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Iterate over the attached CRTCs, encoders and connectors and call the
supplied reset vfunc in order to reset any cached state back to unknown.
Useful after an invalidation event such as a GPU reset or resuming.
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were not pausing after detecting the response was pending and so did
not allow the hardware sufficient time to complete before aborting. This
lead to transient failures whilst probing SDVO devices.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30235
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than power cycling the panel when there are no bits to display,
use the VDD AUX bit to power the panel up just enough for DP AUX
transactions to work. This prevents a bit of unnecessary ugliness as
mode sets occur on the panel.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Now that we're doing the right thing elsewhere, these are no longer
necessary.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31114
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Move the plane->mode config to the point of use rather than repeatedly
querying the same information.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes the DVI-D output on that board (fdo bug 32645).
Reported-by: Bryan Quigley <BryanQuigley@Ubuntu.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is just barely enough to stop a never-ending IRQ storm that can
be triggered by our 3D driver. We have no idea what this engine is..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Was hitting TPC+1's regs by accident, oops.
Reported-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's a reported case where probing for f75375 causes the system
to hang completely, in this case there's an adt7473 at the same
i2c address.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel: (30 commits)
drm/i915: Prevent uninitialised reads during error state capture
drm/i915: Use consistent mappings for OpRegion between ACPI and i915
drm/i915: Handle the no-interrupts case for UMS by polling
drm/i915: Disable high-precision vblank timestamping for UMS
drm/i915: Increase the amount of defense before computing vblank timestamps
drm/i915,agp/intel: Do not clear stolen entries
Remove MAYBE_BUILD_BUG_ON
BUILD_BUG_ON: make it handle more cases
module: fix missing semicolons in MODULE macro usage
param: add null statement to compiled-in module params
module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n
module: show version information for built-in modules in sysfs
selinux: return -ENOMEM when memory allocation fails
tpm: fix panic caused by "tpm: Autodetect itpm devices"
TPM: Long default timeout fix
trusted keys: Fix a memory leak in trusted_update().
keys: add trusted and encrypted maintainers
encrypted-keys: rename encrypted_defined files to encrypted
trusted-keys: rename trusted_defined files to trusted
drm/i915: Recognise non-VGA display devices
...
error_bo and pinned_bo could be used uninitialised if there were no
active buffers.
Caught by kmemcheck.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The opregion is a shared memory region between ACPI and the graphics
driver. As the ACPI mapping has been changed to cachable in commit
6d5bbf00d2, mapping the intel opregion
non-cachable now fails. As no bus-master hardware is involved in the
opregion, cachable map should do no harm.
Tested on a Fujitsu Lifebook P8010.
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
[ickle: convert to acpi_os_ioremap for consistency]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Merge with Linus to resolve conflicting fixes for the reusing the stale
HEAD value during intel_ring_wait().
Conflicts:
drivers/gpu/drm/i915/intel_ringbuffer.c
If the driver calls into the kernel to wait for a breadcrumb to pass,
but hasn't enabled interrupts, fallback to polling the breadcrumb value.
Reported-by: Chris Clayton <chris2553@googlemail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only have sufficient information for accurate (sub-frame) timestamping
when the modesetting is under our control.
Reported-by: Chris Clayton <chris2553@googlemail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Chris Clayton <chris2553@googlemail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can only utilize the stolen portion of the GTT if we are in sole
charge of the hardware. This is only true if using GEM and KMS,
otherwise VESA continues to access stolen memory.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Jiri Olsa <jolsa@redhat.com>
Tested-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't reset if the engine isn't busy. This matches the behavior of
previous asics. Reseting a non-hung block can lead to a hang.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33272
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Seems some other boards do this as well.
Reported-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
I'm amazed but not really surprised this worked on x86...
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Starting with SandyBridge (though possible with earlier hacked BIOSes),
the BIOS may initialise the IGFX as secondary to a discrete GPU. Prior,
it would simply disable the integrated GPU. So we adjust our PCI class
mask to match any DISPLAY_CLASS device.
In such a configuration, the IGFX is not a primary VGA controller and
so should not take part in VGA arbitration, and the error return from
vga_client_register() is expected.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
There are I915_NUM_RINGS-1 inter-ring synchronisation counters, but we
were clearing I915_NUM_RINGS of them. Oops.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Tested-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* akpm:
kernel/smp.c: consolidate writes in smp_call_function_interrupt()
kernel/smp.c: fix smp_call_function_many() SMP race
memcg: correctly order reading PCG_USED and pc->mem_cgroup
backlight: fix 88pm860x_bl macro collision
drivers/leds/ledtrig-gpio.c: make output match input, tighten input checking
MAINTAINERS: update Atmel AT91 entry
mm: fix truncate_setsize() comment
memcg: fix rmdir, force_empty with THP
memcg: fix LRU accounting with THP
memcg: fix USED bit handling at uncharge in THP
memcg: modify accounting function for supporting THP better
fs/direct-io.c: don't try to allocate more than BIO_MAX_PAGES in a bio
mm: compaction: prevent division-by-zero during user-requested compaction
mm/vmscan.c: remove duplicate include of compaction.h
memblock: fix memblock_is_region_memory()
thp: keep highpte mapped until it is no longer needed
kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.
This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel. A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).
Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Acked-by: David Woodhouse <david.woodhouse@intel.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During system suspend, the "wait for ring buffer to empty" loop would
always time out after three seconds, because the faster cached ring
buffer head read would always return zero. Force the slow-and-careful
PIO read on all but the first iterations of the loop to fix it.
This also removes the unused (and useless) 'actual_head' variable that
tried to approximate doing this, but did it incorrectly.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Cc: DRI mailing list <dri-devel@lists.freedesktop.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During suspend, Linus found that his machine would hang for 3 seconds,
and identified that intel_ring_buffer_wait() was the culprit:
"Because from looking at the code, I get the notion that
"intel_read_status_page()" may not be exact. But what happens if that
inexact value matches our cached ring->actual_head, so we never even
try to read the exact case? Does it _stay_ inexact for arbitrarily
long times? If so, we might wait for the ring to empty forever (well,
until the timeout - the behavior I see), even though the ring really
_is_ empty."
As the reported HEAD position is only updated every time it crosses a
64k boundary, whilst draining the ring it is indeed likely to remain one
value. If that value matches the last known HEAD position, we never read
the true value from the register and so trigger a timeout.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hangcheck and error recovery is only used by GEM.
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The [vk][cmz]alloc(_node) family of functions return void pointers which
it's completely unnecessary/pointless to cast to other pointer types since
that happens implicitly.
This patch removes such casts from drivers/gpu/drm/
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
For CRT and SDVO/HDMI, we need to use a normal, non-SSC, clock and so we
must clear any enabling bits left-over from earlier outputs. And also
seems to correct the LVDS panel on the Lenovo U160.
However, at one point, it did cause an "ERROR failed to disable
trancoder". So prolonged testing on top of Jesse's refactored and
error-checking CRTC logic is desired.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The i915 driver normally assumes the video bios has configured several
of the LVDS panel registers, and it just inherits the values. If the
vbios has not run, several of these will need to be setup.
If these are not correct then although the panel looks ok, output from an
HDMI encoder (eg, Chrontel CH7036) will be incorrect.
Signed-off-by: Mark Hayter <mdhayter@chromium.org>
[ickle: minor adjustments]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The i915 driver normally assumes the video bios has configured several
of the LVDS panel registers, and it just inherits the values. If the
vbios has not run, several of these will need to be setup. So we need to
check that the LVDS sync polarity is correctly configured per any
available modelines (e.g. EDID) and adjust if not, issuing a warning as
we do.
Signed-off-by: Mark Hayter <mdhayter@chromium.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These make us increase our frequency much more readily, and decrease
them only after significant idle time, resulting in a 20% performance
increase for nexuiz.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Move code around and invoke iomem annotation in a few more places in
order to silence sparse. Still a few more iomem annotations to go...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I changed 945's self refresh to work without the need for the driver to
enable/disable self refresh manually based on the idle state of the gpu.
This is much better than enabling/disabling self refresh for various
reasons, including staying in a lower power state for more time and
avoiding the need for cpu cycles.
This was originally done manually to workaround issues with the hardware
hanging. However, since 944001201: drm/i915: enable low power render
writes on GEN3 hardware, automatic CxSR seems stable.
Signed-off-by: Alexander Lam <lambchop468@gmail.com>
Acked-by : Li Peng <peng.li@linux.intel.com>
[ickle: play safe with the ordering and disable CxSR before tweaking any
watermark and enable afterwards.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
945 class hardware has an interesting quirk in which the vblank
interrupt is not raised if the CPU is in a low power state. (We also
suspect that the memory bus is clocked to the CPU/c-state and not the
GPU so there are secondary starvation issues.) In order to prevent the
most obvious issue of the low of the vblank interrupt (stuttering
compositing that only updates when the mouse is moving) is to install a
PM QoS request to prevent low c-states whilst the GPU is active.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
problems. So avoid FDI training and PCH PLL enabling in that case.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to unlock the phase sync pointer enable bit before we can
actually enable the phase sync pointer workaround on Ironlake.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Factor out the FDI disable function (make it a mirror of
ironlake_fdi_enable) and add some FDI related assertions to the FDI
training code (we need an active pipe & plane before we start
transmitting bits).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Along with assertion checks for the FDI transmitters and receivers
(including PLLs). Modify the pipe enable function to check for FDI PLL
status as well, when driving PCH ports.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise our writes will be silently ignored.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With assertions to check transcoder and reference clock state.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For pre-ILK only. Saves some code in the CRTC enable/disable functions
and allows us to check for pipe and panel status at enable/disable time.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When PLLs or timing regs are changed, we need to make sure the panel
lock will allow it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add plane enable/disable functions to prevent duplicated code and allow
us to easily check for plane enable/disable requirements (such as pipe
enable, plane status, pll status etc).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On Ironlake+ we need to enable these in a specific order.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Admittedly, trusting ACPI or the BIOS at all to be correct is littered
with numerous examples where it is wrong. Maybe, just maybe, we will
have better luck using the ACPI OpRegion lid status...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Without this change, blits to the front buffer won't invalidate FBC
state, causing us to scan out stale data. Make sure we update these
bits on every FBC enable, since they may get clobbered if we shut off
the display.
References: https://bugzilla.kernel.org/show_bug.cgi?id=26932
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add a couple of missing workaround bits for ILK & SNB. These disable
clock gating on a couple of units that would otherwise prevent FBC from
working.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
First, we were calling mc_stop() at the top of the function
which turns off all MC (memory controller) clients,
then checking if the GPU is idle. If it was idle we
returned without re-enabling the MC clients which would
lead to a blank screen, etc. This patch checks if the
GPU is idle before calling mc_stop().
Second, if the reset failed, we were returning without
re-enabling the MC clients. This patch re-enables
the MC clients before returning regardless of whether
the reset was successful or not.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Switching to pcie gen2 causes problems on some
boards. Add a module option to turn it on/off.
There are gen2 compatability issues with some
motherboards it seems.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33027
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next:
drm/nouveau: fix gpu page faults triggered by plymouthd
drm/nouveau: greatly simplify mm, killing some bugs in the process
drm/nvc0: enable protection of system-use-only structures in vm
drm/nv40: initialise 0x17xx on all chipsets that have it
drm/nv40: make detection of 0x4097-ful chipsets available everywhere
The switch to separate BAR and channel address spaces made the fbcon memory
address calculation incorrect on NV50+ boards, this commit fixes that.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This reverts commit dfe63bb0ad.
This commit was causing nouveau not to work properly, for -rc1 I'd
prefer it worked and we can look if this is useful for 2.6.39.
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDS
agp/intel: Fix device names of i845 and 845G
drm/i915: Disable GPU semaphores on SandyBridge mobile
drm/i915/execbuffer: Clear domains before beginning reloc processing
drm/i915/execbuffer: Reorder relocations to match new object order
drm/i915: Fix error handler to capture the first batch after the seqno
drm/i915: Add a module option to override the use of SSC
drm/i915/panel: The backlight is enabled if the current value is non-zero
drm/i915/debugfs: Correct format after changing type of err object 'size'
Hopefully, this is a temporary measure whilst the root cause is
understood. At the moment, we experience a hard hang whilst looping
urbanterror that has been identified as a result of the use of
semaphores, but so far only on SNB mobile.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32752
Tested-by: mengmeng.meng@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (59 commits)
ACPI / PM: Fix build problems for !CONFIG_ACPI related to NVS rework
ACPI: fix resource check message
ACPI / Battery: Update information on info notification and resume
ACPI: Drop device flag wake_capable
ACPI: Always check if _PRW is present before trying to evaluate it
ACPI / PM: Check status of power resources under mutexes
ACPI / PM: Rename acpi_power_off_device()
ACPI / PM: Drop acpi_power_nocheck
ACPI / PM: Drop acpi_bus_get_power()
Platform / x86: Make fujitsu_laptop use acpi_bus_update_power()
ACPI / Fan: Rework the handling of power resources
ACPI / PM: Register power resource devices as soon as they are needed
ACPI / PM: Register acpi_power_driver early
ACPI / PM: Add function for updating device power state consistently
ACPI / PM: Add function for device power state initialization
ACPI / PM: Introduce __acpi_bus_get_power()
ACPI / PM: Introduce function for refcounting device power resources
ACPI / PM: Add functions for manipulating lists of power resources
ACPI / PM: Prevent acpi_power_get_inferred_state() from making changes
ACPICA: Update version to 20101209
...
After reordering the sequence of relocating objects, commit 6fe4f1404,
we can no longer rely on seeing all reloc targets prior to performing
the relocation. As a result we were ignoring the need to flush objects
from the render cache and invalidate the sampler caches, resulting in
rendering glitches. So we need to clear the relocation domains earlier.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On the fault path, commit 6fe4f140 introduction a regression whereby it
changed the sequence of the objects but continued to use the original
ordering of relocation entries. The result was that incorrect GTT offsets
were being fed into the execbuffer causing lots of misrendering and
potential hangs.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst we had no older batches on the active list, everything was fine.
However, if the GPU is free running and the requests are only being
reaped by the periodic retirer, than the current seqno may not be at the
start of the list. In this case we need to select the first batch after
the last seqno written by the gpu and not inclusive of the seqno.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to workaround the issue with LVDS not working on the Lenovo
U160 apparently due to using the wrong SSC frequency, add an option to
disable SSC.
Suggested-by: Lukács, Árpád <lukacs.arpad@gmail.com>
Bugzillla: https://bugs.freedesktop.org/show_bug.cgi?id=32748
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
... and not if the maximum is non-zero. This fixes the typo introduced
in 47356eb672 and preserves the backlight value from boot.
[ickle: My thanks also to Indan Zupancic for diagnosing the original
regression and suggesting the appropriate fix.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org # after 47356eb672
As the mappable portion of the aperture is always a small subset at the
start of the GTT, it is allocated preferentially by drm_mm. This is
useful in case we ever need to map an object later. However, if you have
a large object that can consume the entire mappable region of the
GTT this prevents the batchbuffer from fitting and so causing an error.
Instead allocate all those that require a mapping up front in order to
improve the likelihood of finding sufficient space to bind them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than evicting an object at random, which is unlikely to alleviate
the memory pressure sufficient to allow us to continue, zap the entire
aperture. That should give the system long enough to recover and reap
some pages from the evicted objects, forestalling the allocation error
for the new object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before releasing the lock in order to copy the relocation list from user
pages, we need to drop all the object references as another thread may
usurp and execute another batchbuffer before we reacquire the lock.
However, the code was buggy and failed to clear the list...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
In order to retire active buffers whilst no client is active, we need to
insert our own flush requests onto the ring.
This is useful for servers that queue up some rendering and then go to
sleep as it allows us to the complete processing of those requests,
potentially making that memory available again much earlier.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Dave Airlie spotted that his ILK laptop with DMAR enabled was generating
the occasional DMAR warning.
"The ordering in the previous code was to rewrite the GTT table before
unmapping the pages and that makes sense to me."
This is his stable patch ported to d-i-n.
Reported-by: Dave Airlie <airlied@redhat.com>
Original-patch-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The docs recommend that if 8 display lines fit inside the FIFO buffer,
then the number of watermark entries should be increased to hide the
latency of filling the rest of the FIFO buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
FDI and the transcoders can fail for various reasons, so detect those
conditions and report on them.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cleanup several aspects of the rc6 code:
- misnamed intel_disable_clock_gating function (was only about rc6)
- remove commented call to intel_disable_clock_gating
- rc6 enabling code belongs in its own function (allows us to move the
actual clock gating enable call back into restore_state)
- allocate power & render contexts up front, only free on unload
(avoids ugly lazy init at rc6 enable time)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: checkpatch cleanup]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Enabling RC6 implies setting a graphics context. Make sure we do that
only after the ring has been enabled, otherwise our ring commands will
hang.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Re-enable rc6 support on Ironlake for power savings. Adds a debugfs
file to check current RC state, adds a missing workaround for Ironlake
MI_SET_CONTEXT instructions, and renames MCHBAR_RENDER_STANDBY to
RSTDBYCTL to match the docs.
Keep RC6 and the power context disabled on pre-ILK. It only seems to
hang and doesn't save any power.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the IMR for the USER interrupts are not modified elsewhere, we can
separate the spinlock used for these from that of hpd and pipestats.
Those two IMR are manipulated under an IRQ and so need heavier locking.
Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to ensure that writes through the GTT land before any
modification to the MMIO registers and so must impose a mandatory write
barrier when flushing the GTT domain. This was revealed by relaxing the
write ordering by experimentally mapping the registers and the GATT as
write-combining.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As has_gem is unconditionally set to true, the conditional immediately
following that assignment is superfluous.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These functions need to be reworked for Ironlake and above, but until
then at least avoid reading non-existent registers.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: combine with a gratuitous tidy]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When bringing up new hardware, or otherwise experimenting, GPU hangs are
a way of life. However, the automatic GPU reset can do more harm than
good under these circumstances, as we may wish to capture a full trace for
debugging.
Based on a patch by Zhenyu Wang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On Ironlake, the LP0 latency is hardcoded and in ns unit, while on
Sandybridge, it comes from a register and with unit 0.1 us. So, fix
the wrong latency value while computing wm0 on Ironlake and Sandybridge.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This patch actually makes the watermark code even uglier (if that's
possible), but has the advantage of sharing code between SNB and ILK at
least. Longer term we should refactor the watermark stuff into its own
file and clean it up now that we know how it's supposed to work.
Supporting WM2 on my Vaio reduced power consumption by around 0.5W, so
this patch is definitely worthwhile (though it also needs lots of test
coverage).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: pass the watermark structs arounds]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On i830 if the tail pointer is set to within 2 cachelines of the end of
the buffer, the chip may hang. So instead if the tail were to land in
that location, we pad the end of the buffer with NOPs, and start again
at the beginning.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In some configuration, the PCU may allow us to overclock the GPU.
Check for this case and adjust the max frequency as appropriate. Also
initialize the min/max frequencies to default values as indicated by
hardware.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... and just any combination of bits & ~PFIT_ENABLE. This way we do not
attempt disable to the panel fitter controller uselessly upon
intel_lvds_disable().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By tracking the current status of the backlight we can prevent recording
the value of the current backlight when we have disabled it. And so
prevent restoring it to 'off' after an unbalanced sequence of
intel_lvds_disable/enable.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=22672
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Alex Fiestas reported an issue with his HDMI connector being misdetected
as DVI unless he had something connected upon boot. By moving the
decision as to whether to use HDMI or DVI encoding for the HDMI capable
output until we probe the monitor means that we should avoid sending a
HDMI signal to a DVI monitor and also correctly detect hardware like
Alex's.
However, to really determine what connector is soldered onto the wire we
need to inspect the VBT sdvo child devices - but can we trust it?
Reported-by: Alex Fiestas <alex@eyeos.org>
Tested-by: Alex Fiestas <alex@eyeos.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Some voltage swing/pre-emphasis level use the same value on eDP
Sandybridge, like 400mv_0db and 600mv_0db are with the same value
of (0x0 << 22). So, fix them, and point out the value if it isn't
a supported voltage swing/pre-emphasis level.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is
not working any longer. The analog output is always activated
regardless of the type of monitor attached.
The culprit seems to be intel_crt_detect_ddc(), which returns true as
soon as an ACK from the EDID device is received. Obviously this
approach does not work with DVI-I where the analog and digital outputs
share a common DDC bus.
In a similar manner to the shared DDC wire, ala the "Mac Mini Hack", we
need an additional check to make sure that there really is an analog
device attached to the DDC.
Signed-off-by: David Müller <d.mueller@elsoft.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
When trying to do channel equalization, we need to make sure we still
have clock recovery on all lanes while training. We also need to try
clock recovery again if we lose the clock or if channel eq fails 5
times. We'll try clock recovery up to 5 more times before giving up
entirely.
Gets suspend/resume working on my Vaio again and brings us back into
compliance with the DP training sequence spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were using a stale pointer in the check which caused us to use CPU
attached DP params when we should have been using PCH attached params.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988
Tested-by: Jan-Hendrik Zab <jan@jhz.name>
Tested-by: Christoph Lukas <christoph.lukas@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (390 commits)
drm/radeon/kms: disable underscan by default
drm/radeon/kms: only enable hdmi features if the monitor supports audio
drm: Restore the old_fb upon modeset failure
drm/nouveau: fix hwmon device binding
radeon: consolidate asic-specific function decls for pre-r600
vga_switcheroo: comparing too few characters in strncmp()
drm/radeon/kms: add NI pci ids
drm/radeon/kms: don't enable pcie gen2 on NI yet
drm/radeon/kms: add radeon_asic struct for NI asics
drm/radeon/kms/ni: load default sclk/mclk/vddc at pm init
drm/radeon/kms: add ucode loader for NI
drm/radeon/kms: add support for DCE5 display LUTs
drm/radeon/kms: add ni_reg.h
drm/radeon/kms: add bo blit support for NI
drm/radeon/kms: always use writeback/events for fences on NI
drm/radeon/kms: adjust default clock/vddc tracking for pm on DCE5
drm/radeon/kms: add backend map workaround for barts
drm/radeon/kms: fill gpu init for NI asics
drm/radeon/kms: add disabled vbios accessor for NI asics
drm/radeon/kms: handle NI thermal controller
...
Lots of HDMI TVs overscan the incoming image by default.
The underscan option was added as a way to compensate for
that by underscanning the image so that the edges would
not be cut off on an overscanning TV. However, the TV
provides no way of knowing whether it is overscanning or
not. If the user has disabled overscan on their TV or has a
TV that does not overscan, you will get black bars around the
edges of your screen. Prior to the patch we got complaints
and bug reports from users with overscanning TVs, now with
the patch, we get lots of complaints and bug reports from
users with non-overscanning TVs. There's no good default,
but on average there have been more users complaining about
it being on by default than off, so change it to off. This
will probably result in a new deluge of overscanning TV user
complaints. There's no winning.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This avoids some issues in the current hdmi audio code for monitors
without audio.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-radeon-ni' of ../drm-radeon-next: (30 commits)
radeon: consolidate asic-specific function decls for pre-r600
drm/radeon/kms: add NI pci ids
drm/radeon/kms: don't enable pcie gen2 on NI yet
drm/radeon/kms: add radeon_asic struct for NI asics
drm/radeon/kms/ni: load default sclk/mclk/vddc at pm init
drm/radeon/kms: add ucode loader for NI
drm/radeon/kms: add support for DCE5 display LUTs
drm/radeon/kms: add ni_reg.h
drm/radeon/kms: add bo blit support for NI
drm/radeon/kms: always use writeback/events for fences on NI
drm/radeon/kms: adjust default clock/vddc tracking for pm on DCE5
drm/radeon/kms: add backend map workaround for barts
drm/radeon/kms: fill gpu init for NI asics
drm/radeon/kms: add disabled vbios accessor for NI asics
drm/radeon/kms: handle NI thermal controller
drm/radeon/kms: parse DCE5 encoder caps when setting up encoders
drm/radeon/kms: dvo dpms updates for DCE5
drm/radeon/kms: dac dpms updates for DCE5
drm/radeon/kms: DCE5 atom dig encoder updates
drm/radeon/kms: DCE5 atom transmitter control updates
...
* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next:
drm/nouveau: fix hwmon device binding
drm/nouveau: create grctx on the fly on all chipsets
drm/nvc0: fix init without firmware present
drm/nvc0/pgraph: fix 0x406028/0x405870 init
drm/nvc0/pgraph: more unit names
drm/nvc0/pfifo: support for chipsets with only one PSUBFIFO (0xc1)
drm/nvc0: reserve only subc 0 for kernel use
drm/nv50: sync up gr data error names with rnn, use for nvc0 also
drm/nvc0: parse a couple more PGRAPH_INTR
drm/nvc0: nuke left-over debug messages
drm/nvc0: kill off a couple more magics
drm/nouveau: Validate channel indices passed from userspace.
drm/nouveau: Only select ACPI_VIDEO if its dependencies are met
* 'for-2.6.38' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (33 commits)
usb: don't use flush_scheduled_work()
speedtch: don't abuse struct delayed_work
media/video: don't use flush_scheduled_work()
media/video: explicitly flush request_module work
ioc4: use static work_struct for ioc4_load_modules()
init: don't call flush_scheduled_work() from do_initcalls()
s390: don't use flush_scheduled_work()
rtc: don't use flush_scheduled_work()
mmc: update workqueue usages
mfd: update workqueue usages
dvb: don't use flush_scheduled_work()
leds-wm8350: don't use flush_scheduled_work()
mISDN: don't use flush_scheduled_work()
macintosh/ams: don't use flush_scheduled_work()
vmwgfx: don't use flush_scheduled_work()
tpm: don't use flush_scheduled_work()
sonypi: don't use flush_scheduled_work()
hvsi: don't use flush_scheduled_work()
xen: don't use flush_scheduled_work()
gdrom: don't use flush_scheduled_work()
...
Fixed up trivial conflict in drivers/media/video/bt8xx/bttv-input.c
as per Tejun.
Bind the hwmon structs to nouveau device kobj. This makes sure
the hwmon files are created in the device subdir in line with
all other hwmon drivers.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Move them to radeon_asic.h together with the other asic
specific stuff.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a copy-and-paste bug. We should be comparing 4 characters here
instead of 3.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The vbios only partially initializes the memory controller on
NI, so now we need to load the MC ucode in the driver and set
the default clocks once the ucode is loaded.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The MC ucode is no longer loaded by the vbios
tables as on previous asics. It now must be loaded
by the driver.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The hardware supports advanced user defined color management
but at the moment, there is no infrastructure in place to take
advantage of it so for now we just support the legacy LUTs.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds some new NI (northern islands) specific display
register defines.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
NI chips no longer load the MC ucode in the asic_init sequence so
the asic comes up in a basic mode with low engine/memory clocks and
a voltage. Once the MC ucode is loaded by the driver the card
can be programmed to it's proper default clocks and voltage. As such
the default clocks in the firmware info table as the post clocks, not
the default running clocks. Track the default post clocks and default
running clocks separately to handle this.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some systems disable the vbios on secondary cards or cards that
have been posted. This code re-enabled the vbios so the driver
can load it.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Needed to tell which DIG encoders are HBR2 capable for DP 1.2.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DVOOutputControl table was removed for DCE5.
DVOEncoderControl now handles everything.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DAC1OutputControl table was removed for DCE5.
DAC1EncoderControl now handles everything.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Supported on rv6xx/r7xx/evergreen. Cards come up in gen1 mode.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If you change the color depth via fbset or some other framebuffer aware
userland application struct fb_fix_screeninfo is not updated to this new
information. This patch fixes this issue. Also the function is changed to
just pass in struct drm_framebuffer so in the future we could use more
fields. I'm hoping some day fix->smem* could be set here :-)
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With cmwq, there's no reason for radeon to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead.
Because radeon_driver_irq_uninstall_kms() may be called from
unsleepable context, the work items can't be flushed from there.
Instead, init and flush from radeon_irq_kms_init/fini().
While at it, simplify canceling/flushing of rdev->pm.dynpm_idle_work.
Always initialize and sync cancel instead of being unnecessarily smart
about it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Alex Deucher <alexdeucher@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The CMASK RAM is for colorbuffer compression (used in conjunction
with MSAA). Only one user (filp) can access it.
The CMASK RAM access is managed in the same way as Hyper-Z, but there is
a separate ioctl, because an app that uses MSAA does not necessarily
have to use zbuffering.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acer laptop (TravelMate 5730G) has an HDMI connector
on the laptop and a DVI connector on the docking station
and both share the same encoder, hpd pin, and ddc line.
The bios connector table reflects this and is technically
correct, however, we drop the DVI connector here since
xrandr has no concept of encoders (only crtcs and connectors)
and will try and drive both connectors with different crtcs
which isn't possible on the hardware side and leaves no crtcs
for LVDS or VGA.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=32732
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
stage 1: turn card on, switch boot vga pointer.
stage 2: switch fbs, switch mux and power off old card.
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to track the state of the switch in drivers, so that after s/r
we don't resume the card we've explicitly switched off before. Also
don't allow a userspace open to occur if we've switched the gpu off.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This improves the IGD/DIS picking using firstly if Intel, then
if the bus is bus 0. There may be a correct way to do this, but
I've no idea what it is.
Signed-off-by: Dave Airlie <airlied@redhat.com>
At least on the nvidia mux the power switch seems to be executed
by the ACPI PS0/PS3 methods so need to do it explicitly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
As we have already detected something attached to the chip during
initialisation, always report the LVDS connector status as connected
during probing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Current 3D driver expects this behaviour. While this could be changed,
there's no compelling reason to reserve more than one subchannel for the
DRM. If we ever need to use an object other then M2MF, we can just
re-bind subchannel 0 as required.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When hacking the libdrm for improvements, I triggered a kernel crash
related to the fact that the NOUVEAU_NOTIFIEROBJ_ALLOC ioctl calls
nouveau_channel_get with an unchecked channel index.
The patch ensures that the channel index is an unsigned and validates
its value in nouveau_channel_get.
Signed-off-by: Michel Hermier <hermier@frugalware.org>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
CONFIG_ACPI_VIDEO depends on more than just CONFIG_ACPI, so add those
dependencies to the Kconfig select condition. The case where some
dependencies fail to be satisfied should be handled correctly, because
in that case the ACPI_VIDEO symbols we use are converted into
static-inline stubs.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
flush_scheduled_work() is deprecated and scheduled to be removed.
Directly flush info->deferred_work on removal instead.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Make ttm_bo::ttm_bo_device_release call cancel_delayed_work_sync()
instead of calling cancel_delayed_work() followed by
flush_scheduled_work().
This is to prepare for the deprecation and removal of
flush_scheduled_work().
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc:: Thomas Hellstrom <thellstrom@vmware.com>
Cc:: Dave Airlie <airlied@redhat.com>
The IPS driver is designed to be able to run detached from i915 and
just not enable GPU turbo in that case, in order to avoid module
dependencies between the two drivers. This means that we don't know
what the load order between the two is going to be, and we had
previously only supported IPS after (optionally) i915, but not i915
after IPS. If the wrong order was chosen, you'd get no GPU turbo, and
something like half the possible graphics performance.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
It's required by the specs, but we don't know why. Let's not find out
why.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Conflicts:
MAINTAINERS
arch/arm/mach-omap2/pm24xx.c
drivers/scsi/bfa/bfa_fcpim.c
Needed to update to apply fixes for which the old branch was too
outdated.
* 'intel/drm-intel-next' of /ssd/git/drm-next: (771 commits)
drm/i915: Undo "Uncouple render/power ctx before suspending"
drm/i915: Allow the application to choose the constant addressing mode
drm/i915: dynamic render p-state support for Sandy Bridge
drm/i915: Enable EI mode for RCx decision making on Sandybridge
drm/i915/sdvo: Border and stall select became test bits in gen5
drm/i915: Add Guess-o-matic for pageflip timestamping.
drm/i915: Add support for precise vblank timestamping (v2)
drm/i915: Add frame buffer compression on Sandybridge
drm/i915: Add self-refresh support on Sandybridge
drm/i915: Wait for vblank before unpinning old fb
Revert "drm/i915: Avoid using PIPE_CONTROL on Ironlake"
drm/i915: Pass clock limits down to PLL matcher
drm/i915: Poll for seqno completion if IRQ is disabled
drm/i915/ringbuffer: Make IRQ refcnting atomic
agp/intel: Fix missed cached memory flags setting in i965_write_entry()
drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
drm/i915: Enable RC6 autodownclocking on Sandybridge
drm/i915: Terminate the FORCE WAKE after we have finished reading
drm/i915/gtt: Clear the cachelines upon resume
drm/i915: Restore GTT mapping first upon resume
...
Blitting from vram to gart is problematic at the moment.
Use the CPU for now to avoid buffer corruption.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Always useful to know just which connector was polled and had its
status updated.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were using the lockup struct from the wrong union.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This block may contain various additional LCD info such
as physical size and a stored EDID.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some systems have the LCD width and height in mm available in the
LCD info table. Use this info if there is no EDID to provide it.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch tries to make sure that the vbl.reply.sequence
vblank count for a queued or emitted vblank event always
corresponds to the true vblank count of queueing/emission, so
the ddx can rely on the returned target_msc for consistency
checks and implementation of swap_intervals in glXSwapBuffers().
Without this there is a small race-condition between the
userspace ddx queueing a vblank event and the vblank
counter incrementing before the event gets queued in
the kernel.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Kconfig says fbcon is required by drm_kms_helper. If radeon, fbcon,
and drm_kms_helper are all modules, radeon is auto loaded (by PCI id?),
drm_kms_helper is loaded because of the module dependency, but fbcon
isn't loaded leaving the console unusable. Since fbcon is required
and there isn't an explicit module dependency, request the module
to be loaded from drm_kms_helper.
Signed-off-by: David Fries <david@fries.net>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Readability cleanup and fix debugging output, no
functional change.
Reported-by: Frank Huang <FrankR.Huang@amd.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Works more like DCE4.0 despite what the docs say.
This fixes blank screen issues when changing crtc
routing due to incorrect crtc to dig mapping.
v2: only two DIGx blocks, routing is hardcoded
based on link.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
add to the 2.8 bump for pageflip
The purpose of these regs is to work around a TX hw bug in R520.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed. Re-program
the mode first, then reset the dpms state.
This fixes the infamous atombios timeouts on resume.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For the fbdev api if the struct fb_var_screeninfo accel_flags field is set
to FB_ACCELF_TEXT then userland applications can not mmap the mmio region.
Since it is a bad idea for DRM drivers to expose the mmio region via the
fbdev layer we always set the accel_flags to prevent this. Please apply.
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 541cc96691.
Wei Yonjun reported this caused a regression against Intel VGA hotplug
on his G33 hw.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[danvet: add cc: stable, forward ported and compile-fixed for X86]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[airlied: move to even earlier in module load.]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Manaul revert of 0cdab21f9a, just to
remove the call to disable the clock gatings and powerctx before
suspend.
Peter Clifton bisected a suspend failure on his gme45 and found this to
be the culprit. As this was intended to be a fix for a similar suspend
failure for Ironlake (it didn't work), undoing this patch should have no
other side-effects.
Reported-and-tested-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The relative-to-general state default is useless as it means having to
rewrite the streaming kernels for each batch. Relative-to-surface is
more useful, as that stream usually needs to be rewritten for each
batch. And absolute addressing mode, vital if you start streaming
state, is also only available by adjusting the register...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add an interrupt handler for switching graphics frequencies and handling
PM interrupts. This should allow for increased performance when busy
and lower power consumption when idle.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This patch changes the strategy for pageflip completion
timestamping. It detects if the pageflip completion
routine gets executed before or after drm_handle_vblank,
and thereby decides if the returned vblank count and
timestamp must be incremented by 1 frame(duration) or
not. It compares the current system time at invocation
against the current vblank timestamp. If the difference
is more than 0.9 video refresh interval durations then
it assumes the vblank timestamp and count are outdated
and need to be incremented and does so. Otherwise it
assumes a delayed pageflip irq and doesn't correct
the timestamp and count.
Advantage of this patch: Pageflip timestamping becomes
more robust against implementation errors and is
maintenance free for future GPU's.
Disadvantage: A few dozen (hundred?) nsecs extra
time spent in pageflip irq handler for each flip,
compared to hard-coded per-gpu settings?
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
v2: Change IS_IRONLAKE to IS_GEN5 to adapt to 2.6.37
This patch adds new functions for use by the drm core:
.get_vblank_timestamp() provides a precise timestamp
for the end of the most recent (or current) vblank
interval of a given crtc, as needed for the DRI2
implementation of the OML_sync_control extension.
It is a thin wrapper around the drm function
drm_calc_vbltimestamp_from_scanoutpos() which does
almost all the work.
.get_scanout_position() provides the current horizontal
and vertical video scanout position and "in vblank"
status of a given crtc, as needed by the drm for use by
drm_calc_vbltimestamp_from_scanoutpos().
The patch modifies the pageflip completion routine
to use these precise vblank timestamps as the timestamps
for pageflip completion events.
This code has been only tested on a HP-Mini Netbook with
Atom processor and Intel 945GME gpu. The codepath for
(IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's
has not been tested so far due to lack of hardware.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next: (93 commits)
drm/nv50: fix a couple of vm init issues
drm/nv04-nv40: Fix up PCI(E) GART DMA object bus address calculation.
drm/nouveau: kick vram functions out into an "engine"
drm/nouveau: allow gpuobj vinst to be a virtual address when necessary
drm/nv50: tidy up PCIEGART implementation
drm/nv50: enable non-contig vram allocations where requested
drm/nv50: enable 4KiB pages for small vram allocations
drm/nv50: implement global channel address space on new VM code
drm/nv50: implement BAR1/BAR3 management on top of new VM code
drm/nv50: import new vm code
drm/nv50: implement custom vram mm
drm/nouveau: Avoid potential race between nouveau_fence_update() and context takedown.
drm/nouveau: fix use of drm_mm_node in semaphore object
drm/nouveau: wrap calls to ttm_bo_validate()
drm/nouveau: no need to zero dma objects, we fill them completely anyway
drm/nouveau: introduce a util function to wait on reg != val
drm/nouveau: implicitly insert non-DMA objects into RAMHT
drm/nouveau: make fifo.create_context() responsible for mapping control regs
drm/nouveau: Spin for a bit in nouveau_fence_wait() before yielding the CPU.
drm/nouveau: Use WC memory on the AGP GART.
...
Drivers using their own implementation of io_mem_reserve/io_mem_free are
likely to store the tracking information for the map in mem.mm_node, so
it can't be freed while still mapped.
Signed-off-by: Ben Skeggs<bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this adds a bo create, and fence seq tracking tracepoints.
This is just an initial set to play around with, we should investigate
what others we need would be useful.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes overwriting the first page table entry when testing that the PRAMIN
BAR can be correctly read/written, and adds an additional bar flush after
poking the BAR3 control regs.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Make sure vram changes hit memory. This mirrors the
6xx/7xx behavior.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There are too many strange corner cases triggered in old userspace
drivers out there to that it's nearly impossible to not break some
obscure app.
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Seems to cause problems on certain laptops
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=24462
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
agp/intel: Fix missed cached memory flags setting in i965_write_entry()
drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD
drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to DVI converter
Add frame buffer compression on Sandybridge. The method is similar to
Ironlake, except that two new registers of type GTTMMADR must be written
with the right fence info.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add the support of memory self-refresh on Sandybridge, which is now
support 3 levels of watermarks and the source of the latency values
for watermarks has changed.
On Sandybridge, the LP0 WM value is not hardcoded any more. All the
latency value is now should be extracted from MCHBAR SSKPD register.
And the MCHBAR base address is changed, too.
For the WM values, if any calculated watermark values is larger than
the maximum value that can be programmed into the associated watermark
register, that watermark must be disabled.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
[ickle: remove duplicate compute routines and fixup for checkpatch]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Be paranoid and ensure that the vblank has passed and the scanout has
switched to the new fb, before unpinning the old one and possibly
tearing down its PTEs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Restore PIPE_CONTROL once again just for Ironlake, as it appears that
MI_USER_INTERRUPT does not have the same coherency guarantees, that is
on Ironlake the interrupt following a GPU write is not guaranteed to
arrive after the write is coherent from the CPU, as it does on the
other generations.
Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reported-by: Shuang He <shuang.he@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32402
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes the lack of output on the LVDS panel of the Lenovo U160.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31596
Reported-and-tested-by: Dirk Gouders <gouders@et.bocholt.fh-gelsenkirchen.de>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we already know the limits for the hardware clock, pass it down
rather than recomputing them for each match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to enforce the correct memory barriers for irq get/put, we need
to perform the actual counting using atomic operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove the ACPI video output switching control as it never works.
With the patch applied,
ACPI video driver still catches the video output notification,
but it does nothing but raises the notification to userspace.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
BIOSes. Can't live without them (apparently), definitely can't live with
them.
Reported-by: Ben Gamari <bgamari@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24312
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once we have read the value out of the GT power well, we need to remove
the FORCE WAKE bit to allow the system to auto-power down.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As suggested by Daniel Vetter, this is a safeguard should any of the
registers cause reference to PTE entries.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we provide a list of all objects that will be accessed from the
batchbuffer, we can build a lut of the handles associated with those
objects for this invocation and use that to avoid the overhead of
looking up those objects again for every relocation.
The cost of building and searching a small hash table is much less than
that of acquiring a spinlock, searching a radix tree and manipulating an
atomic refcnt per relocation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't post a downclocking task if the device is still active when the
idle timer fires. A pathological process could queue up several seconds
worth of processing and then go to sleep, during which time the idle
timer would kick in and downclock the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the tail advances beyond the autoreport HEAD value, then we need to
fallback to an uncached read of the HEAD register in order to ascertain
the correct amount of remaining space in the ringbuffer.
Reported-by: Fang, Xun <xunx.fang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32259
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It should be required for all 7xx asics, but seems to cause
problems on some AGP 7xx chips.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=19002
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reported-and-Tested-by: Duncan <1i5t5.duncan@cox.net>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The "e" pointer is either NULL or freed when we call
drm_vblank_put(dev, e->pipe) on the error path. Just pass the "pipe"
variable directly instead.
I changed another caller to use "pipe" as well for consistency.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Grub doesn't parse spaces in parameters correctly, so
this makes it impossible to force video= parameters
for kms on the grub kernel command line.
v2: shorten the names to make them easier to type.
Reported-by: Sergej Pupykin <ml@sergej.pp.ru>
Cc: Sergej Pupykin <ml@sergej.pp.ru>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DisplayPort standard (1.1a) states that:
The I2C-over-AUX Reply field is valid only when Native AUX CH Reply
field is AUX_ACK (00). When Native AUX CH Reply field is not 00, then,
I2C-over-AUX Reply field must be 00 and be ignored.
This fixes broken EDID reading when using an active DisplayPort to
duallink DVI converter. If the AUX CH replier chooses to defer the
transaction, a short read occurs and erroneous data is returned as
the i2c reply due to a lack of length checking and failure to check
for AUX ACK.
As a result, broken EDIDs can look like:
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: bc bc bc ff bc bc bc ff bc bc bc ac bc bc bc 45 ???.???.???????E
10: bc bc bc 10 bc bc bc 34 bc bc bc ee bc bc bc 4c ???????4???????L
20: bc bc bc 50 bc bc bc 00 bc bc bc 40 bc bc bc 00 ???P???.???@???.
30: bc bc bc 01 bc bc bc 01 bc bc bc a0 bc bc bc 40 ???????????????@
40: bc bc bc 00 bc bc bc 00 bc bc bc 00 bc bc bc 55 ???.???.???.???U
50: bc bc bc 35 bc bc bc 31 bc bc bc 20 bc bc bc fc ???5???1??? ????
60: bc bc bc 4c bc bc bc 34 bc bc bc 46 bc bc bc 00 ???L???4???F???.
70: bc bc bc 38 bc bc bc 11 bc bc bc 20 bc bc bc 20 ???8??????? ???
80: bc bc bc ff bc bc bc ff bc bc bc ff bc bc bc ff ???.???.???.???.
...
which can lead to:
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>30 30 30 30 30 30 30 32 38 32 30 32 63 63 31 61 000000028202cc1a
<3>28 00 02 8c 00 00 00 00 18 00 00 00 00 00 00 00 (...............
<3>20 4c 61 73 74 20 62 65 61 63 6f 6e 3a 20 33 32 Last beacon: 32
<3>32 30 6d 73 20 61 67 6f 46 00 05 8c 00 00 00 00 20ms agoF.......
<3>36 00 00 00 00 00 00 00 00 0c 57 69 2d 46 69 20 6.........Wi-Fi
<3>52 6f 75 74 65 72 01 08 82 84 8b 96 24 30 48 6c Router......$0Hl
<3>03 01 01 06 02 00 00 2a 01 00 2f 01 00 32 04 0c .......*../..2..
<3>12 18 60 dd 09 00 10 18 02 00 00 01 00 00 18 00 ..`.............
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
[ickle: fix up some surrounding checkpatch warnings]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
NVC0 will be able to share some of nv50's paths this way. This also makes
it the card-specific vram code responsible for deciding if a given set
of tile_flags is valid, rather than duplicating the allowed types in
nv50_vram.c and nouveau_gem.c
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
As of this commit, it's guaranteed that if an object is in VRAM that its
GPU virtual address will be constant.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is required on nv50 as we need to be able to have more precise control
over physical VRAM allocations to avoid buffer corruption when using
buffers of mixed memory types.
This removes some nasty overallocation/alignment that we were previously
using to "control" this problem.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
At some point in the future, this bo won't necessarily be backed by
a drm_mm_node, so use the start/size fields of the ttm_mem_reg instead.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The regs belong to PFIFO, they're different for pretty much the same
generations we need different PFIFO control for, and NVC0 is going
to be even more different than the rest.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Sleeping doesn't pay off for very short delays in comparison with the
minimum granularity of schedule_timeout().
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There have been reports of PFIFO cache errors during context take down
(fdo bug 31637). They are caused by some GPU objects being taken out
while the channel is still potentially processing commands. Make sure
that all the previous rendering has landed before releasing a GPU
object.
Reported-by: Grzesiek Sójka <pld@pfu.pl>
Reported-by: Patrice Mandin <patmandin@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvxx_graph_isr is already taking care of it. In some cases this
could've made you miss PGRAPH interrupts (e.g. when you were supposed
to get several IRQs of the same kind in a row).
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
No functional changes, just simplify some code paths a bit.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Avoid overflowing a 32 bit value.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
v3 - don't explicitly set range limit
- use min macro
Cc: stable <stable@kernel.org>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Prevents code that assumes that the encoder is active when asked to be
disabled from dying a horrible death.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As we may try to power down the link at various times, it is not
necessarily still coupled with an encoder and so we must be careful not
to depend upon an operation that is only valid when the link is still
attached to a pipe.
Fixes regression in 5bddd17.
Reported-and-tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org [after applying 5bddd17]
In order for bos to retire eventually, a request must be sent down the
ring. This is expected, for example, by occlusion queries for which mesa
will wait upon (whilst running glean) before issuing more batches and so
the normal activity upon the ring is suspended and we need to emit a
request to clear the idle ring.
Reported-by: Jinjin, Wang <jinjin.wang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30380
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I'm still seeing tiling corruption of PutImage and CopyArea (I think)
under mutter on pnv, so obviously the pipelining logic is deeply flawed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Userspace should not have been declaring that it needed fenced GPU
access with gen4+ as those GPUs have no fenced commands, but to be on
the safe side it is easier to ignore userspace in case they did.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The ability to save the hardware context upon powering down the render
clock through PWRCTXA is only available on a couple of gen4 chipsets.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The workaround is hideous and we are using the STORE_DWORD on all other
generations on all other rings, so use for the gen5 render ring as
well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Linus Torvalds pointed out that our code was unbalanced when powering on
the panel with respect to the power off sequence in that we were failing
to restore the panel-fitter. The consequence of this would be that
across a simple DPMS off/on for a non-native mode, without an intervening
modeset, the panel fitter would remain disabled and the output would shift
on the panel.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There's not much we can do here but hope for the best. However the first
failure happens quite frequently and if often remedied by the second
attempt to reset HEAD. So only print the error if that attempt also
fails.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=19802
Reported-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Otherwise we can't really fix the abi-braindeadness of forcing
libva to manually wait for rendering when switching rings. Which
in turn makes implementing hw semaphores a pointless exercise
(at least for ironlake).
[Also added the relaxed fencing param to explain the jump in
numbering - relaxed fencing is in -next.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The bulk of the change is to convert the growing list of rings into an
array so that the relationship between the rings and the semaphore sync
registers can be easily computed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Previously we enabled this for gen4, only to have to revert it due to it
causing a large number of spurious wakeups. Try again hoping that the
hardware has become more sane in the mean time...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Magic numbers from the specs. This is supposed to allow the PLL some
variance to improve jitter performance and VCO headroom across
manufacturing and environmental variations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... it's because setting the Pixel Multiply bits only takes effect once
the PLL is enabled and stable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes the modesetting on the secondary panel of the Libretto W100 and
presumably many more Ironlake laptops with SDVO LVDS displays.
Reported-and-tested-by: Matthew Willoughby <mattfredwill@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Use the hardware DDA to calculate the ratio with as much accuracy as is
possible.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
If we leave the registers in a conflicting state then when we attempt
to teardown the active mode, we will not disable the pipes and planes
in the correct order -- leaving a plane reading from a disabled pipe and
possibly leading to undefined behaviour.
Reported-and-tested-by: Andy Whitcroft <apw@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32078
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
In typical Apple fashion there's no standard information about what
encoders are present on this machine, this patch adds a quirk to
provide it.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fix running of destroy_context() when create_context() has never been
called for the channel, and fill in engine's tlb_flush() function pointer.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Allows callers to install their own handlers for when a GPIO line
changes state (such as for hotplug detect).
This also fixes a bug where we weren't acknowledging the GPIO IRQ
until after the bottom half had run, causing a severe IRQ storm
in some cases.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The point is to share more code between the PFB/PGRAPH tile region
hooks, and give the hardware specific functions a chance to allocate
per-region resources.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_bo_move_m2mf() needs to lock the kernel channel, and it may be
called from the pushbuf IOCTL with an user channel already locked. Use
a separate subclass for the kernel channel mutex because this is
legitimate mutex nesting.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In a multihead setup vblank interrupts may end up enabled in both
heads. In that case we want to ignore the vblank interrupts coming
from the wrong CRTC to avoid tearing and unbalanced calls to
drm_vblank_get/put (fdo bug 31074).
Reported-by: Felix Leimbach <felix.leimbach@gmx.net>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nv0x-nv4x should be mostly fine, nv50 doesn't work yet.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_fence_* functions are not type safe, which could lead to bugs.
Additionally every use of nouveau_fence_unref had to cast struct
nouveau_fence to void **.
Fix it by renaming old functions and creating static inline functions with
new prototypes. We still need old functions, because we pass function
pointers to ttm.
As we are wrapping functions, drop unused "void *arg" parameter where possible.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Only supported on NV50+ so far, and disabled by default currently. The
module parameter "msi=1" will enable it.
There's a kernel bug which will cause this to fail if the module (or the
NVIDIA binary driver) has ever been loaded before loading nouveau with
MSI enabled. As such, this is only safe to enable if you have nouveau
load on boot, and don't wish to ever reload it.
The workaround is to "echo 0 > /sys/bus/pci/devices/<device>/enable"
until the enable count reads 0. Then you should be able to load nouveau
with MSI enabled.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not an issue right now, we're forced to 64k size/alignment by the BO
allocator anyway. This won't be the case soon.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This really needs cleaning up somehow, and probably investigate what's
needed to do this on earlier generations. NVIDIA do something similar
there too.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We previously added all the available classes for the entire generation,
even though the objects wouldn't work on the hardware.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The structs themselves, as well as the non-sw object creation function are
probably very misnamed now. That's a problem for later :)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Without it there's a potential race with nouveau_fence_update().
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It needs a "strong" channel reference because it actually writes to
the channel pushbuf, otherwise the corresponding FIFO context could
get kicked off in the middle of nouveau_fence_sync().
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fences didn't increment the channel reference count, and the fenced
channel could go away at any time. Fixes a potential race in
nouveau_fence_update().
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_channel_ref() takes a "weak" channel reference that doesn't
prevent the hardware channel resources from being released, it just
keeps the channel data structure alive.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_channel_put() can be executed after the 'refcount == 0' check
in nouveau_channel_get() and before the channel reference count is
incremented. In that case CPU0 will take the context down while CPU1
thinks it owns the channel and 'refcount == 1'.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The destroy_context() engine hooks call gpuobj management functions to
release the channel resources, these functions use HARDIRQ-unsafe locks
whereas destroy_context() is called with the HARDIRQ-safe
context_switch_lock held, that's a lock ordering violation.
Push the engine-specific channel destruction logic into destroy_context()
and let the hardware-specific code lock and unlock when it's actually
needed. Change the engine destruction order to avoid a race in the small
gap between pgraph and pfifo context uninitialization.
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The pushbuf ioctl syncs after validation, no need for this anymore.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
No other driver uses this, and userspace should be responsible for handling
locking between them if they share BOs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This fixes a race condition between fbcon acceleration and TTM buffer
moves. To reproduce:
- start X
- switch to vt and "while (true); do dmesg; done"
- switch to another vt and "sleep 2 && cat /path/to/debugfs/dri/0/evict_vram"
- switch back to vt running dmesg
We don't make use of this on any other channel yet, they're currently
protected by drm_global_mutex. This will change in the near future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A future commit will add locking to the DRM's channel, and there's numerous
problems that come up if we allow printk from an interrupt context to be
accelerated. It seems saner to just disallow it completely.
As a nice side-effect, all the "to accel or not to accel" logic gets moved
out of the chipset-specific code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* 'drm-radeon-fusion' of ../drm-radeon-next:
drm/radeon/kms: add Ontario APU ucode loading support
drm/radeon/kms: add Ontario Fusion APU pci ids
drm/radeon/kms: enable MSIs on fusion APUs
drm/radeon/kms: add power table parsing support for Ontario fusion APUs
drm/radeon/kms: refactor atombios power state fetching
drm/radeon/kms: add bo blit support for Ontario fusion APUs
drm/radeon/kms: add thermal sensor support for fusion APUs
drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs
drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs
drm/radeon/kms: evergreen.c updates for fusion
drm/radeon/kms: MC setup changes for fusion APUs
drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function
drm/radeon/kms: add support for ss overrides on Fusion APUs
drm/radeon/kms: Add support for external encoders on fusion APUs
drm/radeon/kms: atom changes for DCE4.1 devices
drm/radeon/kms: add new family id for AMD Ontario APUs
drm/radeon/kms: upstream power table updates
drm/radeon/kms: upstream atombios.h updates
drm/radeon/kms: upstream ObjectID.h updates
drm/radeon/kms: setup mc chremap properly on r7xx/evergreen
* 'drm-radeon-next' of ../drm-radeon-next:
drm/radeon/kms: improve pflip precision on r1xx-r4xx
drm/kms/radeon: Use high precision timestamps for pageflip completion events.
drm/kms/radeon: Reorder vblank and pageflip interrupt handling.
drm/radeon/kms: add pageflip ioctl support (v3)
drm/kms/radeon: Add support for precise vblank timestamping.
This workaround only applies to Ironlake.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
The pipe is always set to 8BPC, but here we were leaving whatever
previous bits were set by the BIOS in place.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
As the tracepoint is now decoupled from when the actual register is
assigned and was never complemented by detailing when the object lost
its fence, it has outlived its limited usefulness. Profiling the actual
stalls is a far more profitable venture anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the userspace mappings are torn down on every GPU write, we prefer to
track when the buffer is activated (via a fresh i915_gem_fault). This
makes the LRU conceptually simpler. With coherent mappings, the
remaining use-case for set_domain_ioctl is GPU synchronisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With this change, every batchbuffer can use all available fences (save
pinned and scanout, of course) without ever stalling the gpu!
In theory. Currently the actual pipelined update of the register is
disabled due to some stability issues. However, just the deferred update
is a significant win.
Based on a series of patches by Daniel Vetter.
The premise is that before every access to a buffer through the GTT we
have to declare whether we need a register or not. If the access is by
the GPU, a pipelined update to the register is made via the ringbuffer,
and we track the last seqno of the batches that access it. If by the
CPU we wait for the last GPU access and update the register (either
to clear or to set it for the current buffer).
One advantage of being able to pipeline changes is that we can defer the
actual updating of the fence register until we first need to access the
object through the GTT, i.e. we can eliminate the stall on set_tiling.
This is important as the userspace bo cache does not track the tiling
status of active buffers which generate frequent stalls on gen3 when
enabling tiling for an already bound buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6xx/7xx was hitting the wrong BUS_CNTL reg and bits.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
Revert "drm/i915/dp: use VBT provided eDP params if available"
drm/i915: Clear pfit registers when not used by any outputs
drm/i915: fix regression due to ba3d8d749b
This makes the various rings more consistent by removing the anomalous
handing of the rendering ring execbuffer dispatch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 869184a675.
This is required for the Sony Vaio Jesse was working on at the time, but
breaks most other eDP machines - machines that were working in earlier
kernels.
Reported-and-tested-by: Dave Airlie <airlied@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31188
Tested-by: Zhao Jian <jian.j.zhao@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... otherwise the panel-fitter may be left enabled with random settings
and cause unintended filtering (i.e. blurring of native modes on external
panels).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31942
Reported-and-tested-by: Ben Kohler <bkohler@gmail.com>
Tested-by: Ciprian Docan <docan@eden.rutgers.edu>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector->status
value instead of being discarded.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... so that upon first use after resume we will reacquire the fence reg.
Reported-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the error occurred on the current object, it means that its state was
not changed and so it should be excluded from the unwind.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We don't track gpu flush request in any special way. So even with
obj->write_domain == 0, a gpu flush might be outstanding but no
yet executed. Even worse, the latest request might use the object
only for reading. So and unconditional call to object_wait_rendering
is needed for !pipelined.
Hence revert that patch fully and untangle the flushing from the
synchronization again.
Reported-by: Keith Packard <keithp@keithp.com>
Tested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915/sdvo: Always add a 30ms delay to make SDVO TV detection reliable
MAINTAINERS: INTEL DRM DRIVERS list (intel-gfx) is subscribers-only
drm/i915/sdvo: Always fallback to querying the shared DDC line
drm/i915: Handle pagefaults in execbuffer user relocations
drm/i915/sdvo: Only enable HDMI encodings only if the commandset is supported
drm/i915: Only save/restore cursor regs if !KMS
drm/i915: Prevent integer overflow when validating the execbuffer
The update pending bit has a separate enable bit.
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit d33ef52d9d.
This change seems to expose a bug in the 3D driver tiggered by
certain apps, so revert it to keep userspace working.
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Besides the minimal improvement in reducing the execbuffer overhead, the
real benefit is clarifying a few routines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A number of dragons have been seen lurking within the execbuffer code.
The first step is then to isolate them from the rest and begin to
scrutinise them in depth. Suggested by Daniel Vetter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Simply remove our accounting of objects inside the aperture, keeping
only track of what is in the aperture and its current usage. This
removes the over-complication of BUGs that were attempting to keep the
accounting correct and also removes the overhead of the accounting on
the hot-paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With KMS, we can simply relinquish the fence when we idle the GPU and
reassign it upon first use.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Commit d09c23de intended to add a 30ms delay to give the ADD time to
detect any TVs connected. However, it used the sdvo->is_tv flag to do so
which is dependent upon the previous detection result and not whether the
output supports TVs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Avoid evicting buffers that will be used later in the batch in order to
make room for the initial buffers by pinning all bound buffers in a
single pass before binding (and evicting for) fresh buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On a few devices, like the Mac Mini, the CRT DDC pins are shared between
the analog connector and the digital connector. In this scenario, rely
on the EDID to determine if a digital panel is connected to the digital
connector.
Reported-and-tested-by: Tino Keitel <tino.keitel@tikei.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This used to check the precondition that all fences were to be located
in a mappable area, redundant now as those two parameters are combined
into one.
After pinning, we assert that the buffer is bound into the desired
region.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The pipe control object is allocated by the device for the sole use of the
render ringbuffer. Move this detail from the general code to the render
ring buffer initialisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having seen the effects of erroneous fencing on the batchbuffer, a
useful sanity check is to record the fence registers at the time of an
error.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Combining map_and_fenceable revealed a bug in
i915_gem_object_gtt_size() in that it always computed the appropriate
fence size for the object regardless of tiling state which caused us to
over-allocate linear buffers when binding to the GTT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This still uses the agp functions to actually reinstate the mappings
(with a gross hack to make agp cooperate), but it wires everything
up correctly for the switchover.
The call to agp_rebind_memory can be dropped because all non-kms drivers
do all their rebinding on EnterVT.
v2: Be more paranoid and flush the chipset cache after restoring gtt
mappings.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is required to restore gtt mappings on resume when agp is gone.
The right way to do this would be to make sturct drm_mm_node embeddable
and use the allocation list maintained by the drm memory manager. But
that's a bigger project. Getting rid of the per bo agp_mem will save
more memory than this wastes, anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
No longer used.
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently if we hit a pagefault when applying a user relocation for the
execbuffer, we bail and return EFAULT to the application. Instead, we
need to unwind, drop the dev->struct_mutex, copy all the relocation
entries to a vmalloc array (to avoid any potential circular deadlocks
when resolving the pagefault), retake the mutex and then apply the
relocations. Afterwards, we need to again drop the lock and copy the
vmalloc array back to userspace.
v2: Incorporate feedback from Daniel Vetter.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The GATT is a write-only set of registers, reading from them in the
manner of i915_gtt_to_phys() is supposed to be undefined. However a
simple solution exists as we allocate linear memory from the stolen
area, we can simply add the block offset to the base register. As a
side-effect we recover all the unused stolen GTT entries and so enlarge
our aperture.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After a GPU reset, the backlight controller registers may be also reset
to 0. In that case we should restore those to the original values
programmed by the BIOS. Note that we still lack the code to handle the
case where the BIOS failed to program those registers at all...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The vbios power tables on my inagua board seem a bit funky...
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The function was getting too large. Rework it to share
more state better handle new power table formats.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- CONFIG_MEMSIZE is in bytes on fusion.
- FB_BASE and FB_TOP are finer grained.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
MC_VM_FB_LOCATION is at a different offset between r6xx and r7xx/evergreen.
The location is needed for vram setup on fusion chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
System specific spread spectrum overrides can be specified in
the integrated system info table for Fusion APUs. This adds
support for using those overrides.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Should improve performance slightly and possibly fix some
issues.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As we conflated intel_sdvo->is_hdmi with both having HDMI support on the
ADD along with having HDMI support on the monitor, we would attempt to
use HDMI encodings even if the interface did not support those commands.
Reported-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
We were reading our 64-bit value in I915_READ64 and returning 32 bits
of it. The restoration of fence regs at resume then had a zero end
value, and the fence had no effect.
Version 2: Split register access functions into per-size versions
Sharing code between different sizes seemed reasonable when we only
needed a single copy, but as 64-bit access requires its own version,
it makes sense to just split them out for each size.
Reported-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: use a macro to create the various read/write routines]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This has proven sufficient to recover from a hang of the GPU using the
gem_bad_blit test while at the KMS console then starting X. When
attempting the same during an X session, the timer doesn't appear to
trigger.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It isn't used for the hangcheck, which does its work right from the
timer trigger, but hangcheck can lead to error state recording, which
is run off of the workqueue.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When trying to diagnose mysterious errors on resume, capture the
display register contents as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The pinned buffers are useful for diagnosing errors in setting up state
for the chipset, which may not necessarily be 'active' at the time of
the error, e.g. the cursor buffer object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than re-implementing in the Radeon driver,
Use the execbuf / cs / pushbuf utilities that comes with TTM.
This comes with an even greater benefit now that many spinlocks have been
optimized away...
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch attempts to fix up shortcomings with the current calling
sequences.
1) There's a fastpath where no locking occurs and only io_mem_reserved is
called to obtain needed info for mapping. The fastpath is set per
memory type manager.
2) If the fastpath is disabled, io_mem_reserve and io_mem_free will be exactly
balanced and not called recursively for the same struct ttm_mem_reg.
3) Optionally the driver can choose to enable a per memory type manager LRU
eviction mechanism that, when io_mem_reserve returns -EAGAIN will attempt
to kill user-space mappings of memory in that manager to free up needed
resources
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Rather than having the driver supply the validation sequence, leave that
responsibility to TTM. This saves some confusion and a function argument.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Drastically reduce the number of spin lock / unlock operations by performing
unreserving and fencing under global locks.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jerome Glisse <j.glisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The bo lock used only to protect the bo sync object members, and since it
is a per bo lock, fencing a buffer list will see a lot of locks and unlocks.
Replace it with a per-device lock that protects the sync object members on
*all* bos. Reading and setting these members will always be very quick, so
the risc of heavy lock contention is microscopic. Note that waiting for
sync objects will always take place outside of this lock.
The bo device fence lock will eventually be replaced with a seqlock /
rcu mechanism so we can determine that a bo is idle under a
rcu / read seqlock.
However this change will allow us to batch fencing and unreserving of
buffers with a minimal amount of locking.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add an aid for the driver to detect deadlocks on multi-bo reservations
Update documentation.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Avoid the ttm_bo_unreserve() spinlocks by calling
ttm_eu_backoff_reservation_locked under the lru spinlock.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Makes it possible to reserve a list of buffer objects with a single
spin lock / unlock if there is no contention.
Should improve cpu usage on SMP kernels.
v2: Initialize private list members on reserve and don't call
ttm_bo_list_ref_sub() with zero put_count.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I had removed this when I switched the atom indirect io methods
to use the io bar rather than the mmio bar, but it appears it's
still needed.
Reported-by: Mark Lord <kernel@teksavvy.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the vblank irq handler, calls to actual vblank handling,
or at least drm_handle_vblank(), need to happen before
calls to radeon_crtc_handle_flip().
Reason: The high precision pageflip timestamping
and some other pageflip optimizations will need the updated
vblank count and timestamps for the current vblank interval.
These are calculated in drm_handle_vblank(), therefore it
must go first.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds support for dri2 pageflipping.
v2: precision updates from Mario Kleiner.
v3: Multihead fixes from Mario Kleiner; missing crtc offset
add note about update pending bit on pre-avivo chips
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch adds new functions for use by the drm core:
.get_vblank_timestamp() provides a precise timestamp
for the end of the most recent (or current) vblank
interval of a given crtc, as needed for the DRI2
implementation of the OML_sync_control extension.
It is a thin wrapper around the drm function
drm_calc_vbltimestamp_from_scanoutpos() which does
almost all the work and is shared across drivers.
.get_scanout_position() provides the current horizontal
and vertical video scanout position and "in vblank"
status of a given crtc, as needed by the drm for use by
drm_calc_vbltimestamp_from_scanoutpos().
The function is also used by the dynamic gpu reclocking
code to determine when it is safe to reclock inside vblank.
For that purpose radeon_pm_in_vbl() is modified to
accomodate a small change in the function prototype of
the radeon_get_crtc_scanoutpos() which is hooked up to
.get_scanout_position().
This code has been tested on AVIVO hardware, a RV530
(ATI Mobility Radeon X1600) in a Intel Core-2 Duo MacBookPro
and some R600 variant (FireGL V7600) in a single cpu
AMD Athlon 64 PC.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DRI2 swap & sync implementation needs precise
vblank counts and precise timestamps corresponding
to those vblank counts. For conformance to the OpenML
OML_sync_control extension specification the DRM
timestamp associated with a vblank count should
correspond to the start of video scanout of the first
scanline of the video frame following the vblank
interval for that vblank count.
Therefore we need to carry around precise timestamps
for vblanks. Currently the DRM and KMS drivers generate
timestamps ad-hoc via do_gettimeofday() in some
places. The resulting timestamps are sometimes not
very precise due to interrupt handling delays, they
don't conform to OML_sync_control and some are wrong,
as they aren't taken synchronized to the vblank.
This patch implements support inside the drm core
for precise and robust timestamping. It consists
of the following interrelated pieces.
1. Vblank timestamp caching:
A per-crtc ringbuffer stores the most recent vblank
timestamps corresponding to vblank counts.
The ringbuffer can be read out lock-free via the
accessor function:
struct timeval timestamp;
vblankcount = drm_vblank_count_and_time(dev, crtcid, ×tamp).
The function returns the current vblank count and
the corresponding timestamp for start of video
scanout following the vblank interval. It can be
used anywhere between enclosing drm_vblank_get(dev, crtcid)
and drm_vblank_put(dev,crtcid) statements. It is used
inside the drmWaitVblank ioctl and in the vblank event
queueing and handling. It should be used by kms drivers for
timestamping of bufferswap completion.
The timestamp ringbuffer is reinitialized each time
vblank irq's get reenabled in drm_vblank_get()/
drm_update_vblank_count(). It is invalidated when
vblank irq's get disabled.
The ringbuffer is updated inside drm_handle_vblank()
at each vblank irq.
2. Calculation of precise vblank timestamps:
drm_get_last_vbltimestamp() is used to compute the
timestamp for the end of the most recent vblank (if
inside active scanout), or the expected end of the
current vblank interval (if called inside a vblank
interval). The function calls into a new optional kms
driver entry point dev->driver->get_vblank_timestamp()
which is supposed to provide the precise timestamp.
If a kms driver doesn't implement the entry point or
if the call fails, a simple do_gettimeofday() timestamp
is returned as crude approximation of the true vblank time.
A new drm module parameter drm.timestamp_precision_usec
allows to disable high precision timestamps (if set to
zero) or to specify the maximum acceptable error in
the timestamps in microseconds.
Kms drivers could implement their get_vblank_timestamp()
function in a gpu specific way, as long as returned
timestamps conform to OML_sync_control, e.g., by use
of gpu specific hardware timestamps.
Optionally, kms drivers can simply wrap and use the new
utility function drm_calc_vbltimestamp_from_scanoutpos().
This function calls a new optional kms driver function
dev->driver->get_scanout_position() which returns the
current horizontal and vertical video scanout position
of the crtc. The scanout position together with the
drm_display_timing of the current video mode is used
to calculate elapsed time relative to start of active scanout
for the current video frame. This elapsed time is subtracted
from the current do_gettimeofday() time to get the timestamp
corresponding to start of video scanout. Currently
non-interlaced, non-doublescan video modes, with or
without panel scaling are handled correctly. Interlaced/
doublescan modes are tbd in a future patch.
3. Filtering of redundant vblank irq's and removal of
some race-conditions in the vblank irq enable/disable path:
Some gpu's (e.g., Radeon R500/R600) send spurious vblank
irq's outside the vblank if vblank irq's get reenabled.
These get detected by use of the vblank timestamps and
filtered out to avoid miscounting of vblanks.
Some race-conditions between the vblank irq enable/disable
functions, the vblank irq handler and the gpu itself (updating
its hardware vblank counter in the "wrong" moment) are
fixed inside vblank_disable_and_save() and
drm_update_vblank_count() by use of the vblank timestamps and
a new spinlock dev->vblank_time_lock.
The time until vblank irq disable is now configurable via
a new drm module parameter drm.vblankoffdelay to allow
experimentation with timeouts that are much shorter than
the current 5 seconds and should allow longer vblank off
periods for better power savings.
Followup patches will use these new functions to
implement precise timestamping for the intel and radeon
kms drivers.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Under KMS, restoring the cursor is handled upon modeswitch in order to
avoid enabling an undefined set of registers. At the moment, the cursor
is restored before the aperture and modes are fully setup causing some
invalid access during resume, such as:
PGTBL_ER: 0x00040000
Invalid GTT entry during Cursor Fetch
Fix this by only performing cursor register save/restore under UMS where
it is done in the correct sequence.
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Commit 2549d6c2 removed the vmalloc used for temporary storage of the
relocation lists used during execbuffer. However, our use of vmalloc was
being protected by an integer overflow check which we do want to
preserve!
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
drm/i915: Disable FBC on Ironlake to save 1W
drm/i915: Take advantage of auto-polling CRT hotplug detection on PCH hardware
drm/i915/crt: Introduce struct intel_crt
drm/i915: Do not hold mutex when faulting in user addresses
drm: radeon: fix error value sign
drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx
drm/i915: Retire any pending operations on the old scanout when switching
drm/i915: Fix I2C adapter registration
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (40 commits)
drm/radeon/kms: i2c s/sprintf/snprintf/g for safety
drm/radeon/kms: fix i2c pad masks on rs4xx
drm/ttm: Fix up a theoretical deadlock
drm/radeon/kms: fix tiling info on evergreen
drm/radeon/kms: fix alignment when allocating buffers
drm/vmwgfx: Fix up an error path during bo creation
drm/radeon/kms: register an i2c adapter name for the dp aux bus
drm/radeon/kms/atom: add proper external encoders support
drm/radeon/kms/atom: cleanup and unify DVO handling
drm/radeon/kms: properly power up/down the eDP panel as needed (v4)
drm/radeon/kms/atom: set sane defaults in atombios_get_encoder_mode()
drm/radeon/kms: turn the backlight off explicitly for dpms
drm/radeon/kms: fix typo in r600 cs checker
drm: radeon: fix error value sign
drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx
nouveau: Acknowledge HPD irq in handler, not bottom half
drm/nouveau: Fix a few confusions between "chipset" and "card_type".
drm/nouveau: don't expose backlight control when available through ACPI
drm/nouveau/pm: improve memtiming mappings
drm/nouveau: Make PCIE GART size depend on the available RAMIN space.
...
Frame buffer compression is broken on Ironlake due to buggy hardware.
Currently it is disabled through chicken bits, but it still consumes
over 1W more than if we simply never attempt to enable the FBC code
paths.
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Both IBX and CPT have an automatic hotplug detection mode which appears to work reliably enough
that we can dispense with the manual force hotplug trigger stuff. This means that
hotplug detection is as simple as reading the current hotplug register values.
The first time the hotplug detection is activated, the code synchronously waits for a hotplug
sequence in case the hardware hasn't bothered to do a detection cycle since being initialized.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We will use this structure in future patches to store CRT specific
information on the encoder.
Split out and tweaked from a patch by Keith Packard.
Signed-off-by: Keith Packard <keithp@kithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Linus Torvalds found that it was rather trivial to trigger a system
freeze:
In fact, with lockdep, I don't even need to do the sysrq-d thing: it
shows the bug as it happens. It's the X server taking the same lock
recursively.
Here's the problem:
=============================================
[ INFO: possible recursive locking detected ]
2.6.37-rc2-00012-gbdbd01a #7
---------------------------------------------
Xorg/2816 is trying to acquire lock:
(&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c626c>] i915_gem_fault+0x50/0x17e
but task is already holding lock:
(&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
other info that might help us debug this:
2 locks held by Xorg/2816:
#0: (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
#1: (&mm->mmap_sem){++++++}, at: [<ffffffff81022d4f>] page_fault+0x156/0x37b
This recursion was introduced by rearranging the locking to avoid the
double locking on the fast path (4f27b5d and fbd5a26d) and the
introduction of the prefault to encourage the fast paths (b5e4f2b). In
order to undo the problem, we rearrange the code to perform the access
validation upfront, attempt to prefault and then fight for control of the
mutex. the best case scenario where the mutex is uncontended the
prefaulting is not wasted.
Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As per advice from Jean Delvare.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A process suspended waiting for a higher sequence or no sequence to unreserve,
a bo may be beaten to the reservation by a process with a lower sequence.
In that case the first process should give up trying to reserve and
return -EAGAIN. In order for that to happen, we must wake waiting processes
when we change sequence, so that they have a chance to detect the new
sequence.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next: (25 commits)
nouveau: Acknowledge HPD irq in handler, not bottom half
drm/nouveau: Fix a few confusions between "chipset" and "card_type".
drm/nouveau: don't expose backlight control when available through ACPI
drm/nouveau/pm: improve memtiming mappings
drm/nouveau: Make PCIE GART size depend on the available RAMIN space.
drm/nouveau: Return error from nouveau_gpuobj_new if we're out of RAMIN.
drm/nouveau: Fix compilation issues in nouveau_pm when CONFIG_HWMON is not set
drm/nouveau: Don't use load detection for connector polling.
drm/nv10-nv20: Fix instability after MPLL changes.
drm/nv50: implement possible workaround for NV86 PGRAPH TLB flush hang
drm/nouveau: Don't poll LVDS outputs.
drm/nouveau: Use "force" to decide if analog load detection is ok or not.
drm/nv04: Fix scanout over the 16MB mark.
drm/nouveau: fix nv40 pcie gart size
drm/nva3: fix overflow in fixed point math used for pll calculation
drm/nv10: Balance RTs expected to be accessed simultaneously by the 3d engine.
drm/nouveau: Expose some BO usage flags to userspace.
drm/nouveau: Reduce severity of the unknown getparam error.
drm/nouveau: Avoid lock dependency between ramht and ramin spinlocks.
drm/nouveau: Some random cleanups.
...
We aren't currently using tiling in userspace on evergreen,
but the info we currently return for the tiling info query
(gb_addr_config) is no adequate for userspace tiling alignment
calculations. It does not contain the bank info. Create a custom
tiling info dword with all the necessary info (num channels,
num banks, group size, row size).
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were previously dropping alignment requests on the floor
when allocating buffers so we always ended up page aligned.
Certain tiling modes on 6xx+ require larger alignment which
wasn't happening before.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This causes the connector to not be added since i2c init fails
for the adapter. Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=31688
Noticed by Ari Savolainen.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Ari Savolainen <ari.m.savolainen@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are external encoder chips connected via DVO or DP.
The actual external encoder programming is handled by the
kms encoder functions for primary encoder.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Handle all the various asic family specific things for DVO.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The eDP panel must be powered up for aux transactions, so power it
up for detect and mode probe functions, otherwise power it up or
down based on dpms.
v2:
- only mess with eDP panel on DCE4+
- only mess with eDP panel on eDP connectors, not all DP connectors
v3:
- be extra careful to only mess with eDP panels on eDP connectors
v4:
- avoid possible null derefernce if a connector has not been
assigned to the encoder
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If there was no connector mapped to the encoder, atombios_get_encoder_mode()
returned 0 which is the id for DP. Return something sane instead based on
the encoder id. This avoids hitting the DP paths on non-DP encoders.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Looks like a typo in:
drm/radeon/r600: fix tiling issues in CS checker.
(f30df2fad0)
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
enable_vblank implementations should use negative result to indicate error.
radeon_enable_vblank() returns EINVAL in this case. Change this to -EINVAL.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tiled buffers have the same alignment requirements regardless of
whether the surface is for db, cb, or textures. Previously, the
calculations where inconsistent for each buffer type.
- Unify the alignment calculations in a common function
- Standardize the alignment units (pixels for pitch/height/depth,
bytes for base)
- properly check the buffer base alignments
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The old code generated an interrupt storm bad enough to completely
take down my system.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Avoid confusing userspace by not publishing backlight controls if ACPI
equivalents are available.
Reported-by: Aaron Sowry <aaron@aeneby.se>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Improvements:
- Fix bug in switch statement
- Add parts of 0x10022c, 0x10023c
- Clean up 0x100234
- Comment out assumption in 0x100228 until verified
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reported-by: Tomas Miljenovic <tomasmiljenovic@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reported-by: Tomas Miljenovic <tomasmiljenovic@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Analog output polling makes GL programs jerky when pageflip is being
used because it's carried out with the mode_config mutex held.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Nouveau sets the PCIE GART size to 64MiB for all cards before nv50,
but nv40 has enough RAMIN space to support 512MiB GART size. This
patch fixes this value to make use of this hardware capability.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This will be needed for Z compression and to take smarter placement
decisions.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The ramht code called some gpuobj functions with the HARDIRQ-safe
RAMHT spinlock held, this could potentially lead to a dead lock
because ramin_lock is HARDIRQ-unsafe.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Remove some unused/duplicated definitions and make sparse happy again.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This allows the user to set a mode larger than the native one, useful
if we had trouble finding the actual native mode (e.g. because it goes
above the hardware bandwidth limits).
Reported-by: Grzesiek Sójka <pld@pfu.pl>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There are two messages in the ISR of nouveau which might be printed out
hundred times in a second. Ratelimit them. (We need to move
nouveau_ratelimit to the top of the file.)
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The big kernel lock has been removed from all these files at some point,
leaving only the #include.
Remove this too as a cleanup.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
backlight_device_register has been expecting a const "ops" argument, and using
it as such, since 9905a43b2d. Let's make the
remaining backlight_ops instances const.
Inspired by hunks of the grsecurity patch, updated for newer kernels.
Signed-off-by: Lionel Debroux <lionel_debroux@yahoo.fr>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
As we may bind an object with the correct alignment, but with an invalid
size, it may pass the current checks on whether the object may be reused
with a fence.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
g33/pineview doesn't have any alignment constrains for unfenced tiled
buffers. But older chips have. Fix this.
Problem introduced in a00b10c360.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
enable_vblank implementations should use negative result to indicate error.
radeon_enable_vblank() returns EINVAL in this case. Change this to -EINVAL.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tiled buffers have the same alignment requirements regardless of
whether the surface is for db, cb, or textures. Previously, the
calculations where inconsistent for each buffer type.
- Unify the alignment calculations in a common function
- Standardize the alignment units (pixels for pitch/height/depth,
bytes for base)
- properly check the buffer base alignments
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
An old and oft reported bug, is that of the GPU hanging on a
MI_WAIT_FOR_EVENT following a mode switch. The cause is that the GPU is
waiting on a scanline counter on an inactive pipe, and so waits for a
very long time until eventually the user reboots his machine.
We can prevent this either by moving the WAIT into the kernel and
thereby incurring considerable cost on every swapbuffers, or by waiting
for the GPU to retire the last batch that accesses the framebuffer
before installing a new one. As mode switches are much rarer than swap
buffers, this looks like an easy choice.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28964
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29252
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
We only ever used the PRB0, neglecting the secondary ring buffers, and
now with the advent of multiple engines with separate ring buffers we
need to excise the anachronisms from our code (and be explicit about
which ring we mean where). This is doubly important in light of the
FORCEWAKE required to read ring buffer registers on SandyBridge.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before reading ring register, set FORCE_WAKE bit to prevent GT core
power down to low power state, otherwise we may read stale values.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
[ickle: added a udelay which seemed to do the trick on my SNB]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We use i915_gem_object_get_fence_reg() to do LRU tracking of the fence
registers, so stop trying to be too clever when pinning the fb->obj.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Call destroy() on _all_ ttm_bo_init() failures, and make sure that
behavior is documented in the function description.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If ttm_bo_init() returns failure, it already destroyed the BO, so we need to
retry from scratch.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix many small bugs in I2C adapter registration:
* Properly reject unsupported GPIO pin.
* Fix improper use of I2C_NAME_SIZE (which is the size of
i2c_client.name, not i2c_adapter.name.)
* Prefix adapter names with "i915" so that the user knows what the
I2C channel is connected to.
* Fix swapped characters in the string used to name the GPIO-based
adapter.
* Add missing comma in gmbus name table.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Temperature is not shifted as on newer asics.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a follow on to:
2b5b1d7da9583484b3a9e7e375a90ca0e8ca07c2
(drm/radeon/kms: add support for clock/data path routers)
That patch completed mux support for ddc and cd line routing
between connectors. This patch fixes an indexing typo that was
resulting in the atom bios router objects not always being walked,
ensures the validity entries for the reused router structure are
reset for every connector object walked, and corrects the masking
operations used to update the mux control bits.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=31339
Signed-off-by: Tyson Whitehead <twhitehead@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a follow on to:
26b5bc9864
(drm/radeon/kms: add support for router objects)
That patch added support for systems that use a mux to control
the ddc line routing between the connectors. This patch adds
support for systems that use a mux to control the encoder
clock and data path routing to the connectors.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=31339
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Structure drm_vmw_fence_rep is copied to userland with field "pad64"
uninitialized. It leads to leaking of contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When bo pin failed during modesetting,
vmwgfx would try to unref a non-existing buffer object.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This breaks vmwgfx non-root EGL clients and is a remnant from the
TTM user-space interface. This test should be done in the driver.
Replace the remaining placement test with a BUG_ON, since triggering
it is a driver bug.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The sync object may disappear as soon as we release the bo::lock, so
take a reference on it while we use it.
One option would be to call sync_object_flush() before releasing the bo::lock,
but that would put an atomic requirement on that function.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The A/B links aren't independantly useable on these blocks so when
we disable the encoders, make sure to only disable the encoder when
there is no connector using it.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=18564
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently an invalid EDID extension will cause the whole EDID to be considered invalid. Instead just drop the invalid extensions, and return the valid ones. The base block is modified to claim to have the number valid extensions, and the check sum is updated.
For my EIZO S2242W the base block is fine, but the extension block is all zeros. Without this patch I get no X and no VTs.
Signed-off-by: Sam Tygier <samtygier@yahoo.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make more of the connector code debug only to avoid
spamming the kernel logs with detect and add modes
messages.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The driver (for example vmwgfx) may want to silently deal with the
error itself.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since we're doing this outside of a spinlock to provide the necessary
barriers, add an explicit barrier.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Replace with BUG_ON(). These error messages remained from the time
when TTM was initialized from user-space. Nowadays hitting one of those
is really a kernel bug.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Searching for a free block in the range manager may in some situations be a
lenghty operation, and we want to avoid holding the global lru lock
during that time. Instead use a per-manager spinlock.
This leaves the global lru lock for quick lru list and swap list manipulation
only, including list manipulation associated with reserving buffer objects.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove an obsolete comment about mm nodes.
Document the new bo range manager interface.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* Dave Airlie <airlied@linux.ie> wrote:
> > Lee, Chun-Yi (1):
> > gpu: Add Intel GMA500(Poulsbo) Stub Driver
Today's -tip fails to build due to upstream commit e26fd11 ("gpu: Add Intel
GMA500(Poulsbo) Stub Driver"), committed two days ago and merged yesterday, on
x86 allmodconfig with BACKLIGHT_CLASS_DEVICE disabled:
drivers/built-in.o: In function `acpi_video_bus_put_one_device':
video.c:(.text+0x7d26f): undefined reference to `backlight_device_unregister'
drivers/built-in.o: In function `acpi_video_switch_brightness':
video.c:(.text+0x7d6f5): undefined reference to `backlight_force_update'
drivers/built-in.o: In function `acpi_video_device_find_cap':
video.c:(.text+0x7dfdb): undefined reference to `backlight_device_register'
drivers/gpu/stub/Kconfig selects ACPI_VIDEO, but ACPI_VIDEO is a complex interactive
Kconfig option with a lot of dependencies:
config ACPI_VIDEO
tristate "Video"
depends on X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL
depends on INPUT
select THERMAL
help
This driver implements the ACPI Extensions For Display Adapters
and if any of its dependencies are not met, we get a build failure. This problem was
apparently realized in the driver at a certain stage:
config STUB_POULSBO
tristate "Intel GMA500 Stub Driver"
depends on PCI
# Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select ACPI_VIDEO if ACPI
but not fully understood and not fully fixed.
As a quick fix select these secondary dependencies, like drivers/gpu/drm/Kconfig
does:
config DRM_I915
tristate "i915 driver"
depends on AGP_INTEL
select SHMEM
select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select VIDEO_OUTPUT_CONTROL if ACPI
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
help
Choose this option if you have a system that has Intel 830M, 845G,
852GM, 855GM 865G or 915G integrated graphics. If M is selected, the
But it's arguably not particularly nice looking, so maybe this area of code is ripe
for a Kconfig restructuring/cleanup.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
drm/i915: Fix LVDS fixed-mode regression from 219adae1
drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism
drm/i915: Avoid might_fault during pwrite whilst holding our mutex
agp/intel: fix cache control for sandybridge
agp/intel: restore cache behavior on sandybridge
drm/i915; Don't apply Ironlake FDI clock workaround to Sandybridge
drm/i915: Fix KMS regression on Sandybridge/CPT
i915: reprogram power monitoring registers on resume
drm/i915: SNB BLT workaround
drm/i915: Fix the graphics frequency clamping at init and when IPS is active.
drm/i915: Allow powersave modparam to be adjusted at runtime.
drm/i915: Apply big hammer to serialise buffer access between rings
drm/i915: opregion_setup: iounmap correct address
drm/i915: Flush read-only buffers from the active list upon idle as well
i915: signedness bug in check_overlay_src()
drm/i915: Fix typo from "Enable DisplayPort Audio"
Commit 219adae1 cached the EDID found during LVDS init, but in the
process prevented the init routine from discovering the preferred
fixed-mode for the panel. This was causing us to guess the correct mode,
which sometimes is wide of the mark.
Reported-and-tested-by: Jon Masters <jonathan@jonmasters.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If modeset init failed we attempted to unload the module, before we
finished setting it up and so triggered various oopses.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we use POSTING_READ to flush the write to the register before
proceeding, we do not care what the return value is and similar we do
not care for the read to be recorded whilst tracing register
read/writes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These registers are written very frequently, are timing sensitive, and
not particularly relevant to any debugging, so remove the tracepoints
from these.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This will be used later to hide the frequently written registers
from debug traces in order to increase the signal-to-noise.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add two tracepoints at I915_WRITE/READ for tracing down all the
register write and read.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.
Cherry-picked from 6aa56062ea.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31404
Tested-by: Zhao Jian <jian.j.zhao@intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is not known to fix any particular bugs we have, but the spec
says to do it, and the BIOS hadn't already set it up on my system.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... and so prevent a potential circular reference:
[ INFO: possible circular locking dependency detected ]
2.6.37-rc1-uwe1+ #4
-------------------------------------------------------
Xorg/1401 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<c01e4ddb>] might_fault+0x4b/0xa0
but task is already holding lock:
(&dev->struct_mutex){+.+.+.}, at: [<f869c3ac>]
i915_mutex_lock_interruptible+0x3c/0x60 [i915]
which lock already depends on the new lock.
When the locking around the pwrite ioctl was simplified, I did not spot
that the phys path never took any locks and so we introduced this
potential circular reference.
Reported-by: Uwe Helm <uwe.helm@googlemail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The ring buffer registers return 0 whilst idle (for some values of idle)
on early Sandybridge hw. Persevere even when all appears hopeless...
Fortunately the head auto-reporting prevents most hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31370
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Instead of killing the process, just return no page found and reschedule
the process giving the GPU some time to (hopefully) recover.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
a00b10c360 "Only enforce fence limits inside the GTT" also
added a fenceable/mappable disdinction when binding/pinning buffers.
This only complicates the code with no pratical gain:
- In execbuffer this matters on for g33/pineview, as this is the only
chip that needs fences and has an unmappable gtt area. But fences
are only possible in the mappable part of the gtt, so need_fence
implies need_mappable. And need_mappable is only set independantly
with relocations which implies (for sane userspace) that the buffer
is untiled.
- The overlay code is only really used on i8xx, which doesn't have
unmappable gtt. And it doesn't support tiled buffers, currently.
- For all other buffers it's a bug to pass in a tiled bo.
In short, this disdinction doesn't have any practical gain.
I've also reverted mapping the overlay and context pages as possibly
unmappable. It's not worth being overtly clever here, all the big
gains from unmappable are for execbuf bos.
Also add a comment for a clever optimization that confused me
while reading the original patch by Chris Wilson.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In a00b10c360 "Only enforce fence limits inside the GTT"
Chris Wilson implemented an optimization to only pin framebuffers
as mappable for crtc_set_base (but not for pageflips). This breaks
the abi, eg: A double buffering mesa client might leave the last
framebuffer in unmappable space on close. A subsequent glReadPix
by a frontbuffer rendering client then goes boom. My pretty anal
mappable/unmappable consistency checking detected this, see
https://bugs.freedesktop.org/show_bug.cgi?id=31286
Chris Wilson tried to fix this in 085ce26437 by pinning
tiled framebuffers into mappable space. This
a) renders the original optimization of not forcing framebuffers
for pageflipping clients into mappable pointless because all our
scanout buffers are tiled by default.
b) doesn't solve the problem for untiled framebuffers.
So kill this. Emperically it's no gain anyway because framebuffers are
being reused by the ddx and hence there's no chance for them to get
constanly bounced between mappable and unmappable.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We should enable FDI normal training on Sandybridge/CPT system
as well.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[ickle: removed unrelated chunks]
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes issue where i915_gfx_val was reporting values several
orders of magnitude higher than physically possible (without
leaving scorch marks on my thighs at least.)
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When merging Daniel's full-gtt patches I had a set of tweaks which I
thought I had undone. I was half right...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31286
Reported-by: jinjin.wang@intel.com
Reported-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I presumed that we would be writing to the batch through the GTT having
bound it, so I converted it to use iomem. Even later as I spotted that
we didn't even move the batch to the GTT (now an issue since we default
to uncached memory on SNB) I still didn't realise that using iomem for
kmapped memory was incorrect. Fix it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Immediate merge to resolve conflicts from applying a stability fix to
both branches.
Conflicts:
drivers/gpu/drm/i915/intel_ringbuffer.c
drivers/gpu/drm/i915/intel_ringbuffer.h
On some stepping of SNB cpu, the first command to be parsed in BLT
command streamer should be MI_BATCHBUFFER_START otherwise the GPU
may hang.
(cherry picked from commit 8d19215be8)
Conflicts:
drivers/gpu/drm/i915/intel_ringbuffer.c
drivers/gpu/drm/i915/intel_ringbuffer.h
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On some stepping of SNB cpu, the first command to be parsed in BLT
command streamer should be MI_BATCHBUFFER_START otherwise the GPU
may hang.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
[ickle: rebased for -next]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Part of the issue here was that Eric slipped in a debug hack for
testing the i915 IPS code before the intel_ips.c driver had landed.
This caused the driver to always use the full range of frequencies,
which is only legal when IPS tells us we have the headroom. Once that
hack was removed, there was confusion about the driver's frequency
clamping variables: max_delay is the driver's current limit on the
highest frequency the IPS driver wants us to use, while dev_priv->fmax
is the hardware-reported limit that the IPS driver can increase up to.
Tested with IPS driver loaded or not. Note that on Ironlake systems
without the IPS driver loaded this will result in a performance
reduction, and the inital warmup of frequency limits can impact
benchmarking on systems with IPS loaded.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
[ickle: demoted a debugging printk]
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2.6.36 appears to respect the 0400 mode we assigned to the parameter
preventing it from being adjusted after loading. However, this is safe
to adjust at runtime.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31311
Reported-by: Fernando Lemos <fernandotcl@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case of an opregion signature mismatch in intel_opregion_setup(),
iounmap the correct address.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Take two passes to evict everything whilst searching for sufficient free
space to bind the batchbuffer. After searching for sufficient free space
using LRU eviction, evict everything that is purgeable and try again.
Only then if there is insufficient free space (or the GTT is too badly
fragmented) evict everything from the aperture and try one last time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Accessing the uninitialised obj->pages instead of the local page lead to
an OOPs.
Reported-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After switching the MMIO registers to use pci_iomap, remember to dispose
of the mapping with pci_iounmap (for symmetry).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So long as we adhere to the fence registers rules for alignment and no
overlaps (including with unfenced accesses to linear memory) and account
for the tiled access in our size allocation, we do not have to allocate
the full fenced region for the object. This allows us to fight the bloat
tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside
the GTT we still suffer the additional alignment constraints, so it doesn't
magic allow us to render larger scenes without stalls -- we need the
expanded GTT and fence pipelining to overcome those...]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Also spotted by Dan Carpenter.
obj->pin_count is unsigned so the BUG_ON(obj->pin_count<0) will never
trigger.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The error code is only expected during the actual pruning and not during
the first measurement (nr_to_scan == 0) pass.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is possible for the active list to only contain a read-only buffer so
that the ring->gpu_write_list remains entry. This leads to an
inconsistency between i915_gpu_is_active() and i915_gpu_idle() causing
an infinite spin during the shrinker and an assertion failure that
i915_gpu_idle() does indeed flush all buffers from the active lists.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to force a page-fault on a GTT mapping after we start using it
from the GPU and so enforce correct CPU/GPU synchronisation, we need to
invalidate the mapping.
Pointed out by Owain G. Ainsworth.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By using read_cache_page() for individual pages during pwrite/pread we
can eliminate an unnecessary large allocation (and immediate free) of
obj->pages. Also this eliminates any potential nesting of get/put pages,
simplifying the code and preparing the path for greater things.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we rarely use the mmap_offset and it is easily computable from the
obj->map_list.hash, remove it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Eliminate the racy device unload by embedding a shrinker into each
device. Smaller, simpler code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Play safe and use the common routines which take care of the cachability
of the memory when setting up the iomapping for the PCI registers.
Whilst they should be cacheable for the current generations, actually
honouring what the device requires is a better long term strategy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms: enable unmappable vram for evergreen
drm/radeon/kms: fix tiled db height calculation on 6xx/7xx
drm/radeon/kms: fix handling of tex lookup disable in cs checker on r2xx
Evergreen now has blit support, but unmappable vram support
was disabled in c919b371cb
(drm/radeon/kms: avoid corner case issue with unmappable vram V2)
due to merge ordering. This re-enables unmappable vram on
evergreen.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Calculate height based on the slice bitfield rather than the size.
Same as Dave's CB fix.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There are cases when multiple texture units have to be enabled,
but not actually used to sample. This patch checks to see if
the lookup_disable bit is set and if so, skips the texture check.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=25544
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This holds error state from the main graphics arbiter mainly involving
the DMA engine and address translation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is the same value as before, but it just makes the code slightly
more readable to use the local variable than converting the aperture
size into bytes every time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
More precisely: For those that _need_ to be mappable. Also add two
BUG_ONs in fault and pin to check the consistency of the mappable
flag.
Changes in v2:
- Add tracking of gtt mappable space (to notice mappable/unmappable
balancing issues).
- Improve the mappable working set tracking by tracking fault and pin
separately.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This way we can make some more educated guesses as to why exactly
we can't use 2G apertures to their full potential ;)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
At least the part that's currently enabled by the BIOS.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In i915_gem_object_pin obviously unbind only if mappable is true.
This is the last part to enable gtt_mappable_end != gtt_size, which
the next patch will do.
v2: Fences on g33/pineview only work in the mappable part of the
gtt.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Like before add a parameter mappable (also to gem_object_pin) and
set it depending upon the context. Only bos that are brought into
the gtt due to an execbuffer call can be put into the unmappable
part of the gtt, everything else (especially pinned objects) need
to be put into the mappable part of the gtt.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add a mappable parameter to i915_gem_evict_something to distinguish
the two cases (non-restricted vs. mappable gtt allocations). No
functional changes because the mappable limit is set to the end of
the gtt currently.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently, we believe the GPU is idle if just the RENDER ring is idle.
This is obviously wrong if we only using either the BLT or the BSD
rings and so masking genuine hangs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Preparing the ringbuffer for adding new commands can fail (a timeout
whilst waiting for the GPU to catch up and free some space). So check
for any potential error before overwriting HEAD with new commands, and
propagate that error back to the user where possible.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
"depth" should be signed in case packed_depth_bytes() returns -EINVAL.
This probably doesn't make a difference at runtime. In the original
code we would return -EINVAL later if (rec->offset_Y % 4294967274) is
non-zero.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The ringbuffer keeps a pointer to the parent device, so we can use that
instead of passing around the pointer on the stack.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hi,
while I looked through your changes in drm-intel git tree (as I've got
a pressure for supporting DisplayPort audio), I stumbled on the
possible bug in the commit a9756bb5b2
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Sun Sep 19 13:09:06 2010 +0800
drm/i915: Enable DisplayPort audio
In this commit, you changed the return value of g4x_dp_detect()
to "bit", but it should be "status", I suppose.
[ickle: mea culpa.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31094
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (476 commits)
vmwgfx: Implement a proper GMR eviction mechanism
drm/radeon/kms: fix r6xx/7xx 1D tiling CS checker v2
drm/radeon/kms: properly compute group_size on 6xx/7xx
drm/radeon/kms: fix 2D tile height alignment in the r600 CS checker
drm/radeon/kms/evergreen: set the clear state to the blit state
drm/radeon/kms: don't poll dac load detect.
gpu: Add Intel GMA500(Poulsbo) Stub Driver
drm/radeon/kms: MC vram map needs to be >= pci aperture size
drm/radeon/kms: implement display watermark support for evergreen
drm/radeon/kms/evergreen: add some additional safe regs v2
drm/radeon/r600: fix tiling issues in CS checker.
drm/i915: Move gpu_write_list to per-ring
drm/i915: Invalidate the to-ring, flush the old-ring when updating domains
drm/i915/ringbuffer: Write the value passed in to the tail register
agp/intel: Restore valid PTE bit for Sandybridge after bdd3072
drm/i915: Fix flushing regression from 9af90d19f
drm/i915/sdvo: Remove unused encoding member
i915: enable AVI infoframe for intel_hdmi.c [v4]
drm/i915: Fix current fb blocking for page flip
drm/i915: IS_IRONLAKE is synonymous with gen == 5
...
Fix up conflicts in
- drivers/gpu/drm/i915/{i915_gem.c, i915/intel_overlay.c}: due to the
new simplified stack-based kmap_atomic() interface
- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: added .llseek entry due to BKL
removal cleanups.
Use Ben's new range manager hooks to implement a manager for
GMRs that manages ids rather than ranges.
This means we can use the standard TTM code for binding, unbinding and
eviction.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
broken by:
drm/radeon/r600: fix tiling issues in CS checker.
v2: only apply it to 1D tiling case.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Keep the current interface but ignore the KM_type and use a stack based
approach.
The advantage is that we get rid of crappy code like:
#define __KM_PTE \
(in_nmi() ? KM_NMI_PTE : \
in_irq() ? KM_IRQ_PTE : \
KM_PTE0)
and in general can stop worrying about what context we're in and what kmap
slots might be appropriate for that.
The downside is that FRV kmap_atomic() gets more expensive.
For now we use a CPP trick suggested by Andrew:
#define kmap_atomic(page, args...) __kmap_atomic(page)
to avoid having to touch all kmap_atomic() users in a single patch.
[ not compiled on:
- mn10300: the arch doesn't actually build with highmem to begin with ]
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Miller <davem@davemloft.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
macro tile heights are aligned to num channels, not num banks.
Noticed by Dave Airlie.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The hw stores a default clear state for registers in the context
range that can be initialized when the CP is set up. Set the
blit state as the default clear state and use the CLEAR_STATE
packet to load the blit state rather than loading it from an IB.
This reduces overhead when doing bo moves using the 3D engine.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently, there have no GMA500(Poulsbo) native video driver to support
intel opregion. So, use this stub driver to enable the acpi backlight
control sysfs entry files by requrest acpi_video_register.
[airlied: fix warnings]
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The vram map in the radeon memory controller needs to be
>= the pci aperture size. Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=28402
The problematic cards in the above bug have 64 MB of vram,
but the pci aperture is 128 MB and the MC vram map was only
64 MB. This can lead to hangs.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Improper display watermarks can result in underflow to the display
controllers which can cause flickering or other artifacts.
This patch implements display watermark support and line buffer
allocation for evergreen asics.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are needed for enabling dynamic GPR allocation in the shaders
in the userspace acceleration drivers.
v2: fix typo in reg name
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The CS checker had some incorrect alignment requirements for 2D surfaces,
this made rendering to mipmap levels that were 2D broken.
Also the CB height was being worked out from the BO size, this doesn't work
at all when rendering mipmap levels, instead we work out what height userspace
wanted from slice max and use that to check it fits inside the BO, however
the DDX send the wrong slice max for an unaligned buffer so we have to workaround
for that even though its a userspace bug.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-next' of ../drm-next: (63 commits)
drm/i915: Move gpu_write_list to per-ring
drm/i915: Invalidate the to-ring, flush the old-ring when updating domains
drm/i915/ringbuffer: Write the value passed in to the tail register
agp/intel: Restore valid PTE bit for Sandybridge after bdd3072
drm/i915: Fix flushing regression from 9af90d19f
drm/i915/sdvo: Remove unused encoding member
i915: enable AVI infoframe for intel_hdmi.c [v4]
drm/i915: Fix current fb blocking for page flip
drm/i915: IS_IRONLAKE is synonymous with gen == 5
drm/i915: Enable SandyBridge blitter ring
drm/i915/ringbuffer: Remove broken intel_fill_struct()
drm/i915/ringbuffer: Fix emit batch buffer regression from 8187a2b
drm/i915: Copy the updated reloc->presumed_offset back to the user
drm/i915: Track objects in global active list (as well as per-ring)
drm/i915: Simplify most HAS_BSD() checks
drm/i915: cache the last object lookup during pin_and_relocate()
drm/i915: Do interrupible mutex lock first to avoid locking for unreference
drivers: gpu: drm: i915: Fix a typo.
agp/intel: Also add B43.1 to list of supported devices
drm/i915: rearrange mutex acquisition for pread
...
... to prevent flush processing of an idle (or even absent) ring.
This fixes a regression during suspend from 87acb0a5.
Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Tested-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These drivers don't use anything which is defined in <linux/i2c-id.h>.
This header file was never meant to be included directly anyway, and
will be deleted soon.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Ben Dooks <ben-linux@fluff.org>
Acked-by: Dave Airlie <airlied@linux.ie>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
When the object has been written to by the gpu it remains on the ring
until its flush has been retired. However, when the object is moving to
the ring and the associated cache needs to be invalidated, we need to
perform the flush on the target ring, not the one it came from (which is
NULL in the reported case and so the flush was entirely absent).
Reported-by: Peter Clifton <pcjc2@cam.ac.uk>
Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'llseek' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/bkl:
vfs: make no_llseek the default
vfs: don't use BKL in default_llseek
llseek: automatically add .llseek fop
libfs: use generic_file_llseek for simple_attr
mac80211: disallow seeks in minstrel debug code
lirc: make chardev nonseekable
viotape: use noop_llseek
raw: use explicit llseek file operations
ibmasmfs: use generic_file_llseek
spufs: use llseek in all file operations
arm/omap: use generic_file_llseek in iommu_debug
lkdtm: use generic_file_llseek in debugfs
net/wireless: use generic_file_llseek in debugfs
drm: use noop_llseek
* 'config' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/bkl:
BKL: introduce CONFIG_BKL.
dabusb: remove the BKL
sunrpc: remove the big kernel lock
init/main.c: remove BKL notations
blktrace: remove the big kernel lock
rtmutex-tester: make it build without BKL
dvb-core: kill the big kernel lock
dvb/bt8xx: kill the big kernel lock
tlclk: remove big kernel lock
fix rawctl compat ioctls breakage on amd64 and itanic
uml: kill big kernel lock
parisc: remove big kernel lock
cris: autoconvert trivial BKL users
alpha: kill big kernel lock
isapnp: BKL removal
s390/block: kill the big kernel lock
hpet: kill BKL, add compat_ioctl
This should fix the error along the reset path were we tried to clear the
tail register by setting it to 0, but were in fact setting it to the
current value and complaining when it did not reset to 0.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst moving the code around in 9af90d19f, I dropped the or'ing in of
new write domains which would zero out the write domain for a render
target if later reused as a source later in the batch. This meant that
we might drop a required flush before reading from the render target.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31043
Reported-by: xunx.fang@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This block is only used when detecting whether the connector is HDMI and
never again, so scope the variable to the detection routine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This patch enables the sending of AVI infoframes in
drivers/gpu/drm/i915/intel_hdmi.c.
My receiver currently loses sync when the HDMI output on my computer
(DG45FC motherboard) is switched from 800x600 (the BIOS resolution) to
1920x1080 as part of the boot. Fixable by switching inputs on the receiver
a couple of times.
With this patch, my receiver has not lost sync yet (> 40 tries).
Fourth version, now based on drm-intel-next from:
git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
Two questions still remain:
I'm assuming that the sdvo hardware also stores a header ECC byte in
the MSB of the first dword - is this correct?
Does the SDVOB and SDVOC handling in intel_hdmi_set_avi_infoframe()
look correct?
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Block execbuffer for the fb to be flipped away, not the one that is to
be flipped in.
[ickle: rewritten for -next]
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Based on an original patch by Zhenyu Wang, this initializes the BLT ring for
SandyBridge and enables support for user execbuffers.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... before someone tries to use it. The code both calls
intel_ring_begin/advance() and open-codes the bookkeeping performed by
those two functions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In commit 8187a2b, the number of dwords used in the ringbuffer for
executing the batch buffer was erroneously changed from 2 to 4.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With all the patches we have queued in the BKL removal tree, only a
few dozen modules are left that actually rely on the BKL, and even
there are lots of low-hanging fruit. We need to decide what to do
about them, this patch illustrates one of the options:
Every user of the BKL is marked as 'depends on BKL' in Kconfig,
and the CONFIG_BKL becomes a user-visible option. If it gets
disabled, no BKL using module can be built any more and the BKL
code itself is compiled out.
The one exception is file locking, which is practically always
enabled and does a 'select BKL' instead. This effectively forces
CONFIG_BKL to be enabled until we have solved the fs/lockd
mess and can apply the patch that removes the BKL from fs/locks.c.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This commit replaces the ttm_bo_cleanup_ref function with two new functions.
One for the case where the bo is not yet on the delayed destroy list, and
one for the case where the bo was on the delayed destroy list, at least at
the time of call. This makes it possible to optimize the two cases somewhat.
It also enables the possibility to directly destroy buffers on the
delayed delete list when they are about to be evicted or swapped out.
Currently they were only evicted / swapped and destruction was left for the
delayed buffer destruction thread.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the userspace driver is using a constant relocation array with a
static buffer, they will pass the same relocation array back to the
kernel. So we *do* need to update the presumed offset value in those
relocations to reflect the current object so that they remain correct
with future batchbuffers and we avoid the necessity of having to suspend
execution and perform redundant relocations.
Fixes the regression introduced by 12f889c for applications using
absolute addressing on trees of buffer (i.e. the current consumers of
libdrm_intel.so).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30996
Reported-by: Wang, Jinjin <jinjin.wang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To handle retirements, we need per-ring tracking of active objects.
To handle evictions, we need global tracking of active objects.
As we enable more rings, rebuilding the global list from the individual
per-ring lists quickly grows tiresome and overly complicated. Tracking the
active objects in two lists is the lesser of two evils.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... by always initialising the empty ringbuffer it is always then safe
to check whether it is active.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The most frequent relocation within a batchbuffer is a contiguous sequence
of vertex buffer relocations, for which we can virtually eliminate the
drm_gem_object_lookup() overhead by caching the last handle to object
translation.
In doing so we refactor the pin and relocate retry loop out of
do_execbuffer into its own helper function and so improve the error
paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One of the primarily consumers of the i915 driver is X, a large signal
driven application. Frequently when writing into the buffers, there is a
pending signal which causes us not to take the interruptible lock but
then we need to take that same lock around the object unreference. By
rearranging the code to do the interruptible lock as the first check, we
can avoid the frequent additional locking around the unreference.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... to avoid reacquiring it to drop the object reference count on
exit. Note we have to make sure we now drop (and reacquire) the lock
around acquiring the mm semaphore on the slow paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After allocation a handle for the fresh object, we know that we can
safely drop the refcnt without triggering a free so we do not need the
mutex. Strangely, this mutex acquisition is the one that appears on
driver profiles.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid an early eviction of the batch buffer into the uncached GTT
domain, and so do the relocation fixup in cacheable memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... perform an access validation check up front instead and copy them in
on-demand, during i915_gem_object_pin_and_relocate(). As around 20% of
the CPU overhead may be spent inside vmalloc for the relocation entries
when submitting an execbuffer [for x11perf -aa10text], the savings are
considerable and result in around a 10% throughput increase [for glyphs].
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rely on monitor's audio capability to turn on audio output for HDMI.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This will turn on DP audio output by checking monitor's audio
capability.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[ickle: rebase onto recent changes and rearranged for clarity]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The time between start of the pixel clock and backlight enable is a basic
panel timing constraint. If the Panel Power On/Off registers are found
to be 0, assume we are booting without VBIOS initialization and set these
registers to something reasonable.
Change-Id: Ibed6cc10d46bf52fd92e0beb25ae3525b5eef99d
Signed-off-by: Bryan Freed <bfreed@chromium.org>
[ickle: rearranged into a separate function to distinguish its role from
simply parsing the VBIOS tables.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If userspace is submitting so many long running batches that the ring
becomes full, throttle by sleeping for a 1ms before checking for free
space. Simply yielding was causing excessive scheduler overhead whilst
making no progress.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In i2c GPIO fallback, index 6 is reserved for nothing.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
FDI_PLL_BIOS_0 register is for Ironlake only, don't apply to
Sandybridge.
Original-patch-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the PLL may still be on, and the training pattern may not be
correct. Fixes suspend/resume on my PCH eDP test system.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: minor merge conflict and silence the compiler]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Freeing the Hardware Status Page was writing to the HWS register in
order to disable the GPU writing to the HWS page. Unfortunately, we were
writing to the mmio register after unmapping the register space, hence
the oops.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 6939a5aca7.
Daniel Vetter supplied a set of fixes for all the module unload bugs he
could trigger on his machines, so let the fun recommence!
The enter argument as implemented by commit 413d45d362 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.
There is no runtime behavior change as a result of this patch.
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever happened.
There is a short cut used by this patch where gamma_store is used as
the save space. If this turns out to be a problem in the future a
pre-allocated chunk of memory will be required for each crtc to save
and restore the LUT information.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit ff773714dd.
A generic solution is needed to save and retore the LUT information.
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Function ttm_bo_wait_unreserved can be slightly simplified.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need the unlocked variant for the new codepath introduced to fix the
race condition in master recently.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The patch below updates broken web addresses in the kernel
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Finn Thain <fthain@telegraphics.com.au>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Dimitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mike Frysinger <vapier.adi@gmail.com>
Acked-by: Ben Pfaff <blp@cs.stanford.edu>
Acked-by: Hans J. Koch <hjk@linutronix.de>
Reviewed-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fixes cursor corruption in certain cases.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
All file_operations should get a .llseek operation so we can make
nonseekable_open the default for future file operations without a
.llseek pointer.
The three cases that we can automatically detect are no_llseek, seq_lseek
and default_llseek. For cases where we can we can automatically prove that
the file offset is always ignored, we use noop_llseek, which maintains
the current behavior of not returning an error from a seek.
New drivers should normally not use noop_llseek but instead use no_llseek
and call nonseekable_open at open time. Existing drivers can be converted
to do the same when the maintainer knows for certain that no user code
relies on calling seek on the device file.
The generated code is often incorrectly indented and right now contains
comments that clarify for each added line why a specific variant was
chosen. In the version that gets submitted upstream, the comments will
be gone and I will manually fix the indentation, because there does not
seem to be a way to do that using coccinelle.
Some amount of new code is currently sitting in linux-next that should get
the same modifications, which I will do at the end of the merge window.
Many thanks to Julia Lawall for helping me learn to write a semantic
patch that does all this.
===== begin semantic patch =====
// This adds an llseek= method to all file operations,
// as a preparation for making no_llseek the default.
//
// The rules are
// - use no_llseek explicitly if we do nonseekable_open
// - use seq_lseek for sequential files
// - use default_llseek if we know we access f_pos
// - use noop_llseek if we know we don't access f_pos,
// but we still want to allow users to call lseek
//
@ open1 exists @
identifier nested_open;
@@
nested_open(...)
{
<+...
nonseekable_open(...)
...+>
}
@ open exists@
identifier open_f;
identifier i, f;
identifier open1.nested_open;
@@
int open_f(struct inode *i, struct file *f)
{
<+...
(
nonseekable_open(...)
|
nested_open(...)
)
...+>
}
@ read disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ read_no_fpos disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
... when != off
}
@ write @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ write_no_fpos @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
... when != off
}
@ fops0 @
identifier fops;
@@
struct file_operations fops = {
...
};
@ has_llseek depends on fops0 @
identifier fops0.fops;
identifier llseek_f;
@@
struct file_operations fops = {
...
.llseek = llseek_f,
...
};
@ has_read depends on fops0 @
identifier fops0.fops;
identifier read_f;
@@
struct file_operations fops = {
...
.read = read_f,
...
};
@ has_write depends on fops0 @
identifier fops0.fops;
identifier write_f;
@@
struct file_operations fops = {
...
.write = write_f,
...
};
@ has_open depends on fops0 @
identifier fops0.fops;
identifier open_f;
@@
struct file_operations fops = {
...
.open = open_f,
...
};
// use no_llseek if we call nonseekable_open
////////////////////////////////////////////
@ nonseekable1 depends on !has_llseek && has_open @
identifier fops0.fops;
identifier nso ~= "nonseekable_open";
@@
struct file_operations fops = {
... .open = nso, ...
+.llseek = no_llseek, /* nonseekable */
};
@ nonseekable2 depends on !has_llseek @
identifier fops0.fops;
identifier open.open_f;
@@
struct file_operations fops = {
... .open = open_f, ...
+.llseek = no_llseek, /* open uses nonseekable */
};
// use seq_lseek for sequential files
/////////////////////////////////////
@ seq depends on !has_llseek @
identifier fops0.fops;
identifier sr ~= "seq_read";
@@
struct file_operations fops = {
... .read = sr, ...
+.llseek = seq_lseek, /* we have seq_read */
};
// use default_llseek if there is a readdir
///////////////////////////////////////////
@ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier readdir_e;
@@
// any other fop is used that changes pos
struct file_operations fops = {
... .readdir = readdir_e, ...
+.llseek = default_llseek, /* readdir is present */
};
// use default_llseek if at least one of read/write touches f_pos
/////////////////////////////////////////////////////////////////
@ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read.read_f;
@@
// read fops use offset
struct file_operations fops = {
... .read = read_f, ...
+.llseek = default_llseek, /* read accesses f_pos */
};
@ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write.write_f;
@@
// write fops use offset
struct file_operations fops = {
... .write = write_f, ...
+ .llseek = default_llseek, /* write accesses f_pos */
};
// Use noop_llseek if neither read nor write accesses f_pos
///////////////////////////////////////////////////////////
@ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
identifier write_no_fpos.write_f;
@@
// write fops use offset
struct file_operations fops = {
...
.write = write_f,
.read = read_f,
...
+.llseek = noop_llseek, /* read and write both use no f_pos */
};
@ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write_no_fpos.write_f;
@@
struct file_operations fops = {
... .write = write_f, ...
+.llseek = noop_llseek, /* write uses no f_pos */
};
@ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
@@
struct file_operations fops = {
... .read = read_f, ...
+.llseek = noop_llseek, /* read uses no f_pos */
};
@ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
@@
struct file_operations fops = {
...
+.llseek = noop_llseek, /* no read or write fn */
};
===== End semantic patch =====
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Julia Lawall <julia@diku.dk>
Cc: Christoph Hellwig <hch@infradead.org>
I see the following error message in my kernel log from time to time:
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait
After investigation, it turns out that there's nothing to be afraid of
and everything works as intended. So remove the spurious log message.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make TV standard and DFP table revisions debug only.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These bits are used for internal communication and should
be left enabled. This may fix s/r issues on some systems.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.
This patch limit the vram allocation to visible vram until
we have acceleration up and running.
Note that it's more than unlikely that we run into any issue
related to that as when acceleration is not woring userspace
should allocate any object in vram beside front buffer which
should fit in visible vram.
V2 use real_vram_size as mc_vram_size could be bigger than
the actual amount of vram
[airlied: fixup r700_cp_stop case]
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The i915 driver has quite a few module unload bugs, the known ones at
least have fixes that are targeting 2.6.37. However, in order to
maintain a stable kernel, we should prevent this known random memory
corruption following driver unload. This should have very low impact on
normal users who are unlikely to need to unload the i915 driver.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On Sandybridge, the bit definition for hotplug on SDE has changed, so
update the code to new definition.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30378
Cc: stable@kernel.org
Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After disabling the hotplug interrupts for VGA detection on Ironlake, be
sure to re-enable them again afterwards.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30378
Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Needed on Ibex Peak and Cougar Point or the panel won't always come on.
Cc: stable@kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We don't use the CPU DP PLL with PCH attached eDP panels, so don't
bother to enable it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can skip most of the link training step if we use the VBT provided
values.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cache the first 4 bytes of DPCD data in the eDP case. It's unlikely to
change and can save us some trouble at link training time.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We do this later (and more properly) when we enable FDI, so we don't
need to do it here.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Wait for vblank after enabling a pipe, make the error messages more
informative, and wait for the pipe to turn off when we disable it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
CPU eDP needs a different reference clock than PCH eDP, which uses the
standard PCH refclk of 120MHz.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Enable SSC on PCH eDP if possible.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: added a posting read of PCH_DREF_CONTROL before the udelay]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to use some of these values in eDP configurations, so be sure to
fetch them and store them in the i915 private structure.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The _DSM method on the integrated graphics device can tell us which
connectors are muxable, so add support for making the call and parsing
out the connector info.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: fix compiler warnings for using uninitialized 'result' and
downgrade error message for non-switchable devices]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Enable the panel before adjusting eDP link params, make sure the panel
is idle after powering it on before proceeding with other activity,
delay backlight enable to avoid visible flicker.
Also avoid using VDD per hw team recommendation; it can conflict with
the builtin panel power sequencing logic and lead to panel power
sequencing failures.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
FDI training needs to done and idle for PCH eDP and before we turn the
pipes on, and various eDP checks need to account for PCH attached eDP.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we set the output type of PCH attached eDP panels to
INTEL_OUTPUT_eDP this function would never return true when it should.
It's been replaced by working functions.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The display code needs to distinguish between CPU and PCH attached eDP
panels, so add some helpers to handle that.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With the old check we'd never set lane_count or bpp to different values
on PCH attached eDP panels.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If is_edp is true, is_pch_edp will always be true. So limit the calls
to the latter function to places where the distinction actually matters.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Most of the PCH eDP checks are redundant, so document the functions in
preparation for removing most of the calls.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently, if a batch buffer refers to an object with a pending flip,
then we sleep until that pending flip is completed (unpinned and
signalled). This is so that a flip can be queued and the user can
continue rendering to the backbuffer oblivious to whether the buffer is
still pinned as the scan out. (The kernel arbitrating at the last moment
to stall the batch and wait until the buffer is unpinned and replaced as
the front buffer.)
As we only have a queue depth of 1, we can simply wait for the current
pending flip to complete and continue rendering. We can achieve this
with a single WAIT_FOR_EVENT command inserted into the ring buffer prior
to executing the batch, *without* stalling the client.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A physically mapped hardware status page is allocated at driver load
time but was never freed. Call the existing code to free this page at
driver unload time on hardware which uses this kind.
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: call before tearing down registers on KMS-only path, as pointed
out by Dave Airlie]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
since the handle references are all tied to a file_priv, and when it disappears
all the handle refs go with it.
The fbcon ones we'd only notice on unload, but the nouveau notifier one
would would happen on reboot.
nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com>
nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
i915 unload: Reported-by: Keith Packard <keithp@keithp.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-radeon-next' of ../drm-radeon-next:
drm/radeon/kms: add drm blit support for evergreen
drm/radeon: Modify radeon_pm_in_vbl to use radeon_get_crtc_scanoutpos()
drm/radeon: Add function for display scanout position query.
drm/radeon/kms: rework spread spectrum handling
drm/radeon/kms: remove new pll algo
drm/radeon/kms: remove some pll algo flags
drm/radeon/kms: prefer high post dividers in legacy pll algo
drm/radeon/kms: properly handle 40 bit MC addresses in the cursor code
drm/radeon: add properties to configure the width of the underscan borders
drm/radeon/kms/r6xx+: use new style fencing (v3)
drm/radeon/kms: enable writeback (v2)
drm/radeon/kms: clean up r6xx/r7xx blit init (v2)
* drm-kdb-next:
drm/nouveau/kms: Avoid a hang entering KDB with VT accel on.
radeon, kdb, kms: Save and restore the LUT on atomic KMS enter/exit
drm, kdb, kms: Add an enter argument to mode_set_base_atomic() API
drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.
drm/radeon/kms: Implement KDB debug hooks for radeon KMS.
[airlied - add fix for vmwgfx build]
* 'nouveau/for-airlied' of ../drm-nouveau-next: (93 commits)
drm/ttm: restructure to allow driver to plug in alternate memory manager
drm/ttm: introduce utility function to free an allocated memory node
drm/nouveau: fix thinkos in mem timing table recordlen check
drm/nouveau: parse voltage from perf 0x40 entires
drm/nouveau: don't use the default pll limits in table v2.1 on nv50+ cards
drm/nv50: Fix large 3D performance regression caused by the interchannel sync patches.
drm/nouveau: Synchronize buffer object moves in hardware.
drm/nouveau: Use semaphores to handle inter-channel sync in hardware.
drm/nouveau: Provide a means to have arbitrary work run on fence completion.
drm/nouveau: Minor refactoring/cleanup of the fence code.
drm/nouveau: Add a module option to force card POST.
drm/nv50: prevent (IB_PUT == IB_GET) for occurring unless idle
drm/nv0x-nv4x: Leave the 0x40 bit untouched when changing CRE_LCD.
drm/nv30-nv40: Fix postdivider mask when writing engine/memory PLLs.
drm/nouveau: Fix perf table parsing on BMP v5.25.
drm/nouveau: fix required mode bandwidth calculation for DP
drm/nouveau: fix typo in c2aa91afea5f7e7ae4530fabd37414a79c03328c
drm/nva3: split pm backend out from nv50
drm/nouveau: run perflvl and M table scripts on mem clock change
drm/nouveau: pass perflvl struct to clock_pre()
...
Francisco Jerez advises that pre-nv20 cards would hang if we entered
kdb with accel on and IRQs disabled, so we now disable accel before
entering kdb and re-enable it on the way back out.
Reported-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever happened.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some devices such as the radeon chips receive information from user
space which needs to be saved when executing an atomic mode set
operation, else the user space would have to be queried again for the
information.
This patch extends the mode_set_base_atomic() call to pass an argument
to indicate if this is an entry or an exit from an atomic kernel mode
set change. Individual drm drivers can properly save and restore
state accordingly.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested on nv50 and nv04 HW.
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch implements blit support for bo moves using
the 3D engine. It uses the same method as r6xx/r7xx:
- store the base state in an IB
- emit variable state and vertex buffers to do the blit
This allows the hw to move bos using the 3D engine and allows
full use of vram beyond the pci aperture size.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon_pm_in_vbl() didn't report in vblank status accurately. Make
it a wrapper around radeon_get_crtc_scanoutpos() which corrects for
biases, so it reports accurately.
radeon_pm_in_vbl() will only report in_vbl if all active crtc's
are currently inside vblank.
agd5f: use rdev->num_crtc rather than hardcoding the crtc count
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon_get_crtc_scanoutpos() returns the current horizontal
and vertical scanout position of a crtc. It also reports if
the display scanout is currently inside the vblank area.
hpos reports current horizontal pixel scanout position.
vpos reports the current scanned out line as a value >= 0
in active scanout. If the scanout is inside vblank area, it
reports a negative value, the number of scanlines until
end of vblank aka start of active scanout, e.g., -3 ==
"At most 3 scanlines until end of vblank".
This code is derived from radeon_pm_in_vbl(), tested on
R500 and R600.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch reworks spread spectrum handling to enable it
properly on lvds and DP/eDP links. It also fixes several
bugs in the old spread spectrum code.
- Use the ss recommended reference divider if available
when calculating the pll
- Use the proper ss command tables on pre-DCE3 asics
- Avoid reading past the end of the ss info tables
- Enable ss on evergreen asics (lvds, dp, tmds)
- Enable ss on DP/eDP links
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The recent changes to the old algo (prefer high post div)
coupled with the range and precision limitations of using
fixed point with the new algo make the new algo less
useful. So drop the new algo. This should work as well
or better than the old new/old combinations and simplifies
the code a lot.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30218
among others.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These shouldn't be needed with the post div changes
in the last patch.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This allows for a more exact fitting on the physical
display. The new properties default to zero which corresponds to the
previous underscan border width[height] formula:
(display_width[display_width] >> 5) + 16.
Example to set a horizontal border width of 30 and a vertikal border
height of 22:
xrandr --output HDMI-0 --set underscan on --set "underscan hborder" 30 --set "underscan vborder" 22
Signed-off-by: Marius Gröger <marius.groeger@googlemail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On r6xx+ a newer fence mechanism was implemented to replace
the old wait_until plus scratch regs setup. A single EOP event
will flush the destination caches, write a fence value, and generate
an interrupt. This is the recommended fence mechanism on r6xx+ asics.
This requires my previous writeback patch.
v2: fix typo that enabled event fence checking on all asics
rather than just r6xx+.
v3: properly enable EOP interrupts
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=29972
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Keith Packard
Alex Deucher
Inki Dae
Thomas Hellstrom
Jakob Bornecrantz
Michel Dänzer
Nicholas Miell
Linus Torvalds
Dave Airlie
Simon Farnsworth
Ben Widawsky
Wu Fengguang
Ben Skeggs
Marcin Slusarz
Martin Peres
Roy Spliet
Ken Milmore
Akshay Joshi
Jiri Kosina
Justin P. Mattock
Michel Dänzer
Lin Ming
Emil Velikov
Tormod Volden
Michel Dänzer
Marek Olšák
Rob Clark
Jerome Glisse
Michael Witten
Joonyoung Shim
Thomas Jarosch
Thomas Reim
Kamal Mostafa
Jay Estabrook
Jesse Barnes
Matthew Garrett
Thomas Reim
Bojan Prtvar
Fernando Luis Vázquez Cao
Dan Carpenter
Adam Jackson
Michel Alexandre Salim
Pieterjan Camerlynck
Arun Sharma
Rakib Mullick
Benjamin Herrenschmidt
Alan Cox
Rolf Eike Beer
Ralf Baechle
Jesper Juhl
Phil Carmody
Chris Wilson
Alex Deucher
Jon Mason
Kenneth Graunke
Hugh Dickins
Younes Manton
Eric Anholt
Konrad Rzeszutek Wilk
Vitaliy Ivanov
Daniel J Blueman
Jean Delvare
Christian Dietrich
Dave Airlie
Wolfram Sang
Greg Dietsche
Ilija Hadzic
Sascha Hauer
Daniel Haid
Francisco Jerez
Hans de Goede
Daniel Vetter
Nicolas Kaiser
Jason Stubbs
Ying Han
Andrew Morton
Feng, Boqun
Randy Dunlap
Martin Peres
Jimmy Rentz
Andy Lutomirski
Florian Mickler
Alex Williamson
Christopher James Halse Rogers
Joe Perches
Cédric Cano
Konstantin Khlebnikov
Sitsofe Wheeler
Mathew McKernan
Paul Bolle
David Dillow
Jan Engelhardt
John Lindgren
Lucas De Marchi
Thomas Renninger
Takashi Iwai
Yuanhan Liu
Herton Ronaldo Krzesinski
roel
Zhenyu Wang
Jan Niehusmann
Benjamin Franzke
Tejun Heo
Lucas Stach
Mario Kleiner
Indan Zupancic
Kees Cook
Dave Airlie
Arnd Bergmann
Stefan Weil
Torben Hohn
Michael Karcher
David Rientjes
Bryan Freed
Alexander Lam
Knut Petersen
Len Brown
Yuanhan Liu
David Müller
James Simmons
Michel Hermier
Ben Hutchings
David Fries
Tijl Coosemans
Zhang Rui
David Flynn
Alex Shi
Vasiliy Kulikov
Jiri Slaby
Lionel Debroux
Zou Nan hai
Tyson Whitehead
Kulikov Vasiliy
Sam Tygier
Ingo Molnar
Zhenyu Wang
Kyle McMartin
Uwe Kleine-König
Christoph Fritz
Peter Zijlstra
Lee, Chun-Yi
David Härdeman
Chia-I Wu
Andrea Gelmini
Bryan Freed
Jason Wessel
Chris Ball
Marius Gröger