We have two important transitions of the wedged state in the current
code:
- 0 -> 1: This means a hang has been detected, and signals to everyone
that they please get of any locks, so that the reset work item can
do its job.
- 1 -> 0: The reset handler has completed.
Now the last transition mixes up two states: "Reset completed and
successful" and "Reset failed". To distinguish these two we do some
tricks with the reset completion, but I simply could not convince
myself that this doesn't race under odd circumstances.
Hence split this up, and add a new terminal state indicating that the
hw is gone for good.
Also add explicit #defines for both states, update comments.
v2: Split out the reset handling bugfix for the throttle ioctl.
v3: s/tmp/wedged/ sugested by Chris Wilson. Also fixup up a rebase
error which prevented this patch from actually compiling.
v4: To unify the wedged state with the reset counter, keep the
reset-in-progress state just as a flag. The terminally-wedged state is
now denoted with a big number.
v5: Add a comment to the reset_counter special values explaining that
WEDGED & RESET_IN_PROGRESS needs to be true for the code to be
correct.
v6: Fixup logic errors introduced with the wedged+reset_counter
unification. Since WEDGED implies reset-in-progress (in a way we're
terminally stuck in the dead-but-reset-not-completed state), we need
ensure that we check for this everywhere. The specific bug was in
wait_for_error, which would simply have timed out.
v7: Extract an inline i915_reset_in_progress helper to make the code
more readable. Also annote the reset-in-progress case with an
unlikely, to help the compiler optimize the fastpath. Do the same for
the terminally wedged case with i915_terminally_wedged.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While auditing the code I've noticed one place (the throttle ioctl)
which does not yet wait for the reset handler to complete and doesn't
properly decode the wedge state into -EAGAIN/-EIO. Fix this up by
calling the right helpers. This might explain the oddball "my
compositor just died in a successfull gpu reset" reports. Or maybe not, since
current mesa doesn't use this ioctl to throttle command submission.
The throttle ioctl doesn't take the struct_mutex, so to avoid busy-looping
with -EAGAIN while a reset is in process, check for errors first and wait
for the handler to complete if a reset is pending by calling
i915_gem_wait_for_error.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And to make Ben Widawsky happier, use the gpu_error instead of
the entire device as the argument in some functions.
Drop the outdated comment on ->wedged for now, a follow-up patch will
change the semantics and add a proper comment again.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has been sprinkled all over the place in dev_priv. I think
it'd be good to also move all the code into a separate file like
i915_gem_error.c, but that's for another patch.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tha one is really big, since it contains tons of comments explaining
how things work. Which is nice ;-)
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The reasoning behind our code taking two paths depending upon whether or
not we may have been configured for IOMMU isn't clear to me. It should
always be safe to use the pci mapping functions as they are designed to
abstract the decision we were handling in i915.
Aside from simpler code, removing another member for the intel_gtt
struct is a nice motivation.
I ran this by Chris, and he wasn't concerned about the extra kzalloc,
and memory references vs. page_to_phys calculation in the case without
IOMMU.
v2: Update commit message
v3: Remove needs_dmar addition from Zhenyu upstream
This reverts (and then other stuff)
commit 20652097da
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Thu Dec 13 23:47:47 2012 +0800
drm/i915: Fix missed needs_dmar setting
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Squash in follow-up fix to remove the bogus hunk which
deleted the dma_mask configuration for gen6+.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already had a mapping in both (minus the phys_addr in AGP).
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And, move it to where the rest of the logic is.
There is some slight functionality changes. There was extra paranoid
checks in AGP code making sure we never do idle maps on gen2 parts. That
was not duplicated as the simple PCI id check should do the right thing.
v2: use IS_GEN5 && IS_MOBILE check instead. For now, this is the same as
IS_IRONLAKE_M but is more future proof. The workaround docs hint that
more than one platform may be effected, but we've never seen such a
platform in the wild. (Rodrigo, Daniel)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
[1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame
v2: Give the Q bits better names, add spec chapter information
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: David Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise full range output is used.
Additionally DVI monitors should most likely default to full range
always.
As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
otherwise will follow CEA-861 rules.
NOTE: The default value for the property will now be "Automatic"
so some people may be affected in case they're relying on the
current full range default.
[1] CEA-861-E - 5.1 Default Encoding Parameters
[2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
v2: Use has_hdmi_sink to check if a HDMI monitor is present
v3: Add information about relevant spec chapters
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limited color range is requested.
Set the the PIPECONF bit 13 based on the flag.
Experimentation showed that simply toggling the bit while the pipe is
active doesn't work. We need to restart the pipe, which luckily already
happens.
The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
although it doesn't seem to do any harm in practice.
TODO:
- the PIPECONF bit too seems to have disappeared from HSW. Need a
volunteer to test if it's just a documentation issue or if it's really
gone. If the bit is gone and no easy replacement is found, then I suppose
we may need to use the pipe CSC unit to perform the range compression.
v2: Use mode private_flags instead of intel_encoder virtual functions
v3: Moved the intel_dp color_range handling after bpc check to help
later patches
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mappable_end, ie. size is almost always what you want as opposed to the
number of entries. Since we already have that information, we can scrap
the number of entries and only calculate it when needed.
If gtt_start is !0, this will have slightly different behavior. This
difference can only occur in DRI1, and exists when we try to kick out
the firmware fb. The new code seems like a bugfix to me.
The other case where we've changed the behavior is during init we check
the mappable region against our current known upper and lower limits
(64MB, and 512MB). This now matches the comment, and makes things more
convenient after removing gtt_mappable_entries.
Also worth noting is the setting of mappable_end is taken out of setup
because we do it earlier now in the DRI2 case and therefore need to add
that tiny hunk to support the DRI1 IOCTL.
v2: Move up mappable end to before legacy AGP init
v3: Add the dev_priv inclusion here from previous rebase error in patch
5
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: squash in fix for a printk format flag mismatch warning.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have enough info to not use the intel_gtt bridge stuff.
v2: Move setup of mappable_base above the legacy init stuff because we
still need that on older platforms. (Daniel)
v3: Remove the dev_priv hunk which was rebased in by accident
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The purpose of the gtt structure is to help isolate our gtt specific
properties from the rest of the code (in doing so it help us finish the
isolation from the AGP connection).
The following members are pulled out (and renamed):
gtt_start
gtt_total
gtt_mappable_end
gtt_mappable
gtt_base_addr
gsm
The gtt structure will serve as a nice place to put gen specific gtt
routines in upcoming patches. As far as what else I feel belongs in this
structure: it is meant to encapsulate the GTT's physical properties.
This is why I've not added fields which track various drm_mm properties,
or things like gtt_mtrr (which is itself a pretty transient field).
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[Ben modified commit messages]
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the assertion from the previous patch in place, it should be safe
to get rid gtt_mappable_total. Keeps things saner to not have to track
the same info in two places.
In order to keep the diff as simple as possible and keep with the
existing gtt_setup semantics we opt to keep gtt_mappable_end. It's not
as consistent with the 'total' used in the previous patch, but that can
be fixed later.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[Ben modified commit message]
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both DRI1 and DRI2 can never specify a mappable size which goes past the
GTT size. Don't pretend otherwise.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's duplicated in the more useful gtt_total.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix up some copypaste errors in the PIPESTAT register for VLV.
SPRITE0_FLIP_DONE_INT_EN_VLV is bit 22, not bit 26.
SPRITE0_FLIPDONE_INT_STATUS_VLV is bit 14, not bit 15.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using copywinwin10 as an example that is dependent upon emitting a lot
of relocations (2 per operation), we see improvements of:
c2d/gm45: 618000.0/sec to 623000.0/sec.
i3-330m: 748000.0/sec to 789000.0/sec.
(measured relative to a baseline with neither optimisations applied).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Userspace is able to hint to the kernel that its command stream and
auxiliary state buffers already hold the correct presumed addresses and
so the relocation process may be skipped if the kernel does not need to
move any buffers in preparation for the execbuffer. Thus for the common
case where the allotment of buffers is static between batches, we can
avoid the overhead of individually checking the relocation entries.
Note that this requires userspace to supply the domain tracking and
requests for workarounds itself that would otherwise be computed based
upon the relocation entries.
Using copywinwin10 as an example that is dependent upon emitting a lot
of relocations (2 per operation), we see improvements of:
c2d/gm45: 618000.0/sec to 632000.0/sec.
i3-330m: 748000.0/sec to 830000.0/sec.
(measured relative to a baseline with neither optimisations applied).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Fixup merge conflict in userspace header due to different
baseline trees.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of passing around the eb-objects hashtable and a separate object
list, we can include the object list into the eb-objects structure for
convenience.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The difference is that the kernel will then know that this memory will
be reclaimable in the near future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the existing checking inside bind_to_gtt() to the more appropriate
layer in order to prevent recreation of the pages after they have been
explicitly truncated.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As a means to investigate some bad system behaviour related to the
purging of the active, inactive and unbound lists, it is useful to be
able to manually control when those lists should be cleared.
v2: use _safe list iterators as we kick objects from the list as we
walk.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add a small comment explaining why we don't need to check and
wait for gpu resets, acked by Chris on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The two functions are rather similar, so merge them.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The two functions are rather similar, so merge them.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This variable is only used locally in the irq postinstall
functions for ivybridge and ironlake.
Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise it seems like we can get stuck with concurrent waiters.
Right now this /shouldn't/ be a problem, since all pending pageflip
waiters are serialized by the one mode_config.mutex, so there's at
most on waiter. But better paranoid than sorry, since this is tricky
code.
v2: WARN_ON(waitqueue_active) before waiting, as suggested by Chris
Wilson.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
- seqno wrap fixes and debug infrastructure from Mika Kuoppala and Chris
Wilson
- some leftover kill-agp on gen6+ patches from Ben
- hotplug improvements from Damien
- clear fb when allocated from stolen, avoids dirt on the fbcon (Chris)
- Stolen mem support from Chris Wilson, one of the many steps to get to
real fastboot support.
- Some DDI code cleanups from Paulo.
- Some refactorings around lvds and dp code.
- some random little bits&pieces
* tag 'drm-intel-next-2012-12-21' of git://people.freedesktop.org/~danvet/drm-intel: (93 commits)
drm/i915: Return the real error code from intel_set_mode()
drm/i915: Make GSM void
drm/i915: Move GSM mapping into dev_priv
drm/i915: Move even more gtt code to i915_gem_gtt
drm/i915: Make next_seqno debugs entry to use i915_gem_set_seqno
drm/i915: Introduce i915_gem_set_seqno()
drm/i915: Always clear semaphore mboxes on seqno wrap
drm/i915: Initialize hardware semaphore state on ring init
drm/i915: Introduce ring set_seqno
drm/i915: Missed conversion to gtt_pte_t
drm/i915: Bug on unsupported swizzled platforms
drm/i915: BUG() if fences are used on unsupported platform
drm/i915: fixup overlay stolen memory leak
drm/i915: clean up PIPECONF bpc #defines
drm/i915: add intel_dp_set_signal_levels
drm/i915: remove leftover display.update_wm assignment
drm/i915: check for the PCH when setting pch_transcoder
drm/i915: Clear the stolen fb before enabling
drm/i915: Access to snooped system memory through the GTT is incoherent
drm/i915: Remove stale comment about intel_dp_detect()
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Pull drm update from Dave Airlie:
"Exynos and Radeon mostly, with a dma-buf and ttm fix thrown in.
It's a bit big but its mostly exynos license fix ups and I'd rather
not hold those up since its legally stuff.
Radeon has a couple of fixes from dma engine work, TTM is just a
locking fix, and dma-buf fix has been hanging around and I finally got
a chance to review it."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (30 commits)
drm/ttm: fix fence locking in ttm_buffer_object_transfer
drm/prime: drop reference on imported dma-buf come from gem
drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks
drm/exynos: move finish page flip to a common place
drm/exynos: fimd: modify condition in fimd resume
drm/radeon: fix DMA CS parser for r6xx linear copy packet
drm/radeon: split r6xx and r7xx copy_dma functions
drm/exynos: Use devm_clk_get in exynos_drm_gsc.c
drm/exynos: Remove redundant NULL check in exynos_drm_gsc.c
drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_gsc.c
drm/exynos: Use devm_clk_get in exynos_drm_rotator.c
drm/exynos: Remove redundant NULL check in exynos_drm_rotator.c
drm/exynos: Remove unnecessary devm_* freeing APIs in exynos_drm_rotator.c
drm/exynos: Use devm_clk_get in exynos_drm_fimc.c
drm/exynos: Remove redundant NULL check
drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_fimc.c
drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c
drm/exynos: fix gem buffer allocation type checking
drm/exynos: remove needless parenthesis.
drm/exynos: fix incorrect interrupt induced by m2m operation.
...
Noticed while reviewing the fence locking in the radeon pageflip
handler.
v2: Instead of grabbing the bdev->fence_lock in object_transfer just
move the single callsite of that function a few lines, so that it is
protected by the fence_lock. Suggested by Jerome Glisse.
v3: Fix typo in commit message.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex writes:
A few more fixes for DMA and a mac quirk.
* 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks
drm/radeon: fix DMA CS parser for r6xx linear copy packet
drm/radeon: split r6xx and r7xx copy_dma functions
Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem
makes memory leak. release function of dma-buf cannot be called because f_count
of dma-buf increased by importing gem and gem ref count cannot be decrease
because of exported dma-buf.
So I add dma_buf_put() for imported gem come from its own gem into each drivers
having prime_import and prime_export capabilities. With this, only gem ref
count is increased if importing gem exported from gem of same driver.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin.park <kyungmin.park@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
configuration space is not restored correctly, resulting in MSI not working after switch.
Only useful item in dmesg is:
[ 33.922807] radeon 0000:01:00.0: Refused to change power state, currently in D3
I did some testing, dumping the difference in ms between first succesful switch
from D3 to D0, and it seems that there is slightly more than 20 ms difference when
the device is re-enabled through vga-switcheroo.
So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not working
on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 10 ms.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch implements the exynos_drm_crtc_finish_pageflip in
exynos_drm_crtc.c. This avoids the duplication of same code
in mixer, fimd and vidi.
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Stephane Marchesin <marcheu@chromium.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
call fimd_activate(false) and just returns. Similarily the check in
fimd_resume should not resume if previously runtime_suspended.
Instead the existing check does the opposite. So if fimd was not
runtime suspended, suspend will turn off fimd but resume will not turn
it on. This patch fixes this issue by reversing the condition.
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Pull radeon and minor nouveau fixes from Dave Airlie:
"Just a radeon pull from Alex, fixes a few regressions since 3.7 and
reworks some of the reset handling, and two minor nouveau fixes I
found on the list, Ben will be back next week to take care of the
couple of larger nouveau patches that I see outstanding."
* 'drm-next' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau: fix init with agpgart-uninorth
drm: nouveau: Fix build warning seen if HWMON is undefined
drm/radeon: switch to a finer grained reset for SI (v2)
drm/radeon: switch to a finer grained reset for cayman/TN
drm/radeon: switch to a finer grained reset for evergreen
drm/radeon: switch to a finer grained reset for r6xx/7xx
drm/radeon: add GPU reset flags
drm/radeon: fix typo in evergreen dma fence
drm/radeon: Properly handle DDC probe for DP bridges
drm/radeon: reset dma engine on gpu reset (v2)
drm/radeon: print dma status reg on lockup (v2)
drm/radeon: improve ring debugfs printing
drm/radeon: add debugfs file for dma rings
drm/radeon/r6xx: fix DMA engine for ttm bo transfers
drm/radeon: add connector table for Mac G4 Silver
- r6xx actually uses a slightly different packet format,
although both formats seem to work ok.
- r7xx doesn't have the count multiple of 2 limitation.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
devm_kzalloc makes the code simpler by eliminating the need for
explicit freeing.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes gem buffer allocation type checking.
EXYNOS_BO_CONTIG has 0 so the checking should be fixed
to 'if (!(flags & EXYNOS_BO_NONCONTIG))'
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch removes needless parenthesis.
This was pointed out but in case of fimc side. we missed it.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes incorrect interrupt induced by m2m operation.
the m2m operation calls s/w reset every frame but there is the case that
the interrupt to m2m operation occures after s/w reset sometimes.
So this patch makes dma and capture operations stop at s/w reset
to avoid incorrect interrupt.
Signed-off-by: Jinyoung Jeon <jy0.jeon@samsung.com>
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch removes color bar pattern register because we don't use the register anymore.
because it doesn't support color bar feature for writeback operation.
camera driver only supports color bar feature. but IPP doesn't support camera driver.
Signed-off-by: JoongMock Shin <jmock.shin@samsung.com>
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch cleanup corrects some comments to abbreviation.
We would like to prevent it stands misunderstood.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes erroneous register read.
reall function needs register base address + offset but
exynos_drm_gsc module used only offset to read a register.
so this patch uses gsc_read function instead of readl.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch considers both case of vflip and hflip.
If we want that the contents in buffer to be rotated to 180 degree,
then we can use h,vflip or 180 degree.
Changelog v2:
- added EXYNOS_DRM_FLIP_BOTH enum value to avoid build warnning.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch removes property error handling. because property couldn't be NULL.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch change current command name from cmd to c_node.
because we are using the member name, 'cmd', for command control ioctl in another structure.
so, this patch changes it to c_node to avoid such confusing.
Signed-off-by: Eunchul Kim <chulspro.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes the issue that when buffer allocation is requested
without iommu, the allocation is failed.
Without iommu, dma_alloc_attrs function allocates some memory region
and returns cpu address so this patch makes the cpu address to be set
to buf->kvaddr correctly.
Changelog v2:
- fix buffer free
. Without iommu, dma_free_attrs function requires kernel space address
as argument. So it changes the argument, buf->pages to buf->kvaddr.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch changes file license to GPL
Most of exynos files had been copied from some random
file and not updated correctly. So this patch corrects
the file license.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch considers no iommu support to kernel space mapping
of console framebuffer.
Without iommu, we get physical address instead of device address
after dma_alloc_attrs function is called. So we should consider
the case without iommu when it maps console framebuffer with
kernel space.
Changelog v2:
- calll vunmap function only with iommu support.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).
The patch fixes the following error seen on G5 iMac:
nouveau E[ DRM] failed to create kernel channel, -12
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58806
Cc: stable@vger.kernel.org
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix:
nouveau_pm.c: In function ‘nouveau_hwmon_init’:
nouveau_pm.c:703:24: warning: unused variable ‘therm’ [-Wunused-variable]
Introduced by commit 095f979a (drm/nouveau/pm: fix build with HWMON off) which
fixed a build error but introduced a build warning.
Cc: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No change in functionality as we currently set all the reset
flags.
v2: fix typo
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No change in functionality as we currently set all the reset
flags.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No change in functionality as we currently set all the reset
flags.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No change in functionality as we currently set all the reset
flags.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The idea here is to move to a finer grained reset.
In some cases we may not need reset every block, and
in other cases we may not need to re-init the entire
asic.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.
This change removes the use of __devinit, __devexit_p, and __devexit
from these drivers.
Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DDC information can be accessed using AUX CH
Fixes failure to probe monitors on some systems with
DP bridge chips.
agd5f: minor fixes
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This try to reset the dma engine when performing gpu reset. Hopefully
bringing back the gpu dma engine in sane state.
v2: agd5f: fix dma reset on cayman/TN, add support for SI
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To help debug dma related lockup.
v2: agd5f: update SI as well
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Print 32dword before last know rptr as problem most likely comes
from previous command. Also small cosmetic change to the printing.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
count must be a multiple of 2. Fixes crashes on
R6xx chips reported by a number of people.
Cc: Borislav Petkov <bp@alien8.de>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Tested-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Apple cards do not provide data tables in the vbios
so we have to hard code the connector parameters
in the driver.
Reported-by: Albrecht Dreß <albrecht.dress@arcor.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This reverts commit 83c0bcb694.
Lucas pointed out this was a mistake, and I missed the discussion,
so just revert it out to save a rebase.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The intention is to program exactly WIN_A, not WIN_A and possibly
others.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is no gem.c anymore, those functions are implemented by the
drm_cma_helpers now.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The 720p and 1080p entries are completely redundant, as we are matching
the table entries against <=pclk.
Also generalize the comment, as we are using those table entries even
when driving other modes than the standard TV ones.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Window properties are programmed through a shared aperture and have to
happen atomically. Also we do the read-update-write dance on some of the
shared regs.
To make sure that different functions don't stumble over each other
protect the register access with a mutex.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No real problem for now, as nothing is using this, but leaving it
unitialized is asking for trouble later on.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes wrong picture offset observed when using HDMI output with a
Technisat HD TV.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Acked-by: Mark Zhang <markz@nvidia.com>
Tested-by: Mark Zhang <markz@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some fixes for 3.8:
- Watermark fixups from Chris Wilson (4 pieces).
- 2 snb workarounds, seem to be recently added to our internal DB.
- workaround for the infamous i830/i845 hang, seems now finally solid!
Based on Chris' fix for SNA, now also for UXA/mesa&old SNA.
- Some more fixlets for shrinker-pulls-the-rug issues (Chris&me).
- Fix dma-buf flags when exporting (you).
- Disable the VGA plane if it's enabled on lid open - similar fix in
spirit to the one I've sent you last weeek, BIOS' really like to mess
with the display when closing the lid (awesome debug work from Krzysztof
Mazur).
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: disable shrinker lock stealing for create_mmap_offset
drm/i915: optionally disable shrinker lock stealing
drm/i915: fix flags in dma buf exporting
i915: ensure that VGA plane is disabled
drm/i915: Preallocate the drm_mm_node prior to manipulating the GTT drm_mm manager
drm: Export routines for inserting preallocated nodes into the mm manager
drm/i915: don't disable disconnected outputs
drm/i915: Implement workaround for broken CS tlb on i830/845
drm/i915: Implement WaSetupGtModeTdRowDispatch
drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM computations
drm/i915: Clear self-refresh watermarks when disabled
drm/i915: Double the cursor self-refresh latency on Valleyview
drm/i915: Fixup cursor latency used for IVB lp3 watermarks
Misc fixes for reset and new packets for userspace usage.
* 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list
drm/radeon: add support for MEM_WRITE packet
drm/radeon: restore modeset late in GPU reset path
drm/radeon: avoid deadlock in pm path when waiting for fence
drm/radeon: don't leave fence blocked process on failed GPU reset
Modesetting seems to work alright, as does graphics (using binary driver
fuc from nve7...).
Lots to be done no doubt, but this'll get an image on the screen for
people.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Note: This patch also adds a little helper intel_crtc_restore_mode for
the common case where we do a full modeset but with the same
parameters, e.g. to undo bios damage or update a property.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Added note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter