GEM objects used by frame buffers must be referenced for the whole life
of the frame buffer. Release the references in the frame buffer
destructor instead of its constructor.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
The exynos_drm_gem_dumb_map_offset() doesn't need to access any
Exynos-specific GEM object fields, don't cast the GEM object.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
DRIVER_BUS_PLATFORM is a bus type used internally in the DRM core, not a
flag for the drm_driver::driver_features field.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
The NV12M/YUV420M formats are identical to the already existing standard
NV12/YUV420 formats. The M variants will be removed, so convert the
driver to use the standard names.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This makes for easier benchmarking and testing. One can set a fixed
frequency by setting min and max to the same value.
v2: fix whitespace & comment (Eugeni)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni@dodonov.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.
After the previous two prep patches the only thing left is to clean up
things a bit. I've opted to pass in an adjust_mode param to
dp_adjust_dithering because that way we can be sure to avoid
duplicating this logic between mode_valid and mode_fixup - which was
the cause behind a dp link bw calculation bug in the past.
Also mark the mode argument of pch_panel_fitting const.
v2: Split up the mode->clock => adjusted_mode->clock change,
as suggested by Chris Wilson.
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of changing mode->clock, which we should leave as-is.
After the previous patch we only touch that if it's a panel, and then
adjusted mode->clock equals adjusted_mode->clock. Outside of
intel_dp.c we only use ajusted_mode->clock in the mode_set functions.
Within intel_dp.c we only use it to calculate the dp dithering
and link bw parameters, so that's the only thing we need to fix
up.
As a temporary ugliness (until the cleanup in the next patch) we
pass the adjusted_mode into dp_dither for both parameters (because
that one still looks at mode->clock).
Note that we do overwrite adjusted_mode->clock with the selected dp
link clock, but that only happens after we've calculated everything we
need based on the dotclock of the adjusted output configuration.
Outside of intel_dp.c only intel_display.c uses adjusted_mode->clock,
and that stays the same after this patch (still equals the selected dp
link clock). intel_display.c also needs the actual dotclock (as
target_clock), but that has been fixed up in the previous patch.
v2: Adjust the debug message to also use adjusted_mode->clock.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... instead of abusing mode->clock by storing it in there - we
shouldn't touch that one at all. This patch is the first prep step to
constify the mode argument of the intel_dp_mode_fixup function.
The next patch will stop us from modifying mode->clock.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Empirical evidence suggests that we need to: On at least one ivb
machine when running the hangman i-g-t test, the rings don't properly
initialize properly - the RING_START registers seems to be stuck at
all zeros.
Holding forcewake around this register init sequences makes chip reset
reliable again. Note that this is not the first such issue:
commit f01db988ef
Author: Sean Paul <seanpaul@chromium.org>
Date: Fri Mar 16 12:43:22 2012 -0400
drm/i915: Add wait_for in init_ring_common
added delay loops to make RING_START and RING_CTL initialization
reliable on the blt ring at boot-up. So I guess it won't hurt if we do
this unconditionally for all force_wake needing gpus.
To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
intel_info bit for that.
v2: Fixup missing commas in static struct and properly handling the
error case in init_ring_common, both noticed by Jani Nikula.
Cc: stable@vger.kernel.org
Reported-and-tested-by: Yang Guang <guang.a.yang@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By correctly describing the rinbuffers as being in the GTT domain, it
appears that we are more careful with the management of the CPU cache
upon resume and so prevent some coherency issue when submitting commands
to the GPU later. A secondary effect is that the debug logs are then
consistent with the actual usage (i.e. they no longer describe the
ringbuffers as being in the CPU write domain when we are accessing them
through an wc iomapping.)
Reported-and-tested-by: Daniel Gnoutcheff <daniel@gnoutcheff.name>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41092
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both busy_ioctl and the new wait_ioct need to do the same dance (or at
least should). Some slight changes:
- busy_ioctl now unconditionally checks for olr. Before emitting a
require flush would have prevent the olr check and hence required a
second call to the busy ioctl to really emit the request.
- the timeout wait now also retires request. Not really required for
abi-reasons, but makes a notch more sense imo.
I've tested this by pimping the i-g-t test some more and also checking
the polling behviour of the wait_rendering_timeout ioctl versus what
busy_ioctl returns.
v2: Too many people complained about unplug, new color is
flush_active.
v3: Kill the comment about the unplug moniker.
v4: s/un-active/inactive/
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm fixes from Dave Airlie:
"A bunch of fixes:
- vmware memory corruption
- ttm spinlock balance
- cirrus/mgag200 work in the presence of efifb
and finally Alex and Jerome managed to track down a magic set of bits
that on certain rv740 and evergreen cards allow the correct use of the
complete set of render backends, this makes the cards operate
correctly in a number of scenarios we had issues in before, it also
manages to boost speed on benchmarks my large amounts on these
specific gpus."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/edid: Make the header fixup threshold tunable
drm/radeon: fix regression in UMS CS ioctl
drm/vmwgfx: Fix nasty write past alloced memory area
drm/ttm: Fix spinlock imbalance
drm/radeon: fixup tiling group size and backendmap on r6xx-r9xx (v4)
drm/radeon: fix HD6790, HD6570 backend programming
drm/radeon: properly program gart on rv740, juniper, cypress, barts, hemlock
drm/radeon: fix bank information in tiling config
drm/mgag200: kick off conflicting framebuffers earlier.
drm/cirrus: kick out conflicting framebuffers earlier
cirrus: avoid crash if driver fails to load
Instead of checking for !CPT, check for IBX to make it clearer that
this is a IBX-specific workaround. No functional change because we
smash the PPT PCH into the HAS_PCH_CPT check and atm DP isn't enabled
on the haswell LPT PCH yet.
See Bspec Vol 3, Part 3, Section 4.[3-5].1 about DP[BCD], bit 30 for
details of this workaround.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull vfs changes from Al Viro.
"A lot of misc stuff. The obvious groups:
* Miklos' atomic_open series; kills the damn abuse of
->d_revalidate() by NFS, which was the major stumbling block for
all work in that area.
* ripping security_file_mmap() and dealing with deadlocks in the
area; sanitizing the neighborhood of vm_mmap()/vm_munmap() in
general.
* ->encode_fh() switched to saner API; insane fake dentry in
mm/cleancache.c gone.
* assorted annotations in fs (endianness, __user)
* parts of Artem's ->s_dirty work (jff2 and reiserfs parts)
* ->update_time() work from Josef.
* other bits and pieces all over the place.
Normally it would've been in two or three pull requests, but
signal.git stuff had eaten a lot of time during this cycle ;-/"
Fix up trivial conflicts in Documentation/filesystems/vfs.txt (the
'truncate_range' inode method was removed by the VM changes, the VFS
update adds an 'update_time()' method), and in fs/btrfs/ulist.[ch] (due
to sparse fix added twice, with other changes nearby).
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (95 commits)
nfs: don't open in ->d_revalidate
vfs: retry last component if opening stale dentry
vfs: nameidata_to_filp(): don't throw away file on error
vfs: nameidata_to_filp(): inline __dentry_open()
vfs: do_dentry_open(): don't put filp
vfs: split __dentry_open()
vfs: do_last() common post lookup
vfs: do_last(): add audit_inode before open
vfs: do_last(): only return EISDIR for O_CREAT
vfs: do_last(): check LOOKUP_DIRECTORY
vfs: do_last(): make ENOENT exit RCU safe
vfs: make follow_link check RCU safe
vfs: do_last(): use inode variable
vfs: do_last(): inline walk_component()
vfs: do_last(): make exit RCU safe
vfs: split do_lookup()
Btrfs: move over to use ->update_time
fs: introduce inode operation ->update_time
reiserfs: get rid of resierfs_sync_super
reiserfs: mark the superblock as dirty a bit later
...
6 bytes seems to be a reasonable default so far, but for the desperate
it's worth exposing this.
[airlied: change include to module.h for this]
Bugzilla: https://bugzilla.redhat.com/582559
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon_cs_parser_init is called by both the legacy UMS
CS ioctl and the KMS CS ioctl. Protect KMS specific
pieces of the code by checking that rdev is not NULL.
Reported-by: Michael Burian <michael.burian@sbg.at>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This imbalance may cause hangs when TTM is trying to swap out a buffer
that is already on the delayed delete list.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and
simplify render backend map. This now properly sets up the backend map
on r6xx-9xx which should improve 3D performance.
Vadim benchmarked also:
Some benchmarks on juniper (5750), fullscreen 1920x1080,
first result - kernel 3.4.0+ (fb21affa), second - with these patches:
Lightsmark: 91 fps => 123 fps +35%
Doom3: 74 fps => 101 fps +36%
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to program an additional VM register. This doesn't not currently
cause any problems, but allows us to program the proper backend
map in a subsequent patch which should improve performance on these
asics.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
While there are cards with more than 8 mem banks, the max
number of banks from a tiling perspective is 8, so cap
the tiling config at 8 banks.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43448
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
It appears grub2 can pass framebuffer info via efifb, so
we need to kick it off earlier to reserve the vram allocation.
(just a fixup same as for cirrus)
Signed-off-by: Dave Airlie <airlied@redhat.com>
It appears that grub2 will pass framebuffer info via EFI,
this causes the vram reserve to fail, so kick out efifb
earlier before cirrus loads.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=826983
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need the latest dma-buf code from Dave Airlie so that we can pimp
the backing storage handling code in drm/i915 with Chris Wilson's
unbound tracking and stolen mem backed gem object code.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Positively checking for the required feature/gen is simpler than build
a cascade of negative "we need to bail" checks. And the later won't
scale if we add more stuff that doesn't fit in nicely.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes an (albeit really hard to hit) race resulting in an oops:
- The parity work get scheduled.
- We re-init the irq state and call INIT_WORK again.
- The workqueue code tries to run the work item and stumbles over a
work item that should be on it's runlist.
Also initiliaze the work item unconditionally like all the others,
it's simpler.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Whilst most monitors do wire up the HPD presence pin, it seems quite a
few KVM do not. Therefore if we simply rely on the HPD pin being
asserted to indicate a connected monitor we fail miserable, so fall back
to performing a DCC query for the EDID.
Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dumb binary interfaces which allow root-only updates of the cache
remapping registers. As mentioned in a previous patch, software using
this interface needs to know about HW limits, and other programming
considerations as the kernel interface does no checking for these things
on the root-only interface.
v1: Drop extra posting reads (Chris)
Return negative values in the sysfs interfaces on errors (Chris)
v2: Return -EINVAL for offset % 4 (Jesse)
Move schizo userspace check out (Jesse)
Cleaner sysfs item initializers (Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If any l3 rows have been previously remapped, we must remap them after
GPU reset/resume too.
v2: Just return (no warn) on remapping init if not IVB (Jesse)
Move the check of schizo userspace to i915_gem_l3_remap (Jesse)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The previous patch put all the code, and handlers in place. It should
now be safe to enable the parity error interrupt. The parity error must
be unmasked in both the GTIMR, and the CS IMR. Unfortunately, the docs
aren't clear about this; nevertheless it's the truth.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On IVB hardware we are given an interrupt whenever a L3 parity error
occurs in the L3 cache. The L3 cache is used by internal GPU clients
only. This is a very rare occurrence (in fact to test this I need to
use specially instrumented silicon).
When a row in the L3 cache detects a parity error the HW generates an
interrupt. The interrupt is masked in GTIMR until we get a chance to
read some registers and alert userspace via a uevent. With this
information userspace can use a sysfs interface (follow-up patch) to
remap those rows.
Way above my level of understanding, but if a given row fails, it is
statistically more likely to fail again than a row which has not failed.
Therefore it is desirable for an operating system to maintain a lifelong
list of failing rows and always remap any bad rows on driver load.
Hardware limits the number of rows that are remappable per bank/subbank,
and should more than that many rows detect parity errors, software
should maintain a list of the most frequent errors, and remap those
rows.
V2: Drop WARN_ON(IS_GEN6) (Jesse)
DRM_DEBUG row/bank/subbank on errror (Jesse)
Comment updates (Jesse)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A 30 ms delay is simply way too big to waste cpu cycles on.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor,
but we have the identical code in ironlake_ccrtc_mode_set. And that
function is huge, so extracting some code full of magic numbers is
always nice.
Noticed while trying to get a handle on our dp clock code.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Already discovered in
commit 5a117db77e
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Thu Jan 5 09:34:29 2012 -0200
drm/i915: there is no pipe CxSR on ironlake
but we've failed to rip out the code from the ironlake specific code.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Weirdness around do_mmap() in there does not rely on ->mmap_sem for
exclusion, so no need to keep it under that. As the result, we can
turn that do_mmap() into vm_mmap().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
On IVB and older, we basically have two registers: the control and the
data register. We write a few consecutitve times to the control
register, and we need these writes to arrive exactly in the specified
order.
Also, when we're changing the data register, we need to guarantee that
anything written to the control register already arrived (since
changing the control register can change where the data register
points to). Also, we need to make sure all the writes to the data
register happen exactly in the specified order, and we also *can't*
read the data register during this process, since reading and/or
writing it will change the place it points to.
So invoke the "better safe than sorry" rule and just be careful and
put barriers everywhere :)
On HSW we still have a control register that we write many times, but
we have many data registers.
Demanded-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HSW support is now just like all the other generations: we send AVI
and SPD InfoFrames. There are other DIPs for HSW, but there are other
DIPs for the previous generations too. For each gen, we can see which
DIPs are missing by looking at the 'set_infoframes' function: we
explicitly disable the DIPs we're not using.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The register that controls the HDMI port can be used to control the
sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE
is one of those: HDMI ports that can't be used in sDVO mode don't even
have this bit defined in their specifications.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At this time, the HDMI port is enabled, and the DIP control register
specification says we need to disable the port *before* disabling the
DIPs. Also, while doing this we risk telling the HW to send the AVI
DIPs once (not every VSync), which really seems to confuse the HW and
trigger bugs where the DIPs are not sent.
This code was here just to set the DIP register to a 'known state'
before using it, but since now the set_infoframes functions already
set the control registers to a known state, this code can go away.
Also, the previous code disables *all* the DIP registers for *each*
HDMI port, so we end disabling each DIP register more than once.
This patch solves a problem I can reproduce on my IVB machine. When I
boot it with just a single HDMI monitor, the AVI InfoFrames are not
sent. With this patch, the InfoFrames are sent. Previously, I wrote a
patch to 'touch the DIP registers after we enable the HDMI port' to
solve this same problem, but that patch doesn't seem to be needed
anymore after this patch.
All this patch does is revert a chunk of the following commit:
commit 64a8fc0145
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Sep 22 11:16:00 2011 +0530
drm/i915: fix ILK+ infoframe support
So bugs that can be bisected to that commit may be fixed now.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43256
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The register specification says we need to do this.
V2: Only write the register if the port is enabled.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From this point on, the 'set_infoframe' functions always set the DIP
registers to a known state, so anything done will always be undone at
the modeset.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function is called when the pipe is disabled, so it always gets
the 50ms timeout.
This function is called once for each InfoFrame, so we actually get a
100ms timeout. Will be more if we add more InfoFrames.
Also, the spec says we need to "wait for a VSync to ensure completion
of any pending DIP transmissions", not for a VBlank. OTOH, the
register documentation suggests that the DIPs are sent *during* the
VSync, so shouldn't we be waiting until *after* the VSync to ensure
all DIPs are sent?
So this wait_for_vblank seems, besides useless, totally wrong.
If we ever want to change some specific InfoFrame on-the-fly (outside
of the modeset code), the code that changes the InfoFrame will have to
do the waiting itself, and properly.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So the write_infoframe function can assume the DIP is on.
V2: Be more defensive and add WARN().
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not once for each InfoFrame. Now we have a function that allows us to
do this.
[danvet: Paulo clarified on irc that a later bugfix patch needs this
cleanup.]
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need a function that is able to fully 'set' the state of the DIP
registers to a known state.
Currently, we have the write_infoframe function that is called twice:
once for AVI and once for SPD. The problem is that write_infoframe
tries to keep the state of the DIP register as it is, changing only
the minimum necessary bits. The second problem is that
write_infoframe does twice (once for each time it is called) some
work that should be done only once (like waiting for vblank and
setting the port). If we add even more DIPs, it will do even more
repeated work.
This patch only adds the infrastructure keeping the code behavior the
same as before.
v2: add static keywords
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we reset the ring control registers, including the HEAD and TAIL of
the ring, we also need to reset associated state. In this instance, we
were failing to reset the cached value of ring->last_retired_head and so
upon the first request for more space following a resume would
potentially (depending on a narrow race window) believe that the HEAD had
advanced much further than reality.
This is a regression from:
commit a71d8d9452
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Feb 15 11:25:36 2012 +0000
drm/i915: Record the tail at each request and use it to estimate the head
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org # 3.4
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Entirely new class of fail for this one. The detailed timings are for
normal CVT but the monitor really wanted CVT-R.
Bugzilla: http://bugzilla.redhat/com/516471
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: tune down the noise of the RP irq limit fail
drm/i915: Remove the error message for unbinding pinned buffers
drm/i915: Limit page allocations to lowmem (dma32) for i965
drm/i915: always use RPNSWREQ for turbo change requests
drm/i915: reject doubleclocked cea modes on dp
drm/i915: Adding TV Out Missing modes.
drm/i915: wait for a vblank to pass after tv detect
drm/i915: no lvds quirk for HP t5740e Thin Client
drm/i915: enable vdd when switching off the eDP panel
drm/i915: Fix PCH PLL assertions to not assume CRTC:PLL relationship
drm/i915: Always update RPS interrupts thresholds along with frequency
drm/i915: properly handle interlaced bit for sdvo dtd conversion
drm/i915: fix module unload since error_state rework
drm/i915: be more careful when returning -ENXIO in gmbus transfer
Only override the ddc bus if the connector doesn't have
a valid one. The existing code overrode the ddc bus for
all connectors even if it had ddc bus.
Fixes ddc on another XFX card with the same pci ids that
was broken by the quirk overwriting the correct ddc bus.
Reported-by: Mehdi Aqadjani Memar <m.aqadjanimemar@student.ru.nl>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The rest of the code uses stdint types, so use them in
drm_property_change_is_valid() as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Using the wrong union.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we hit an error here, then we should unlock and unreference obj
before returning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just move its only caller into the same file as it and make it static.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the
separate HDMI registers where introduced with the first PCH) and so
g4x_hdmi_connected() never selected the right bit and always returned
disconnected.
Regression in
commit 8ec22b214d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri May 11 18:01:34 2012 +0100
drm/i915/hdmi: Query the live connector status bit for G4x
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wait request is poorly named IMO. After working with these functions for
some time, I feel it's much clearer to name the functions more
appropriately.
Of course we must update the callers to use the new name as well.
This leaves room within our namespace for a *real* wait request function
at some point.
Note to maintainer: this patch is optional.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This helps implement GL_ARB_sync but stops short of allowing full blown
sync objects. Finally we can use the new timed seqno waiting function
to allow userspace to wait on a buffer object with a timeout. This
implements that interface.
The IOCTL will take as input a buffer object handle, and a timeout in
nanoseconds (flags is currently optional but will likely be used for
permutations of flush operations). Users may specify 0 nanoseconds to
instantly check.
The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
non-zero timeout parameter the wait ioctl will wait for the given number
of nanoseconds on an object becoming unbusy. Since the wait itself does
so holding struct_mutex the object may become re-busied before this
completes. A similar but shorter race condition exists in the busy
ioctl.
v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
Flush the object from the gpu write domain (Chris + Daniel)
Fix leaked refcount in good case (Chris)
Naturally align ioctl struct (Chris)
v3: Drop lock after getting seqno to avoid ugly dance (Chris)
v4: check for 0 timeout after olr check to allow polling (Chris)
v5: Updated the comment. (Chris)
v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
Fix the commit message comment to be less ugly (Ben)
Add a warning to check the return timespec (Ben)
v7: Use DRM_AUTH for the ioctl. (Eugeni)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We still don't understand why this fails exactly, but if fails way
too often for a simple debug information. Furthermore the current
ducttape should prevent the gpu from getting stuck at low frequencies.
Hence tune down the dmesg noise.
Note that the known failure case is that the register read returns 0
when the gpu gets confused.
v2: Add comments about the known failure case.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is now used intentionally to prevent proliferation of is-pinned
checks upon the inactive list following:
commit 1b50247a8d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 24 15:47:30 2012 +0100
drm/i915: Remove the list of pinned inactive objects
Reported-and-tested-by: guang.a.yang@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50075
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Broadwater and Crestline share a limitation that prevent it from
relocating general surface state above 4GiB. The only recourse we have
since any buffer object may be used as a relocation target is then to
limit all object allocations on 965g[m] to DMA32.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The trace events adds whether or not the wait was blocking. Blocking in
this case means to hold struct_mutex (ie. no new work can be submitted
during the wait). The information is inherently racy.
The blocking information is racy since mutex_is_locked doesn't check
that the current thread holds the lock. The only other option would be
to pass the boolean information of whether or not the class was blocking
down through the stack which is less desirable.
v2: Don't do a trace event per loop. (Chris)
Only get blocking/non-blocking info (Chris)
v3: updated comment in code as well as commit msg (Daniel)
Add "(NB)" to trace information to remind us in 6 months (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Insert a wait parameter in the code so we can possibly timeout on a
seqno wait if need be. The code should be functionally the same as
before because all the callers will continue to retry if an arbitrary
timeout elapses.
We'd like to have nanosecond granularity, but the only way to do this is
with hrtimer, and that doesn't fit well with the needs of this code.
v2: Fix rebase error (Chris)
Return proper time even in wedged + signal case (Chris + Ben)
Use timespec constructs (Ben)
Didn't take Daniel's advice regarding the Frankenstein-ness of the
function. I did try his advice, but in the end I liked the way the
original code looked, better.
v3: Make wakeups far less frequent for infinite waits (Chris)
v4: Remove dummy_wait variable (Daniel)
Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben)
Added a couple of warnings (Ben)
v5: Remove warnings (Daniel)
Use more accurate time diff for default case (Daniel)
Bikeshed for setting the return timespec in timeout case (Daniel)
s/jiffies/time in one of the comments
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull main drm updates from Dave Airlie:
"This is the main merge window request for the drm.
It's big, but jam packed will lots of features and of course 0
regressions. (okay maybe there'll be one).
Highlights:
- new KMS drivers for server GPU chipsets: ast, mgag200 and cirrus
(qemu only). These drivers use the generic modesetting drivers.
- initial prime/dma-buf support for i915, nouveau, radeon, udl and
exynos
- switcheroo audio support: so GPUs with HDMI can turn off the sound
driver without crashing stuff.
- There are some patches drifting outside drivers/gpu into x86 and
EFI for better handling of multiple video adapters in Apple Macs,
they've got correct acks except one trivial fixup.
- Core:
edid parser has better DMT and reduced blanking support,
crtc properties,
plane properties,
- Drivers:
exynos: add 2D core accel support, prime support, hdmi features
intel: more Haswell support, initial Valleyview support, more
hdmi infoframe fixes, update MAINTAINERS for Daniel, lots of
cleanups and fixes
radeon: more HDMI audio support, improved GPU lockup recovery
support, remove nested mutexes, less memory copying on PCIE, fix
bus master enable race (kexec), improved fence handling
gma500: cleanups, 1080p support, acpi fixes
nouveau: better nva3 memory reclocking, kepler accel (needs
external firmware rip), async buffer moves on nv84+ hw.
I've some more dma-buf patches that rely on the dma-buf merge for vmap
stuff, and I've a few fixes building up, but I'd decided I'd better
get rid of the main pull sooner rather than later, so the audio guys
are also unblocked."
Fix up trivial conflict due to some duplicated changes in
drivers/gpu/drm/i915/intel_ringbuffer.c
* 'drm-core-next' of git://people.freedesktop.org/~airlied/linux: (605 commits)
drm/nouveau/nvd9: Fix GPIO initialisation sequence.
drm/nouveau: Unregister switcheroo client on exit
drm/nouveau: Check dsm on switcheroo unregister
drm/nouveau: fix a minor annoyance in an output string
drm/nouveau: turn a BUG into a WARN
drm/nv50: decode PGRAPH DATA_ERROR = 0x24
drm/nouveau/disp: fix dithering not being enabled on some eDP macbooks
drm/nvd9/copy: initialise copy engine, seems to work like nvc0
drm/nvc0/ttm: use copy engines for async buffer moves
drm/nva3/ttm: use copy engine for async buffer moves
drm/nv98/ttm: add in a (disabled) crypto engine buffer copy method
drm/nv84/ttm: use crypto engine for async buffer copies
drm/nouveau/ttm: untangle code to support accelerated buffer moves
drm/nouveau/fbcon: use fence for sync, rather than notifier
drm/nv98/crypt: non-stub implementation of the engine hooks
drm/nouveau/fifo: turn all fifo modules into engine modules
drm/nv50/graph: remove ability to do interrupt-driven context switching
drm/nv50: remove manual context unload on context destruction
drm/nv50: remove execution engine context saves on suspend
drm/nv50/fifo: use hardware channel kickoff functionality
...
Media turbo requests can either use RPVSWREQ or RPNSWREQ to indicate
what the interrupt handler should do. Since we only deal with the
latter in our turbo code, make the media engine use that for turbo
requests.
Cc: stable@vger.kernel.org.
Tested-by: Joe Bloggsian <joebloggsian@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These are ultra-low-res modes used to upscale SDTV content and we
don't know how to support these on dp on intel hw:
- It's unclear whether we can send avi infoframes over dp ports.
- And the pixel repeat setting that work for hdmi/sdvo explicitly
don't work for dp.
So don't bother and just reject these modes. These modes have been
introduced in
commit 54ac76f851
Author: Christian Schmidt <schmidt@digadd.de>
Date: Mon Dec 19 14:53:16 2011 +0000
drm/edid: support CEA video modes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
Tested-by: Yuang Guang <guang.a.yang@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These 2 modes were removed by mistake during a clean up.
So, now it is time to add them back. For further info about
supported mode and standard timing table please check:
VOL_3_display_registers_updated.pdf at intellinuxgraphics.org.
Note that this regression has been introduce in
commit 55a6713b3f
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date: Thu Dec 15 14:47:33 2011 -0200
drm/i915: Removing TV Out modes.
and this commit partially reverts it by re-adding the wrongly removed
modes.
Reported-by: Robert Lowery <rglowery@exemail.com.au>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Pimped commit message to cite the commit that introduced this
regression.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise the hw will get confused and result in a black screen.
This regression has been most likely introduce in
commit 974b93315b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Sep 5 00:44:20 2010 +0100
drm/i915/tv: Poll for DAC state change
That commit replace the first msleep(20) with a busy-loop, but failed
to keep the 2nd msleep around. Later on we've replaced all these
msleep(20) by proper vblanks.
For reference also see the commit in xf86-video-intel:
commit 1142be53eb8d2ee8a9b60ace5d49f0ba27332275
Author: Jesse Barnes <jbarnes@hobbes.lan>
Date: Mon Jun 9 08:52:59 2008 -0700
Fix TV programming: add vblank wait after TV_CTL writes
Fxies FDO bug #14000; we need to wait for vblank after
writing TV_CTL or following "DPMS on" calls may not actually enable the output.
v2: As suggested by Chris Wilson, add a small comment to ensure that
no one accidentally removes this vblank wait again - there really
seems to be no sane explanation for why we need it, but it is
required.
Launchpad: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688
Reported-and-Tested-by: Robert Lowery <rglowery@exemail.com.au>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have one bug report from a validation team that we get the eDP
panel sequencing still somewhat wrong: We need to enable VDD while
switching off the panel and backlight. Unfortunately that reporter
seems to have fallen off the earth :(
For another reporter this actually fixes a black panel issue because
without this the backlight/panel gets confused and doesn't light up
again.
v2: I've forgotten to remove the vdd_off call in panel_off which is
now bogus. This essentially reverts
commit 17038de5f1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Apr 16 22:43:42 2012 +0100
drm/i915/dp: Flush any outstanding work to turn the VDD off
v3: the current panel_off code forces off the vdd power, too. Which is
bogus and resulted in some funny warnings later on when we've tried to
do aux channel communications with just the vdd forced on. Fix this,
too.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163
Tested-by: Vincent Frentzel <zcecc22@gmail.com>
Cc: stable@kernel.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The existing assertions were written under the assumption that we wanted
to test the related PLL to a CRTC. With the split of PLL into a
separately managed entity which may be shared amongst CRTCs, we need to
pass in both the CRTC and the PLL to the assertion routine.
Occassionally, this means passing NULL for the CRTC as we wish to check
the status of the PLL irrespective of the current CRTC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to avoid missed down-interrupts when coming out of RC6, it is
advised that we always reset the down-threshold upon a PM event. This is
due to that the PM unit goes through a little dance when coming out of
RC6, it first brings the GPU up at the lowest frequency then a short
time later it restores the thresholds. During that interval, the
down-interval may expire and the interrupt be suppressed.
Now aware of the dance taking place within the GPU when coming out of
RC6, one wonders what other writes need to be queued in the fifo buffer
in order to be properly sequenced; setting the RP state appears to be
one.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44006
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've simply ignored this, which isn't too great. With this, interlaced
1080i works on my HDMI screen connected through sdvo. For no apparent
reason anything else still doesn't work as it should.
While at it, give these magic numbers in the dtd proper names and
add a comment that they match with EDID detailed timings.
v2: Actually use the right bit for interlaced.
Tested-by: Peter Ross <pross@xvid.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently nouveau only registers as a vga_switcheroo client, but never
unregisters. This patch adds the necessary unregister calls.
Signed-off-by: Andreas Heider <andreas@meetr.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Currently vga_switcheroo_unregister_handler is called unconditionally when
nouveau is unloaded, even when nouveau never registered a handler. This
interferes with other switcheroo handlers, as vga_switcheroo doesn't check who
called unregister_handler, but simply unregisters the current handler. This
patch adds a check so unregister is only called if a handler was registered by
nouveau before.
Signed-off-by: Andreas Heider <andreas@meetr.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Disabled for the moment until some performance issues are sorted out, code
committed as a reference point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Been tested on each major revision that's relevant here, but I'm sure there
are still bugs waiting to be ironed out.
This is a *very* invasive change.
There's a couple of pieces left that I don't like much (eg. other engines
using fifo_priv for the channel count), but that's an artefact of there
being a master channel list still. This is changing, slowly.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
All the places this stuff is actually needed tends to be chipset-specific
anyway, so we're able to just inline the register bashing instead.
The parts of the common code that still directly touch PFIFO temporarily
have conditionals, these will be removed in subsequent commits that will
refactor the fifo modules into engine modules like graph/mpeg etc.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Now have a somewhat simpler semaphore sync implementation for nv17:nv84,
and a switched to using semaphores as fences on nv84+ and making use of
the hardware's >= acquire operation.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Just a cleanup more or less, and to remove the need for special handling of
software objects.
This removes a heap of documentation on dma/graph object formats. The info
is very out of date with our current understanding, and is far better
documented in rnndb in envytools git.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This shouldn't be necessary, I believe this is just a bit of missed debug
code that got left over somehow.
Causes flips to be always synced to vblank, regardless of swap interval,
which we don't want..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The conditional definition of the generation helper functions apparently
confuses some IDEs....
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Depending on exact point of failure, not cleaning would lead to
BUG_ONs/oopses in various distant places.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Port change from "drm/nouveau: Keep RAMIN heap within the channel"
to kernel channel, which has its own ramin heap initialisation.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Younes Manton <younes.m@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Kepler GRAPH has (well, sorta) fixed subchannel<->class assignments, make
this match up to keep it happy without trapping.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This may, perhaps, get re-merged with nvc0_graph.c at some point. It's
still unclear as to how great an idea that'd be. Stay tuned...
Completely dependent on firmware blobs from NVIDIA binary driver currently.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not entirely convinced 0x004018 transitions are correct yet, but, it's
an improvement.
The 750MHz value comes from fiddling with the binary driver + coolbits on
two different DDR3 NVA8 chipsets (T510 NVS3100M, and NVS300), not a clue
where this number comes from.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Probably not quite right, but this is enough now to make NVS300 reclock
between all 3 of its perflvls correctly.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This probably wants a cleanup, but I'm holding off until I know for sure
how the rest of the things that need doing fit together.
Tested on NVS300 by hacking up perflvl 1 to require PLL mode, and switching
between perflvl 3 and 1.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The binary driver appears to do various bits and pieces of the memory
clock frequency change at different times, depending on the particular
transition that's occuring. I've attempted to replicate this here
for div->pll, pll->div and div->div transitions.
With some additional (patches upcoming) magic regs being bashed, this
allows me to correctly transition between all 3 perflvls on NVS300.
pll->pll transitions will *not* work correctly at the moment, pending
me tricking the binary driver into doing one and seeing how to correctly
handle it.
This patch also handles (hopefully) 0x1110e0, which appears to need
changing depending on whether in PLL or divider mode.. Maybe. We'll
see.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The reg calculation may get moved elsewhere at some point, but lets
figure out what exactly we need to do first.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This adds prime->fd and fd->prime support to radeon.
It passes the sg object to ttm and then populates
the gart entries using it.
Compile tested only.
v2: stub kmap + use new helpers + add reimporting
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds handle->fd and fd->handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.
v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.
Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.
Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.
Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).
Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.
v3: Right when I've hit sent I've noticed that I've screwed up one
obj->sg_list (for dmar support) and obj->sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.
v4: fix the error reporting bugs pointed out by ickle.
v5: fix another error, and stop non-gtt mmaps on shared objects
stop pread/pwrite on imported objects, add fake kmap
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds prime->fd and fd->prime support to nouveau,
it passes the SG object to TTM, and then populates the
GART entries using it.
v2: add stubbed kmap + use new function to fill out pages array
for faulting + add reimport test.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the ability for ttm common code to take an SG table
and use it as the backing for a slave TTM object.
The drivers can then populate their GTT tables using the SG object.
v2: make sure to setup VM for sg bos as well.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
udl can only be used as an output offload so doesn't need to support
handle->fd direction.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If userspace attempts to import a buffer it exported on the same device,
we need to return the same GEM handle for it, not a new handle pointing
at the same GEM object.
v2: move removals into a single fn, no need to set to NULL. (Chris Wilson)
Signed-off-by: Dave Airlie <airlied@redhat.com>
the ttm drivers need this currently, in order to get fault handling
working and efficient.
It also allows addrs to be NULL for devices like udl.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull trivial updates from Jiri Kosina:
"As usual, it's mostly typo fixes, redundant code elimination and some
documentation updates."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (57 commits)
edac, mips: don't change code that has been removed in edac/mips tree
xtensa: Change mail addresses of Hannes Weiner and Oskar Schirmer
lib: Change mail address of Oskar Schirmer
net: Change mail address of Oskar Schirmer
arm/m68k: Change mail address of Sebastian Hess
i2c: Change mail address of Oskar Schirmer
net: Fix tcp_build_and_update_options comment in struct tcp_sock
atomic64_32.h: fix parameter naming mismatch
Kconfig: replace "--- help ---" with "---help---"
c2port: fix bogus Kconfig "default no"
edac: Fix spelling errors.
qla1280: Remove redundant NULL check before release_firmware() call
remoteproc: remove redundant NULL check before release_firmware()
qla2xxx: Remove redundant NULL check before release_firmware() call.
aic94xx: Get rid of redundant NULL check before release_firmware() call
tehuti: delete redundant NULL check before release_firmware()
qlogic: get rid of a redundant test for NULL before call to release_firmware()
bna: remove redundant NULL test before release_firmware()
tg3: remove redundant NULL test before release_firmware() call
typhoon: get rid of redundant conditional before all to release_firmware()
...
The omapdrm driver uses this for setting per-overlay rotation. It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A bitmask property is similar to an enum. The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).
[airlied: 1LL -> 1ULL]
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung:
drm/exynos: add G2D driver
drm/exynos: added vp scaling feature for hdmi
drm/exynos: added source size to overlay structure
drm/exynos: add additional display mode for hdmi
drm/exynos: enable dvi mode for dvi monitor
drm/exynos: fixed wrong pageflip finish event for interlace mode
drm/exynos: add PM functions for hdmi and mixer
drm/exynos: add dpms for hdmi
drm/exynos: use threaded irq for hdmi hotplug
drm/exynos: use platform_get_irq_byname for hdmi
drm/exynos: cleanup for hdmi platform data
drm/exynos: added a feature to get gem buffer information.
drm/exynos: added drm prime feature.
drm/exynos: added cache attribute support for gem.
vgaarb: Provide dummy default device functions
Drivers for hardware without gamma support should not be forced to
implement a no-op gamma set operation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DRM mode config functions structure declared by drivers and pointed
to by the drm_mode_config funcs field is never modified. Make it a const
pointer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Rob Clark <rob.clark@linaro.org>
Reviwed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The GEM vm operations structure is passed to the VM core that stores it
in a const field. There vm operations structures can thus be const in
DRM as well.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <rob.clark@linaro.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A race condition exists in drm_vblank_cleanup() if the vblank disable
timer callback runs after freeing the memory that its callback function
tries to access. Fix this by deleting the timer synchronously.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The power field was never correctly initialized.
[airlied: just took the two drm specific bits]
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Poulsbo needs a physical address in the cursor base register. We allocate a
stolen memory buffer and copy the cursor image provided by userspace into it.
When/If we get our own userspace driver we can map this stolen memory directly.
The patch also adds a mark in chip ops so we can identify devices that has this
requirement.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some devices don't have a panel connected to LVDS and thus will never power up.
This patch checks the power sequence progress bits in PP_STATUS to prevent an
endless loop on such devices.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This seems to be wrong to me, spotted while thinking about dma-buf.
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Unfortunately we can't abort a mode_set, but at least tell the user
that something might have gone wrong when setting the sdvo input or
output timing fails.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- kill intel_sdvo->input_dtd, it's only used as a temporary variable,
we store the preferred input mode in the adjusted mode at mode_fixup
time.
- rename the function to make it clear what we want it to do (get the
preferred mode) and say in a comment what it unfortunately does as a
side-effect (set the new output timings).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to remove the debugfs file. Regression introduce in
commit d54423037f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 27 15:17:40 2012 +0200
drm/i915: allow the existing error_state to be destroyed
Reported-and-Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... flaky ddc hardware can cause a spurious NAK, resulting in the i2c
core and drm edid functions not trying to retry the edid transfer.
Luckily the gmbus quiescenting also times out for these cases, so we
can get out of this mess by returning -ETIMEDOUT for this specific
case. This way we keep the fast-fail of returning -ENXIO if there is
no device present, speeding up the boot process.
This regression has been introduced in
commit e646d57735
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Fri Mar 30 19:46:38 2012 +0800
drm/i915/intel_i2c: always wait for IDLE before clearing NAK
v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs,
suggested by Daniel Kurtz.
Cc: Daniel Kurtz <djkurtz@chromium.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518
Reported-and-Tested-by: Julian Simioni <julian.simioni@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to
whether the connector is active prior to attempting to retrieve the EDID.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note that gen3 is the only platform where we've got the bit
definitions right, hence the workaround of disabling sdvo hotplug
support on i945g/gm is not due to misdiagnosis of broken hotplug irq
handling ...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: add some blurb about sdvo hotplug fail on i945g/gm I've
wondered about while reviewing.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The status bits corresponding to the interrupt enable bits are the
"live" hotplug status bits, and reflect the current status of the port
(high for a detected connection, low for a disconnect). The actual bits
corresponding to the interrupt source are elsewhere. The actual event is
then determined by a combination of the interrupt flag and the current
live status (if the interrupt is active, but the current status is not,
then we have detected a disconnect.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also as we set the HOTPLUG_EN to 0 during pre-install, we can simply set
it during post-install, and nor do we wish to enable unwanted hotplug
events.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel wrote:
The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly
bugfixes:
- last few patches for basic hsw enabling (Eugeni, infoframe support by
Paulo)
- Fix up infoframe support, we've hopefully squashed all the cargo-culting
in there (Paulo). Among all the issues, this finally fixes some of the
infoframe regressions seen on g4x and snb systems.
- Fixup sdvo infoframe support, this fixes a regression from 2.6.37.
- Correctly enable semaphores on snb, we've enabled it already for 3.5,
but the dmar check was slightly wrong.
- gen6 irq fixlets from Chris.
- disable gmbus on i830, the hw seems to be simply broken.
- fix up the pch pll fallout (Chris & me).
- for_each_ring macro from Chris - I've figured I'll merge this now to
avoid backport pain.
- complain when the rps state isn't what we expect (Chris). Note that this
is shockingly easy to hit and hence pretty much will cause a regression
report. But it only tells us that the gpu turbo state got out of whack,
a problem we know off since a long time (it cause the gpu to get stuck a
a fixed frequency, usually the lowest one). Chris is working on a fix,
but we haven't yet found a magic formula that works perfectly (only
patches that massively reduce the frequency of this happening).
- MAINTAINERS patch, I'm now officially the guy to beat up."
* tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits)
drm/i915: IBX has a fixed pch pll to pch pipe mapping
drm/i915: implement hsw_write_infoframe
drm/i915: small hdmi coding style cleanups
drm/i915: fixup infoframe support for sdvo
drm/i915: Enable the PCH PLL for all generations after link training
drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN
drm/i915: don't clobber the pipe param in sanitize_modesetting
drm/i915: disable gmbus on i830
drm/i915: Replace the feature tests for BLT/BSD with ring init checks
drm/i915: Check whether the ring is initialised prior to dispatch
drm/i915: Introduce for_each_ring() macro
drm/i915: Assert that the transcoder is indeed off before modifying it
drm/i915: hook Haswell devices in place
drm/i915: prepare HDMI link for Haswell
drm/i915: move HDMI structs to shared location
drm/i915: add WR PLL programming table
drm/i915: add support for DDI-controlled digital outputs
drm/i915: detect digital outputs on Haswell
drm/i915: program iCLKIP on Lynx Point
drm/i915: program WM_LINETIME on Haswell
...
This should fix breakage introduced in
commit ee7b9f93fd
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Apr 20 17:11:53 2012 +0100
drm/i915: manage PCH PLLs separately from pipes
v2: Add a DRM_DEBUG_KMS message to explain why a given pll was
selected, suggested by Chris Wilson.
v3: Actually run git add.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both the control and data registers are completely different now.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Changed the coding style of auxiliary infoframe functions to make
them smaller
- Fixed the column alignment of some function definitions
- Remove definition of "struct drm_crtc" in some places as they're
used only to retrieve "struct intel_crtc"
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least the worst offenders:
- SDVO specifies that the encoder should compute the ecc. Testing also
shows that we must not send the ecc field, so copy the dip_infoframe
struct to a temporay place and avoid the ecc field. This way the avi
infoframe is exactly 17 bytes long, which agrees with what the spec
mandates as a minimal storage capacity (with the ecc field it would
be 18 bytes).
- Only 17 when sending the avi infoframe. The SDVO spec explicitly
says that sending more data than what the device announces results
in undefined behaviour.
- Add __attribute__((packed)) to the avi and spd infoframes, for
otherwise they're wrongly aligned. Noticed because the avi infoframe
ended up being 18 bytes large instead of 17. We haven't noticed this
yet because we don't use the uint16_t fields yet (which are the only
ones that would be wrongly aligned).
This regression has been introduce by
3c17fe4b8f is the first bad commit
commit 3c17fe4b8f
Author: David Härdeman <david@hardeman.nu>
Date: Fri Sep 24 21:44:32 2010 +0200
i915: enable AVI infoframe for intel_hdmi.c [v4]
Patch tested on my g33 with a sdvo hdmi adaptor.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI)
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Hidden away within one chipset specific path was the necessary logic to
turn on the PLL. This needs to be done everywhere in order for us to
drive any display! As such as soon as we tested on a non-CougarPoint
chipset, we failed to bring up any DisplayPorts and generated a nice set
of assertion failures in the process. At least one part of our logic is
working, the part that assumes that we have no idea what we are doing.
Reported-by: guang.a.yang@intel.com
References: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Turn a fatal lockup into a merely blank display with lots of shouty
messages.
v2: Whilst in the area, convert the other BUG_ON into less fatal errors.
In particular, note that we may be called on a PCH platform not using
PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... we need it later on in the function to clean up pipe <-> plane
associations. This regression has been introduced in
commit f47166d2b0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Mar 22 15:00:50 2012 +0000
drm/i915: Sanitize BIOS debugging bits from PIPECONF
Spotted by staring at debug output of an (as it turns out) totally
unrelated bug.
v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
Chris Wilson.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Cc: stable@kernel.org (the regression was Cc: stable, too)
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hw just returns garbage.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838
Reported-and-tested-by: Vladyslav <DFEW.Entwickler@googlemail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When userspace asks whether the driver supports the BLT or BSD rings for
this chip, simply report whether those particular rings are initialised
v2: Use intel_ring_initialized()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than use the magic feature tests HAS_BLT/HAS_BSD just check
whether the ring we are about to dispatch the execbuffer on is
initialised.
v2: Use intel_ring_initialized()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In many places we wish to iterate over the rings associated with the
GPU, so refactor them to use a common macro.
Along the way, there are a few code removals that should be side-effect
free and some rearrangement which should only have a cosmetic impact,
such as error-state.
Note that this slightly changes the semantics in the hangcheck code:
We now always cycle through all enabled rings instead of
short-circuiting the logic.
v2: Pull in a couple of suggestions from Ben and Daniel for
intel_ring_initialized() and not removing the warning (just moving them
to a new home, closer to the error).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added note to commit message about the small behaviour
change, suggested by Ben Widawsky.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Inspired by a recent regression that seems to confuse pch transcoder
state, let's be a bit more paranoid.
References: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Pimped commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.
Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
programming instead of HDMI-specific registers.
This commit take advantage of the WR PLL clock table which is in a
separate (previous) commit to select the right divisors for each mode.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move intel_hdmi data structure and support functions to a shared location,
to allow their usage from intel_ddi module.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.
Note that this table is a temporary solution for WR PLL programming. It
will be reworked into a more exact algorithm at a later stage. But for
now, it provides the most accurate clock setting solution, so we use it
here.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
