Chris Wilson [Sun, 13 Oct 2013 11:56:31 +0000 (12:56 +0100)]
drm/i915: Add breadcrumbs for why the backlight is being set
At the moment we have 3 paths that lead to actually_set_backlight(),
from modesetting, ACPI/OpRegion requests and our very own
intel_backlight interface, and we have no way of distinguishing them in
the debug log. So add a debug breadcrumb to explain the source of the
backlight changes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 25 Sep 2013 16:55:26 +0000 (19:55 +0300)]
drm/i915: Fix pre-CTG vblank counter
The old style frame counter increments at the start of active video.
However for i915_get_vblank_counter() we want a counter that increments
at the start of vblank.
Fortunately the low frame counter register also contains the pixel
counter for the current frame. We can can compare that against the
vblank start pixel count to determine if we need to increment the
frame counter by 1 to get the correct answer.
Also reorganize the function pointer assignments in intel_irq_init() a
bit to avoid confusing people.
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 9 Oct 2013 07:18:51 +0000 (09:18 +0200)]
drm/i915: Kconfig option to disable the legacy fbdev support
Boots Just Fine (tm)!
The only glitch seems to be that at least on Fedora the boot splash
gets confused and doesn't display much at all.
And since there's no ugly console flickering anymore in between, the
flicker while switching between X servers (VT support is still enabled)
is even more jarring.
Also, I'm unsure whether we don't need to somehow kick out vgacon, now
that nothing else gets in the way. But stuff seems to work, so I
don't care. Also everything still works as well with VGA_CONSOLE=n
Also the #ifdef mess needs a bit of a cleanup, follow-up patches will
do just that.
To keep the Kconfig tidy, extract all the i915 options into its own
file.
v2:
- Rebase on top of the preliminary hw support option and the
intel_drv.h cleanup.
- Shut up warnings in i915_debugfs.c
v3: Use the right CONFIG variable, spotted by Chon Ming.
Cc: Lee, Chon Ming <chon.ming.lee@intel.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 8 Oct 2013 15:44:47 +0000 (17:44 +0200)]
drm: Add separate Kconfig option for fbdev helpers
For drivers which might want to disable fbdev legacy support.
Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.
v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!
v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.
Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Dave Airlie <airlied@linux.ie> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 11 Oct 2013 11:21:31 +0000 (14:21 +0300)]
drm/i915: Fix pipe off timeout handling for pre-gen4
The current pre-gen4 pipe off code might break out of the loop
due to the timeout, but then the fail to print the warning.
Refactor the code a bit to use wait_for() to avoid the problem,
and that we also re-check the condition after the timeout has
expired.
v2: Use wait_for()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 9 Oct 2013 19:39:57 +0000 (16:39 -0300)]
drm/i915: increase the SWSCI DSLP default timeout to 50ms
The spec says the default timeout should be 2ms, but on my machine
this doesn't seem to be enough. Sometimes it works, sometimes I get
these messages when booting:
- SWSCI request timed out
- SWSCI request already in progress
And my guess is that the "already in progress" message is because the
first one is still happening.
I did some experiments on my machine (that has CONFIG_HZ=1000) and the
wait_for function usually takes 4-6 jiffies to finish, but I've seen
up to 9. So increase the timeout to 50ms. We only expect to wait for
the actual amount of time the operation takes, so even a huge timeout
shouldn't delay us more than what the hardware actually requires.
Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 10 Oct 2013 20:58:50 +0000 (21:58 +0100)]
drm/i915: Avoid tweaking RPS before it is enabled
As we delay the initial RPS enabling (upon boot and after resume), there
is a chance that we may start to render and trigger RPS boosts before we
set up the punit. Any changes we make could result in inconsistent
hardware state, with a danger of causing undefined behaviour. However,
as the boosting is a optional tweak to RPS, we can simply ignore it
whilst RPS is not yet enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Thu, 10 Oct 2013 12:25:37 +0000 (15:25 +0300)]
drm/i915: tell the user KMS is required for gen6+
Educate the users why i915 won't load on gen6+ and nomodeset.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=61671 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 9 Oct 2013 17:22:22 +0000 (19:22 +0200)]
drm/i915: Educate users in dmesg about reporting gpu hangs
Untangling me-too reports that actually aren't is really messy. And we
need to make sure the blame is put where it should be right from the
start ;-)
v2: Improve the wording from Ben's suggestions.
Cc: Ben Widawsky <ben@bwidawsk.net> Acked-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Frob the message as suggested by Paulo on irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tom O'Rourke [Mon, 16 Sep 2013 21:56:43 +0000 (14:56 -0700)]
drm/i915: Finish enabling rps before use by sysfs or debugfs
Enabling rps (turbo setup) was put in a work queue because it may
take quite awhile. This change flushes the work queue to initialize
rps values before use by sysfs or debugfs. Specifically,
rps.delayed_resume_work is flushed before using rps.hw_max,
rps.max_delay, rps.min_delay, or rps.cur_delay.
This change fixes a problem in sysfs where show functions using
uninitialized values show incorrect values and store functions
using uninitialized values in range checks incorrectly fail to
store valid input values. This change also addresses similar use
before initialized problems in debugfs.
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 10 Oct 2013 08:37:19 +0000 (09:37 +0100)]
drm/i915: Capture the initial error-state when kicking stuck rings
We lost the ability to capture the first error for a stuck ring in the
recent hangcheck robustification. Whilst both error states are
interesting (why does the GPU not recover is also essential to debug),
our primary goal is to fix the initial hang and so we need to capture
the first error state upon taking hangcheck action.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 9 Oct 2013 14:24:58 +0000 (17:24 +0300)]
drm/i915: Rename primary_disabled to primary_enabled
Let's try to avoid these confusing negated booleans.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 9 Oct 2013 16:52:36 +0000 (13:52 -0300)]
drm/i915: don't leak dp_connector at intel_ddi_init
Regression introduced by:
commit 311a20949f047a70935d6591010f42336f5402e7
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
drm/i915: don't init DP or HDMI when not supported by DDI port
Since the commit above it is possible to have a DDI encoder that has
the HDMI connector but not the DP connector (in case the port doesn't
support DP). In this case, we must properly free the DP connector.
We just leak this once, so it's not a big deal.
Reported by kmemleak.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Fri, 4 Oct 2013 12:08:48 +0000 (15:08 +0300)]
drm/i915/dp: update training set in a burst write with training pattern set
The DP spec allows this, and requires it when full link training is
started with non-minimum voltage swing and/or non-zero pre-emphasis.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Tue, 8 Oct 2013 23:31:03 +0000 (16:31 -0700)]
drm/i915: Do PCH and uncore init earlier
For future platforms we'll need to initialize our MMIO function pointers
even earlier. Specifically, we'll need to be able to have register
reads/writes at GTT initialization (in i915_gem_gtt_init). Similarly,
these platforms also have MMIO differences based on the PCH id, so
while moving stuff around, also move the PCH initialization.
CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Mention the function where we need register access.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Thu, 19 Sep 2013 20:03:06 +0000 (17:03 -0300)]
drm/i915: wait for IPS_ENABLE when enabling IPS
At the end of haswell_crtc_enable we have an intel_wait_for_vblank
with a big comment, and the message suggests it's a workaround for
something we don't really understand. So I removed that wait and
started getting HW state readout error messages saying that the IPS
state is not what we expected.
I investigated and concluded that after you write IPS_ENABLE to
IPS_CTL, the bit will only actually become 1 on the next vblank. So
add code to wait for the IPS_ENABLE bit. We don't really need this
wait right now due to the wait I already mentioned, but at least this
one has a reason to be there, while the other one is just to
workaround some problem: we may remove it in the future.
The wait also acts as a POSTING_READ which we missed.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 8 Oct 2013 17:39:29 +0000 (19:39 +0200)]
drm/i915: Keep intel_drv.h tidy
Something already got misplaced (although it's from a patch from
before Paulo's cleanup). Move it to the right spot.
v2: Remove the line to keep a neat block, requested by Paulo.
Reported-by: Paulo Zanoni <przanoni@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sun, 6 Oct 2013 00:57:11 +0000 (17:57 -0700)]
drm/i915: Remove gen specific checks in MMIO
Now that MMIO has been split up into gen specific functions it is
obvious when HAS_FPGA_DBG_UNCLAIMED, HAS_FORCE_WAKE are needed. As such,
we can remove this extraneous condition.
As a result of this, as well as previously existing function pointers
for forcewake, we no longer need the has_force_wake member in the device
specific data structure.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sat, 5 Oct 2013 04:22:54 +0000 (21:22 -0700)]
drm/i915: Create GEN specific write MMIO
Similar to the previous patch which implemented GEN specific reads; this
patch does the same for writes. Writes have a bit of adding complexity
due to the FPGA_DBG feature of HSW plus:
gen[2-4]: nothing special
gen5: ILK dummy write
gen[6-7]: forcewake shenanigans
gen[HSW}: forcewake shenanigans + FPGA_DBG
I was a bit torn about whether or not to combine 6-HSW as one function,
since the FPGA_DBG is cleanly separated, and it wouldn't make the 6-7
MMIO too messy. In the end, I chose the clearest possible solution which
splits out HSW.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sat, 5 Oct 2013 04:22:53 +0000 (21:22 -0700)]
drm/i915: Create GEN specific read MMIO
Extracting the MMIO read functionality makes per gen handling a bit
simpler, and the overall function a lot easier to read. The increasing
complexity of reads doesn't get too bad as the generation number
increases:
gen[2-4]: Nothing special
gen5: ILK dummy write workaround
gen6+: forcewake shenanigans
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sat, 5 Oct 2013 04:22:51 +0000 (21:22 -0700)]
drm/i915: Create MMIO virtual functions
In preparation for having per GEN MMIO functions, create, and start
using MMIO functions in our uncore data structure. This simply makes the
transition easier by allowing us to just plug in the per GEN stuff
later.
For simplicity, I moved the intel_uncore_init() function down since
those rely on static functions defined lower in the file. This is most
of the churn in this patch.
I made one unrelated change here by using off_t datatype for the offset
of the register to write. I like the clarity that this brings to the
code. If I did it as a separate patch, I am pretty certain it would get
bikeshedded to oblivion.
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sat, 5 Oct 2013 04:22:50 +0000 (21:22 -0700)]
drm/i915: Move edram detection early_sanitize
In order to be able to have virtual functions for the MMIO, we need to
use the raw access function. To keep things simple, just move this to
our early_sanitize code in uncore.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 8 Oct 2013 10:25:41 +0000 (12:25 +0200)]
drm/i915: rip out gen2 reset code
At least on my i830M here it reliably results in hard system hangs
nowadays. This is much worse than falling back to software rendering,
so I think we should simply rip this out.
After all we don't have any gpu reset for gen3 either, and there are a
lot more of those still around.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 8 Oct 2013 10:16:59 +0000 (11:16 +0100)]
drm/i915: Undo the PIPEA quirk for i845
The PIPEA quirk is specifically for the issue with the PIPEB PLL on
830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA
running. i845 doesn't even have the second PLL or pipe, and enabling
the quirk results in a blank DVO LVDS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Mon, 7 Oct 2013 20:15:48 +0000 (17:15 -0300)]
drm/i915: Use the real cpu max frequency for ring scaling
The policy's max frequency is not equal to the CPU's max frequency. The
ring frequency is derived from the CPU frequency, and not the policy
frequency.
One example of how this may differ through sysfs. If the sysfs max
frequency is modified, that will be used for the max ring frequency
calculation.
(/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq). As far as I
know, no current governor uses anything but max as the default, but in
theory, they could. Similarly distributions might set policy as part of
their init process.
It's ideal to use the real frequency because when we're currently scaled
up on the GPU. In this case we likely want to race to idle, and using a
less than max ring frequency is non-optimal for this situation.
AFAIK, this patch should have no impact on a majority of people.
This behavior hasn't been changed since it was first introduced:
commit 23b2f8bb92feb83127679c53633def32d3108e70
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Jun 28 13:04:16 2011 -0700
drm/i915: load a ring frequency scaling table v3
CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:21 +0000 (18:02 +0300)]
drm/i915: Flush primary plane changes in sprite code
Flush the primary plane changes when enabling/disabling the primary
plane in response to sprite visibility.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:20 +0000 (18:02 +0300)]
drm/i915: WARN if primary plane state doesn't match expectations
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:19 +0000 (18:02 +0300)]
drm/i915: Rename intel_{enable, disable}_plane to intel_{enable, disable}_primary_plane
The new names make it clearer which plane we're talking about.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Resolve small conflict with the haswell_crtc_disable_planes
extraction.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:18 +0000 (18:02 +0300)]
drm/i915: Rename intel_flush_display_plane to intel_flush_primary_plane
The intel_flush_primary_plane name actually tells us which plane
we're talking about.
Also reorganize the internals a bit and add a missing POSTING_READ()
to make sure the hardware has seen the changes by the time we
return from the function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:17 +0000 (18:02 +0300)]
drm/i915: Enable/disable IPS when primary is enabled/disabled
IPS should be OK as long as one plane is enabled on the pipe, but
it does seem to cause problems when going between primary only and
sprite only.
This needs more investigations, but for now just disable IPS whenever
the primary plane is disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:16 +0000 (18:02 +0300)]
drm/i915: Do the fbc vs. primary plane enable/disable in the right order
Disable fbc before disabling the primary plane, and enable fbc after
the primary plane has been enabled again.
Also use intel_disable_fbc() to disable FBC to avoid the pointless
overhead of intel_update_fbc(), and especially avoid having to clean
up and set up the stolen mem compressed buffer again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:15 +0000 (18:02 +0300)]
drm/i915: Save user requested plane coordinates only on success
If the setplane operation fails, we shouldn't save the user's requested
plane coordinates. Since we adjust the coordinates during the clipping
process, make a copy of the originals, and once the operation has
succeeded save them for later reuse when the plane gets re-enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:14 +0000 (18:02 +0300)]
drm/i915: Do a bit of cleanup in the sprite code
Move the variable initialization to where the variables are declared,
and kill a pointless to_intel_crtc() cast when we already have the
casted pointer.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:13 +0000 (18:02 +0300)]
drm/i915: Kill a goto from sprite disable code
Let's not use goto when a simple if suffices. This is not error handling
code or anything, so the goto looks out of place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:12 +0000 (18:02 +0300)]
drm/i915: Reduce the time we hold struct mutex in sprite update_plane code
We used to call the entire intel specific update_plane hook while
holding struct_mutex. Actually we only need to hold struct_mutex while
pinning/unpinning the obj. The plane state itself is protected by the
kms locks, and as the object is pinned we can dig out the offset and
tiling information from it without fearing that it would change
underneath us.
So now we don't need to drop and reacquire the lock around the
wait_for_vblank. Also we will need another wait_for_vblank in the IVB
specific update_plane hook, and this way we don't need to worry about
struct_mutex there either.
Also move the intel_plane->obj=NULL assignment outside strut_mutex in
disable_plane to make it clear that it's not protected by struct_mutex.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:11 +0000 (18:02 +0300)]
drm/i915: Allow sprites to be configured on a disabled pipe
We allow cursors to be set up when the pipe is disabled. Do the same for
sprites as well.
We need to be somewhat careful with the primary disable logic as we
don't want to accidentally enable the primary plane on a disabled pipe.
v2: Skip primary enable/disable and plane registers
writes on disabled pipe
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 15:02:10 +0000 (18:02 +0300)]
drm/i915: Set primary_disabled in intel_{enable, disable}_plane
If the primary gets marked as disabled while the pipe is off for
instance, we should still re-enable it when the pipe is turned on,
unless the sprite covers it fully also in that configuration.
Unfortunately we do the plane visibility checks only in the sprite code,
which is executed after the primary enabling when turning the pipe off.
Ideally we should compute the plane visibility before touching the
hardware at all, but for now just set the primary_disabld flag
in intel_{enable,disable}_plane.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Sat, 5 Oct 2013 13:13:56 +0000 (16:13 +0300)]
drm/i915/dp: promote clock recovery failures to DRM_ERROR
If channel equalization succeeds, there's no indication something went
wrong in clock recovery (unless debug is enabled). We should shout about
the failures and fix them instead of hiding them under the carpet.
This has allowed bugs like [1] stay dormant for a long time.
Ville Syrjälä [Fri, 4 Oct 2013 17:32:25 +0000 (20:32 +0300)]
drm/i915: Fix VGA_DISP_DISABLE check
The VGACNTRL register contains a bunch of other stuff besides
the VGA_DISP_DISABLE bit. When we write the register we always set those
other bits to zero, so normally the current check would work.
However on HSW disabling and re-enabling the power well will reset the
VGACNTRL register to its default value, which has several of the other
bits set as well.
So only look at the VGA_DISP_DISABLE bit when checking whether the VGA
plane needs re-disabling.
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>
Ville Syrjälä [Fri, 27 Sep 2013 13:55:49 +0000 (16:55 +0300)]
drm/i915: Use intel_PLL_is_valid() in vlv_find_best_dpll()
Everyone else uses intel_PLL_is_valid(), so make VLV use it as well.
We don't have any special p and m limits on VLV, so skip those tests,
and we also need to skip the m1<=m2 test line PNV.
Reorganize the function a bit to move the n check alongside the rest of
the test for the non-derived dividers, and check the derived values
afterwards.
Note that this changes vlv_find_best_dpll() in two ways:
- The .vco comparison is now >max instead of >=max, and since we round
down when calculating that stuff, we may now allow frequencies slightly
above the max as we do on other platforms. The previous method
disallowed exactly max and anything above it.
- We now check the .dot frequency against the data rate limits, which we
didn't do before.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:31 +0000 (21:26 +0300)]
drm/i915: Don't lie about findind suitable PLL settings on VLV
If vlv_find_best_dpll() couldn't find suitable PLL settings,
just say so instead of lying to caller.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:30 +0000 (21:26 +0300)]
drm/i915: intel_limits_vlv_dac and intel_limits_vlv_hdmi are the same
After aligning the p1 divider limits, and removing the unused p and m
limits, intel_limits_vlv_dac and intel_limits_vlv_hdmi are identical.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:29 +0000 (21:26 +0300)]
drm/i915: Remove unused dot_limit from VLV PLL limits
We don't use .dot_limit for anything on VLV, so don't populate it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:28 +0000 (21:26 +0300)]
drm/i915: Remove the unused p and m limits for VLV
We never check the p and m limits (which according to comments are
based on someone's guesswork), so just remove them.
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm has no p and m
limits listed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:27 +0000 (21:26 +0300)]
drm/i915: Respect p2 divider minimum limit on VLV
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm tells us that the
minimum p2 divider is 2. Use that limit on the code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:26 +0000 (21:26 +0300)]
drm/i915: Allow p1 divider 2 on VLV
According to VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm p1
can be 2-3 always.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:25 +0000 (21:26 +0300)]
drm/i915: Clarify VLV PLL p1 limits
For some reason there's a sort of off by one issue with the p1 divider.
The actual p1 limits according to
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm is 2-3, so we should
just say that instead of saying 1-3 and avoiding the 1 via the choice of
comparison operator.
I don't know why we're using different p1 limits for intel_limits_vlv_dac
and intel_limits_vlv_hdmi, but let's preserve that for now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:24 +0000 (21:26 +0300)]
drm/i915: Make sure we respect n.max on VLV
We limit the maximum n divider value in order to make sure the PLL's
reference inout is at least 19.2 MHz. I assume that is done to satisfy
some hardware requirement.
However we never check whether that calculated limit is below the
maximum supoorted N divider value (7). In practice that is always true
since we only support 100 MHz reference clock, but making the code
safe against higher reference clocks seems like a reasoanble thing to
do.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:23 +0000 (21:26 +0300)]
drm/i915: De-magic the VLV p2 divider step size
The p2 divider on VLV needs to be even when it's > 10. The current code
to make that happen is rather weird. Just make the step size adjustement
in the for loop decrement step.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 27 Sep 2013 13:54:19 +0000 (16:54 +0300)]
drm/i915: Rewrite vlv_find_best_dpll()
Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
an army of local variables.
Also extract the code to calculate the derived values into
vlv_clock().
v2: Split up the earlier fixes, extract vlv_clock()
v3: Initialize best_clock
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:21 +0000 (21:26 +0300)]
drm/i915: Don't underflow bestppm
We do 'bestppm - 10' in vlv_find_best_dpll() but never check whether
that might underflow. Add such a check.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 24 Sep 2013 18:26:20 +0000 (21:26 +0300)]
drm/i915: Make vlv_find_best_dpll() ppm calculation safe
Use div_u64() to make the ppm calculation in vlv_find_best_dpll() safe
against interger overflows.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 4 Oct 2013 09:33:00 +0000 (10:33 +0100)]
drm/i915: Fix type mismatch and accounting in i915_gem_shrink
The interface uses an unsigned long, and we can use the unsigned counter
throughout our code, so do so. In the process, we notice one instance
where the shrink count is based on a heuristic rather than the result,
and another where we ask for too many pages to be purged.
v2: nr_to_scan needs to be promoted to a long as well, so just use
sc->nr_to_scan directly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 4 Oct 2013 08:58:46 +0000 (09:58 +0100)]
drm/i915: Call io_schedule() whilst whilsting for the GPU
Since we are waiting upon IO completion, inform the kernel through use
of the io_schedule() call rather than the regular schedule(). This
should allow the kernel to make better decisions regarding scheduling
and power management.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 10 Oct 2013 10:44:43 +0000 (12:44 +0200)]
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next
The conflict in intel_drv.h tripped me up a bit since a patch in dinq
moves all the functions around, but another one in drm-next removes a
single function. So I'ev figured backing this into a backmerge would
be good.
i915_dma.c is just adjacent lines changed, nothing nefarious there.
Jani Nikula [Fri, 4 Oct 2013 12:08:10 +0000 (15:08 +0300)]
drm/i915/dp: get rid of intel_dp->link_configuration
It's not really needed, rather just adds another place to hold
intermediate values that could go wrong, and it's not clear that the
training pattern set or training lane set should be written at this
point at all.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jani Nikula [Fri, 4 Oct 2013 12:08:09 +0000 (15:08 +0300)]
drm/radeon/dp: use drm_dp_enhanced_frame_cap()
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-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>
Jani Nikula [Fri, 4 Oct 2013 12:08:08 +0000 (15:08 +0300)]
drm/dp: add helper for checking DP_ENHANCED_FRAME_CAP in DPCD
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-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: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:40 +0000 (14:53 +0300)]
drm: Remove pci_vendor and pci_device from struct drm_device
We can get the PCI vendor and device IDs via dev->pdev. So we can drop
the duplicated information.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:39 +0000 (14:53 +0300)]
drm: Kill ctx_count from struct drm_device
The only user of ctx_count is the via driver, and we can replace that
use with list_is_singular().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:38 +0000 (14:53 +0300)]
drm: Kill unused stuff from struct drm_device
'map_count' and 'work' are never used. Kill them both.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:37 +0000 (14:53 +0300)]
drm: Make irq_enabled bool
irq_enabled is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:36 +0000 (14:53 +0300)]
drm: Collect per-crtc vblank stuff to a struct
drm_vblank_init() is too ugly. Make it a bit easier on the eye by
collecting all the per-crtc vblank counters, timestamps etc. to
a structure and just allocate an array of those.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:35 +0000 (14:53 +0300)]
drm: Make vblank_enabled bool
vblank_enabled is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:34 +0000 (14:53 +0300)]
drm: Make vblank_inmodeset unsigned
vblank_inmodeset is a bitmask, with only two bits mind you, but better
make it unsigned anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 4 Oct 2013 11:53:33 +0000 (14:53 +0300)]
drm: Make vblank_disable_allowed bool
vblank_disable_allowed is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Chris Wilson [Wed, 2 Oct 2013 10:12:53 +0000 (11:12 +0100)]
drm: Try loading builtin EDIDs first
If the firmware is not builtin and userspace is not yet running, we can
stall the boot process for a minute whilst the firmware loader times
out. This is contrary to expectations of providing a builtin EDID!
In the process, we can rearrange the code to make the error handling
more resilient and prevent gcc warning about unitialised variables along
the error paths.
v2: Load builtins first, fix gcc second (Jani) and cosmetics (Ville).
v3: Verify that we do not read beyond the end of the fwdata (Ville)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 2 Oct 2013 09:23:38 +0000 (11:23 +0200)]
drm: move device unregistration into drm_dev_unregister()
Analog to drm_dev_register(), we now provide drm_dev_unregister() which
does the reverse. drm_dev_put() is still in place and combines the calls
to drm_dev_unregister() and drm_dev_free() so buses don't have to change.
*_get() and *_put() are used for reference-counting in the kernel.
However, drm_dev_put() definitely does not do any kind of ref-counting.
Hence, use the more appropriate *_register(), *_unregister(), *_alloc()
and *_free() names.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 2 Oct 2013 09:23:37 +0000 (11:23 +0200)]
drm: introduce drm_dev_free() to fix error paths
The error paths in DRM bus drivers currently leak memory as they don't
correctly revert drm_dev_alloc(). Introduce drm_dev_free() to free DRM
devices which haven't been registered, yet.
We must be careful not to introduce any side-effects with cleanups done in
drm_dev_free(). drm_ht_remove(), drm_ctxbitmap_cleanup() and
drm_gem_destroy() are all fine in that regard.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 2 Oct 2013 09:23:36 +0000 (11:23 +0200)]
drm: move drm_lastclose() to drm_fops.c
Try to keep all functions that handle DRM file_operations in drm_fops.c
so internal helpers can be marked static later.
This makes the split between the 3 core files more obvious:
- drm_stub.c: DRM device allocation/destruction and management
- drm_fops.c: DRM file_operations (except for ioctl)
- drm_drv.c: Global DRM init + ioctl handling
Well, ioctl handling is still spread throughout hundreds of source files,
but at least the others are clearly defined this way.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 2 Oct 2013 09:23:35 +0000 (11:23 +0200)]
drm: merge device setup into drm_dev_register()
All bus drivers do device setup themselves. This requires us to adjust all
of them if we introduce new core features. Thus, merge all these into a
uniform drm_dev_register() helper.
Note that this removes the drm_lastclose() error path for AGP as it is
horribly broken. Moreover, no bus driver called this in any other error
path either. Instead, we use the recently introduced AGP cleanup helpers.
We also keep a DRIVER_MODESET condition around pci_set_drvdata() to keep
semantics.
[airlied: keep passing flags through so drivers don't oops on load]
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 2 Oct 2013 09:23:34 +0000 (11:23 +0200)]
drm: add drm_dev_alloc() helper
Instead of managing device allocation+initialization in each bus-driver,
we should do that in a central place. drm_fill_in_dev() already does most
of it, but also requires the global drm lock for partial AGP device
registration.
Split both apart so we have a clean device initialization/allocation
phase, and a registration phase.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 2 Oct 2013 08:15:18 +0000 (10:15 +0200)]
drm: kill ->gem_init_object() and friends
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie <airlied@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Ben Skeggs <skeggsb@gmail.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 2 Oct 2013 08:15:17 +0000 (10:15 +0200)]
drm/nouveau: embed gem object in nouveau_bo
There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.
The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff the user holds a valid
gem reference. That is, as the gem object holds a reference to the
nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
guaranteed to also hold a gem reference. The gem object might get
destroyed after the last user drops the gem-ref via
drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
gem-reference.
For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
valid. However, this shouldn't be used for real functionality to avoid
gem-internal dependencies.
Note that the implementation follows the previous style. However, we no
longer can check for bo->gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Chon Ming Lee [Thu, 3 Oct 2013 15:16:17 +0000 (23:16 +0800)]
drm/i915/vlv: Turn off power gate for BIOS-less system.
During system boot up, by default, the power gate for render, media and
display well still power gated. Normally, BIOS will turn off the power
gate. In the BIOS-less system, the driver need to turn off the power
gate very early during driver load.
v2: Move this to intel_uncore_sanitize to allow it to get call during
resume path. (Daniel)
v3: Remove redundant write 0 to DPIO_CTL, and use DPIO_RESET instead of
just 0x1 (Ville)
Add turn of power gate for display 2d/render well/media well.
v4: Remove toggle cmnreset in intel_uncore_sanitize. Cmnreset should
toggle after CRI clock source has been selected. Jesse DPIO reset patch
which toggle the cmnreset in intel_modeset_init_hw() should handle it.
(Ville)
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse Barnes [Thu, 3 Oct 2013 18:35:46 +0000 (11:35 -0700)]
drm/i915/vlv: reset DPIO on load and resume v2
DPIO needs to have common reset de-asserted on soft resets like boot and
S3. In some cases, the BIOS will have done this for us, but it should
be safe to do at runtime as well, as long as we do it when the pipes are
otherwise off.
v2: update bit name to match docs better (Ville)
reset after CRI clock select (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=69166 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rodrigo Vivi [Thu, 3 Oct 2013 19:15:06 +0000 (16:15 -0300)]
drm/i915: Simplify PSR debugfs
for igt test case.
v2: remove trailing spaces and fix conflicts
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet:
- make it comipile
- s/IS_HASWELL/HAS_PSR/] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 25 Sep 2013 16:34:57 +0000 (17:34 +0100)]
drm/i915: Tweak RPS thresholds to more aggressively downclock
After applying wait-boost we often find ourselves stuck at higher clocks
than required. The current threshold value requires the GPU to be
continuously and completely idle for 313ms before it is dropped by one
bin. Conversely, we require the GPU to be busy for an average of 90% over
a 84ms period before we upclock. So the current thresholds almost never
downclock the GPU, and respond very slowly to sudden demands for more
power. It is easy to observe that we currently lock into the wrong bin
and both underperform in benchmarks and consume more power than optimal
(just by repeating the task and measuring the different results).
An alternative approach, as discussed in the bspec, is to use a
continuous threshold for upclocking, and an average value for downclocking.
This is good for quickly detecting and reacting to state changes within a
frame, however it fails with the common throttling method of waiting
upon the outstanding frame - at least it is difficult to choose a
threshold that works well at 15,000fps and at 60fps. So continue to use
average busy/idle loads to determine frequency change.
v2: Use 3 power zones to keep frequencies low in steady-state mostly
idle (e.g. scrolling, interactive 2D drawing), and frequencies high
for demanding games. In between those end-states, we use a
fast-reclocking algorithm to converge more quickly on the desired bin.
v3: Bug fixes - make sure we reset adj after switching power zones.
v4: Tune - drop the continuous busy thresholds as it prevents us from
choosing the right frequency for glxgears style swap benchmarks. Instead
the goal is to be able to find the right clocks irrespective of the
wait-boost.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Stéphane Marchesin <stephane.marchesin@gmail.com> Cc: Owen Taylor <otaylor@redhat.com> Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com> Cc: "Zhuang, Lena" <lena.zhuang@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 25 Sep 2013 16:34:56 +0000 (17:34 +0100)]
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Stéphane Marchesin <stephane.marchesin@gmail.com> Cc: Owen Taylor <otaylor@redhat.com> Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com> Cc: "Zhuang, Lena" <lena.zhuang@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 25 Sep 2013 16:34:55 +0000 (17:34 +0100)]
drm/i915: Fix __wait_seqno to use true infinite timeouts
When we switched to always using a timeout in conjunction with
wait_seqno, we lost the ability to detect missed interrupts. Since, we
have had issues with interrupts on a number of generations, and they are
required to be delivered in a timely fashion for a smooth UX, it is
important that we do log errors found in the wild and prevent the
display stalling for upwards of 1s every time the seqno interrupt is
missed.
Rather than continue to fix up the timeouts to work around the interface
impedence in wait_event_*(), open code the combination of
wait_event[_interruptible][_timeout], and use the exposed timer to
poll for seqno should we detect a lost interrupt.
v2: In order to satisfy the debug requirement of logging missed
interrupts with the real world requirments of making machines work even
if interrupts are hosed, we revert to polling after detecting a missed
interrupt.
v3: Throw in a debugfs interface to simulate broken hw not reporting
interrupts.
v4: s/EGAIN/EAGAIN/ (Imre)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Don't use the struct typedef in new code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 23 Sep 2013 20:33:20 +0000 (17:33 -0300)]
drm/i915: Add some missing steps to i915_driver_load error path
We missed adding a few cleanup steps for recent additions.
Reviewer: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 2 Oct 2013 16:25:02 +0000 (09:25 -0700)]
drm/i915: Clean up the ring scaling calculations
This patch attempts to clean up the ring/IA scaling programming in the
following ways.
1. Fix the comment about the DDR frequency. The math is 266MHz, not
133MHz. Formula was right, docs are wrong.
2. Mask the DCLK register since I don't know how it is defined on future
platforms.
3. use mult_frac instead of magic math.
This helps for future platform enabling.
v2: Actually use the right patch. The v1 was a mix of things, none of
which was right. Note that due to rounding, we actually get different
values (slightly higher) for the effective ring frequency.
v3: Use 1.25 instead of 1.33 as the original code did. (Jesse)
CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 1 Oct 2013 19:52:14 +0000 (22:52 +0300)]
drm/i915: Don't populate pipe_src_{w,h} multiple times
If we ever end up doing the retry loop due to bandwidth constraints, we
would rewrite pipe_src_{w,n} based on adjusted_mode timings. But by that
time the encoder may have already replaced the adjusted_mode with a
fixed panel mode, which would then corrupt pipe_src_{w,h}.
v2: Use requested_mode and slap on a big comment from Daniel
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 20 Sep 2013 19:21:19 +0000 (16:21 -0300)]
drm/i915: implement the Haswell mode set sequence workaround
This workaround is described in the mode set sequence documentation.
When enabling planes for the second pipe, we need to wait for 2
vblanks on the first pipe. This should solve "a flash of screen
corruption if planes are enabled on second/third pipe during the time
that big FIFO mode is exiting". Watermarks are fun :)
v2: Save indentation levels
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 19 Sep 2013 20:00:37 +0000 (17:00 -0300)]
drm/i915: Disable/enable planes as the first/last thing during modeset on HSW
Refactor the plane enabling/disabling into helper functions and move
the calls to happen as the first thing during .crtc_disable, and the
last thing during .crtc_enable.
Those are the two clear points where we are sure that the pipe is
actually running regardless of the encoder type or hardware
generation.
v2: Made by Paulo:
Remove the code touching everything but the Haswell functions. We
need this change on Haswell right now since it fixes a FIFO underrun
that we get on pipe A while we enable pipe B (see the workaround
notes on the Haswell mode set sequence documentation). We can bring
back the code to gens 2-7 later, once they're tested.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
projects / ~andy / linux / log