Daniel Vetter [Fri, 14 Jun 2013 22:13:15 +0000 (00:13 +0200)]
drm: check that ->set_config properly updates the fb
Historically drm lacked fb refcounting, so the updating of crtc->fb
was done by the lower levels at a point convenient to get their own
refcounting (e.g. refcounts for the underlying gem bo, pinning
refcounts) right. With the introduction of refcounted fbs the drm core
handled the fb refcounts, but still relied on drivers to update the
crtc->fb pointer (this approach required the least invasive changes in
drivers).
Enforce this contract with a WARN_ON.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Fri, 14 Jun 2013 22:13:13 +0000 (00:13 +0200)]
drm/crtc-helper: explicit DPMS on after modeset
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
drm: Only set DPMS ON when actually configuring a mode
which fixed the bug of trying to dpms on disabled outputs, but
introduced the new discrepancy between an fb update only and full
modesets. The actual introduction of this goes back to
drm: Set connector DPMS status to ON in drm_crtc_helper_set_config
And if you'd dig around in the i915 driver code there's even more fun
around forcing dpms on and losing our heads and temper of the
resulting inconsistencies. Especially the DP re-training code had tons
of funny stuff in it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Fri, 14 Jun 2013 22:13:12 +0000 (00:13 +0200)]
drm/crtc-helper: no need to check for fb->depth/bpp
... since we already check for fb->pixel_format, which encodes all
this. The other two fields are only for backwards compat of older
drivers (and we might want to look into eventually just killing them).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Fri, 14 Jun 2013 22:13:11 +0000 (00:13 +0200)]
drm/crtc-helpers: Enforce sane set_config api
There's no point in trying to clean up after driver-bugs, so just blow
up. Furthermore it's an interface abuse to set no mode but have an fb
and aslo to try to set an fb without enough connectors. These two
spefici cases of interface abuse have been committed by the fb helper,
but that's been fixed meanwhile in
The i915 driver has been shipping since a while with these BUGs with
no reports, so should be save.
Note that this drops an ugly case where we clear crtc->fb behind the
upper levels back and so cause a refcounting mayhem, which Russell
Kins spotted while trying to hunt down a drm framebuffer leak.
Reported-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Benoit Parrot [Tue, 18 Jun 2013 22:18:31 +0000 (17:18 -0500)]
gpu:drm:tilcdc: get preferred_bpp value from DT
The preferred_bpp value in currently hard-coded to 16.
This causes color corruption on the am335x-evm lcd panel which
requires 32 bpp instead. This changes attempts to use the configured
bpp value from the DT or built-in panel-info struct.
Signed-off-by: Benoit Parrot <bparrot@ti.com> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/mgag200: Don't do full cleanup if mgag200_device_init fails
Running mgag200_driver_unload when the driver init fails early on
causes functions like drm_mode_config_cleanup to be called. The
problem is, drm_mode_config_cleanup crashes because the corresponding
init hasn't happend yet. There really isn't anything to cleanup after
mgag200_device_init, so we can just pass the error code upwards.
Acked-by: Julia Lemire <jlemire@matrox.com> Signed-off-by: Christopher Harvey <charvey@matrox.com> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Dave Airlie <airlied@gmail.com>
G200 cards support, at best, 16 colour palleted images for the cursor
so we do a conversion in the cursor_set function, and reject cursors
with more than 16 colours, or cursors with partial transparency. Xorg
falls back gracefully to software cursors in this case.
We can't disable/enable the cursor hardware without causing momentary
corruption around the cursor. Instead, once the cursor is on we leave
it on, and simulate turning the cursor off by moving it
offscreen. This works well.
Since we can't disable -> update -> enable the cursors, we double
buffer cursor icons, then just move the base address that points to
the old cursor, to the new. This also works well, but uses an extra
page of memory.
The cursor buffers are lazily-allocated on first cursor_set. This is
to make sure they don't take priority over any framebuffers in case of
limited memory.
Here is a representation of how the bitmap for the cursor is mapped in G200 memory :
Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3
are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for
AND mask. Each line has the following format:
Signed-off-by: Christopher Harvey <charvey@matrox.com> Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com> Acked-by: Julia Lemire <jlemire@matrox.com> Tested-by: Julia Lemire <jlemire@matrox.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
Ville Syrjälä [Mon, 27 May 2013 17:19:58 +0000 (20:19 +0300)]
drm: Drop all the stub gamma_get, gamma_set, load_lut functions from drivers
Many of the drivers didn't implement palette/gamma handling, but were forced
to provide stubs for the hooks to avoid drm_fb_helper from oopsing. Now that
the hooks are optional, we can eliminate all the stubs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
Ville Syrjälä [Mon, 27 May 2013 17:19:57 +0000 (20:19 +0300)]
drm/fb-helper: Make load_lut and gamma_set/gamma_get hooks optional
Check whether the crtc provides the load_lut callback before calling it.
This allows the driver to provide the hook only for those CRTCs that
actually have the hardware support for it.
Also check whether the driver provided the fb_helper gamma_set/gamma_get
hooks. It's a driver bug if it allows non-truecolor fbdev visuals w/o
these hooks, but auditing all the drivers is too tedious. So just slap
a big WARN_ON() there and bail out before things start to explode.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
Ville Syrjälä [Mon, 27 May 2013 17:19:56 +0000 (20:19 +0300)]
drm/fb-helper: Don't clobber the display palette when fbdev isn't bound
Perform the drm_fb_helper_is_bound() check to avoid clobbering the
display palette of some other KMS client.
While at it, fix up the locking by grabbing all modeset locks for the
duration of the fb_setcmap operation.
v2: Make a note of the locking changes in the commit message
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
Ville Syrjälä [Mon, 3 Jun 2013 13:10:42 +0000 (16:10 +0300)]
drm/fb-helper: Disable cursors and planes when restoring fbdev mode
Cursors and plane can obscure whatever fbdev wants to show the user.
Disable them all in drm_fb_helper_restore_fbdev_mode.
After the cursors and planes have been disabled, user space needs to
explicitly re-enable them to make them visible again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
Ville Syrjälä [Fri, 31 May 2013 12:23:41 +0000 (15:23 +0300)]
drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list
Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.
Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Mon, 3 Jun 2013 13:10:41 +0000 (16:10 +0300)]
drm/vmwgfx: Don't access file_priv in cursor_set when handle==0
We want to disable the cursor by calling ->cursor_set() with handle=0
from places where we don't have a file_priv, so don't try to access it
unless necessary.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Wed, 5 Jun 2013 12:39:55 +0000 (12:39 +0000)]
drm: Improve drm_crtc documentation
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>
Dave Airlie [Mon, 10 Jun 2013 22:38:56 +0000 (08:38 +1000)]
Merge tag 'drm-intel-next-2013-06-01' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:
Another round of drm-intel-next for 3.11. Highlights:
- Haswell IPS support (Paulo Zanoni)
- VECS support on Haswell (Ben Widawsky, Xiang Haihao, ...)
- Haswell watermark fixes (Paulo Zanoni)
- "Make the gun bigger again" multithread fence fix from Chris.
- i915_error_state finnally no longer fails with -ENOMEM! Big thanks to
Mika for tackling this.
- vlv sideband locking fixes from Jani
- Hangcheck prep work for arb_robustness support (Mika&Chris)
- edp vs cpu port confusion clean-up from Imre
- pile of smaller fixes and cleanups all over.
* tag 'drm-intel-next-2013-06-01' of git://people.freedesktop.org/~danvet/drm-intel: (70 commits)
drm/i915: add i915_ips_status debugfs entry
drm/i915: add enable_ips module option
drm/i915: implement IPS feature
drm/i915: fix up the edp power well check
drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparam
drm/i915: add I915_EXEC_VEBOX to i915_gem_do_execbuffer()
drm/i915: add VEBOX into debugfs
drm/i915: Enable vebox interrupts
drm/i915: vebox interrupt get/put
drm/i915: consolidate interrupt naming scheme
drm/i915: Convert irq_refounct to struct
drm/i915: make PM interrupt writes non-destructive
drm/i915: Add PM regs to pre/post install
drm/i915: Create an ivybridge_irq_preinstall
drm/i915: Create a more generic pm handler for hsw+
drm/i915: add support for 5/6 data buffer partitioning on Haswell
drm/i915: properly set HSW WM_LP watermarks
drm/i915: properly set HSW WM_PIPE registers
drm/i915: fix pch_nop support
drm/i915: Vebox ringbuffer init
...
Ville Syrjälä [Fri, 31 May 2013 12:17:08 +0000 (12:17 +0000)]
drm: Sort connector modes based on vrefresh
Keeping the modes sorted by vrefresh before the pixel clock makes the
mode list somehow more pleasing to the eye.
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>
Ville Syrjälä [Fri, 31 May 2013 12:17:07 +0000 (12:17 +0000)]
drm: Add probed modes in probe order
Keeping the modes in the same order as we probe them makes it a bit
easier to track what's happening.
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>
Ville Syrjälä [Fri, 31 May 2013 12:17:06 +0000 (12:17 +0000)]
drm: Preserve the list head in drm_mode_copy
Preserve the destination mode's list head in drm_mode_copy. Just
in case someone decides that it's a good idea to overwrite a mode which
happens to be on some list,
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>
Dave Airlie [Mon, 10 Jun 2013 22:14:21 +0000 (08:14 +1000)]
Merge branch 'drm/next' of git://linuxtv.org/pinchartl/fbdev into drm-next
GEM CMA PRIME support from Laurent.
* 'drm/next' of git://linuxtv.org/pinchartl/fbdev:
drm: GEM CMA: Add DRM PRIME support
drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping
drm: GEM CMA: Split object creation into object alloc and DMA memory alloc
drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
drm/gem: Split drm_gem_mmap() into object search and object mapping
Ville Syrjälä [Fri, 7 Jun 2013 15:43:07 +0000 (15:43 +0000)]
drm: Constify the pretty-print functions
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().
While at it move the drm_get_connector_status_name() prototype from
drmP.h to drm_crtc.h where it belongs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Fri, 7 Jun 2013 15:43:05 +0000 (15:43 +0000)]
drm/i915: Print pretty names for pixel formats
Use drm_get_format_name to print more readable pixel format names
in debug output.
Also unify the debug messages to say "unsupported pixel format",
which better describes what is going on.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/gem: Split drm_gem_mmap() into object search and object mapping
The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
Paulo Zanoni [Fri, 31 May 2013 19:33:23 +0000 (16:33 -0300)]
drm/i915: add enable_ips module option
IPS is still enabled by default. Feature requested by the power
management team.
This should also help testing the feature on some early pre-production
hardware where there were relationship problems between IPS and PSR.
v2: Rebase on top of the newest IPS implementation.
v3: Check i915_enable_ips at compute_config, not supports_ips, so the
kernel parameter will be ignored at haswell_get_pipe_config.
Requested-by: Kristen Accardi <kristen.c.accardi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 31 May 2013 19:33:22 +0000 (16:33 -0300)]
drm/i915: implement IPS feature
Intermediate Pixel Storage is a feature that should reduce the number
of times the display engine wakes up memory to read pixels, so it
should allow deeper PC states. IPS can only be enabled on ULT pipe A
with 8:8:8 pipe pixel formats.
With eDP 1920x1080 and correct watermarks but without FBC this moves
my PC7 residency from 2.5% to around 38%.
v2: - It's tied to pipe A, not port A
- Add pipe_config support (Chris)
- Add some assertions (Chris)
- Rebase against latest dinq
v3: - Don't ever set ips_enabled to false (Daniel)
- Only check for ips_enabled at hsw_disable_ips (Daniel)
v4: - Add hsw_compute_ips_config (Daniel)
- Use the new dump_pipe_config (Daniel)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 31 May 2013 15:49:17 +0000 (17:49 +0200)]
drm/i915: fix up the edp power well check
Now that we track the cpu transcoder we need accurately in the pipe
config we can finally fix up the transcoder check. With the current
code eDP on port D will be broken since we'd errornously cut the
power.
v2:
- Kill the now outdated comment (Paulo)
- Add the missing crtc->base.enabled check and consolidate it (Paulo)
- Smash all checks together, looks neater that way.
v3: Kill the unused encoder variable.
Cc: Takashi Iwai <tiwai@suse.de> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 29 May 2013 02:22:29 +0000 (19:22 -0700)]
drm/i915: consolidate interrupt naming scheme
The motivation here is we're going to add some new interrupt definitions
and handling outside of the GT interrupts which is all we've managed so
far (with some RPS exceptions). By consolidating the names in the future
we can make thing a bit cleaner as we don't need to define register
names twice, and we can leverage pretty decent overlap in HW registers
since ILK.
To explain briefly what is in the comments: there are two sets of
interrupt masking/enabling registers. At least so far, the definitions
of the two sets overlap. The old code setup distinct names for
interrupts in each set, ie. one for global, and one for ring. This made
things confusing when using the wrong defines in the wrong places.
rebase: Modified VLV bits
v2: Renamed GT_RENDER_MASTER to GT_RENDER_CS_MASTER (Damien)
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 29 May 2013 02:22:27 +0000 (19:22 -0700)]
drm/i915: make PM interrupt writes non-destructive
PM interrupts have an expanded role on HSW. It helps route the EBOX
interrupts. This patch is necessary to make the existing code which
touches the mask, and enable registers more friendly to other code paths
that also will need these registers.
To be more explicit:
At preinstall all interrupts are masked and disabled. This implies that
preinstall should always happen before any enabling/disabling of RPS or
other interrupts.
The PMIMR is touched by the workqueue, so enable/disable touch IER and
IIR. Similarly, the code currently expects IMR has no use outside of the
RPS related interrupts so they unconditionally set 0, or ~0. We could
use IER in the workqueue, and IMR elsewhere, but since the workqueue
use-case is more transient the existing usage makes sense.
Enable RPS events:
IER := IER | GEN6_PM_RPS_EVENTS // Enable the RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Make sure there were no leftover events
(really shouldn't happen)
v2: Shouldn't destroy PMIIR or PMIMR VEBOX interrupt state in
enable/disable rps functions (Haihao)
v3: Bug found by Chris where we were clearing the wrong bits at rps
disable.
expanded commit message
v4: v3 was based off the wrong branch
v5: Added the setting of PMIMR because of previous patch update
CC: Chris Wilson <chris@chris-wilson.co.uk> 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 [Wed, 29 May 2013 02:22:26 +0000 (19:22 -0700)]
drm/i915: Add PM regs to pre/post install
At the moment, these values are wiped out anyway by the rps
enable/disable. That will be changed in the next patch though.
v2: Add post install setup to address issue found by Damien in the next
patch.
replaced
WARN_ON(dev_priv->rps.pm_iir != 0);
with rps.pm_iir = 0;
With the v2 of this patch and the deferred pm enabling (which changed
since the original patches) we're now able to get PM interrupts before
we've brought up enabled rps. At this point in boot, we don't want to do
anything about it, so we simply ignore it. Since writing the original
assertion, the code has changed quite a bit, and I believe removing this
assertion is perfectly safe.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: I don't agree with the justification to drop the WARN and
added a FIXME to that effect.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 29 May 2013 02:22:24 +0000 (19:22 -0700)]
drm/i915: Create a more generic pm handler for hsw+
HSW has some special requirements for the VEBOX. Splitting out the
interrupt handler will make the code a bit nicer and less error prone
when we begin to handle those.
The slight functional change in this patch (queueing work while holding
the spinlock) is intentional as it makes a subsequent patch a bit nicer.
The change should also only effect HSW platforms.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 31 May 2013 13:19:21 +0000 (10:19 -0300)]
drm/i915: add support for 5/6 data buffer partitioning on Haswell
Now we compute the results for both 1/2 and 5/6 partitioning and then
use hsw_find_best_result to choose which one to use.
With this patch, Haswell watermarks support should be in good shape.
The only improvement we're missing is the case where the primary plane
is disabled: we always assume it's enabled, so we take it into
consideration when calculating the watermarks.
v2: - Check the latency when finding the best result
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>
Paulo Zanoni [Fri, 31 May 2013 14:45:06 +0000 (11:45 -0300)]
drm/i915: properly set HSW WM_LP watermarks
We were previously only setting the WM_PIPE registers, now we are
setting the LP watermark registers. This should allow deeper PC
states, resulting in power savings.
We're only using 1/2 data buffer partitioning for now.
v2: Merge both hsw_compute_pri_wm_* functions (Ville)
v3: - Simplify hsw_compute_wm_results (Ville)
- Rebase due to changes on the previous patch
v4: Unconfuse wm_lp/level (Ville)
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>
Paulo Zanoni [Fri, 31 May 2013 13:08:35 +0000 (10:08 -0300)]
drm/i915: properly set HSW WM_PIPE registers
We were previously calling sandybridge_update_wm on HSW, but the SNB
function didn't really match the HSW specification, so we were just
writing the wrong values.
With this patch, the haswell_update_wm function will set the correct
values for the WM_PIPE registers, but it will still keep all the LP
watermarks disabled.
The patch may look a little bit over-complicated for now, but it's
because much of the infrastructure for setting the LP watermarks is
already in place, so we won't have too much code churn on the patch
that sets the LP watermarks.
v2: - Fix pixel_rate on panel fitter case (Ville)
- Try to not overflow (Ville)
- Remove useless variable (Ville)
- Fix p->pri_horiz_pixels (Paulo)
v3: - Fix rounding errors on hsw_wm_method2 (Ville)
v4: - Fix memcmp bug (Paulo)
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>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Xiang, Haihao [Wed, 29 May 2013 02:22:22 +0000 (19:22 -0700)]
drm/i915: add HAS_VEBOX
The flag will be useful to help share code between IVB, and HSW as the
programming is similar in many places with this as one of the major
differences.
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
[Commit message + small fix by] Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 29 May 2013 02:22:21 +0000 (19:22 -0700)]
drm/i915: Rename ring flush functions
Historically we considered the render ring to have special flush
semantics and everything else to fall under a more general umbrella.
Probably by coincidence more than anything we decided to make the bsd
ring have the default *other* flush. As the new vebox ring exposes, the
bsd ring is actually the weird one. Doing this allows us to call
gen6_ring_flush for the vebox because calling blt_ring_flush would be
weird...
This patch should have no functional change.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 29 May 2013 02:22:20 +0000 (19:22 -0700)]
drm/i915: Add VECS semaphore bits
Like the other rings, the VECS supports semaphores. The semaphore stuff
is a bit wonky so this patch on it's own should be nice for review.
This patch should have no functional impact.
v2: Fix the English parts of clarification (again, register names were
right, text was reversed) (Damien)
Restore the still valid invariant. (Damien)
The bsd semaphore register should be MI_SEMAPHORE_SYNC_VVE (Damien)
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 [Wed, 29 May 2013 02:22:19 +0000 (19:22 -0700)]
drm/i915: Introduce VECS: the 4th ring
The video enhancement command streamer is a new ring on HSW which does
what it sounds like it does. This patch provides the most minimal
inception of the ring.
In order to support a new ring, we need to bump the number. The patch
may look trivial to the untrained eye, but bumping the number of rings
is a bit scary. As such the patch is not terribly useful by itself, but
a pretty nice place to find issues during a bisection.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 29 May 2013 02:22:18 +0000 (19:22 -0700)]
drm/i915: Semaphore MBOX update generalization
This replaces the existing MBOX update code with a more generalized
calculation for emitting mbox updates. We also create a sentinel for
doing the updates so we can more abstractly deal with the rings.
When doing MBOX updates the code must be aware of the /other/ rings.
Until now the platforms which supported semaphores had a fixed number of
rings and so it made sense for the code to be very specialized
(hardcoded).
The patch does contain a functional change, but should have no
behavioral changes.
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 [Wed, 29 May 2013 02:22:17 +0000 (19:22 -0700)]
drm/i915: Comments for semaphore clarification
Semaphores are tied very closely to the rings in the GPU. Trivial patch
adds comments to the existing code so that when we add new rings we can
include comments there as well. It also helps distinguish the ring to
semaphore mailbox interactions by using the ringname in the semaphore
data structures.
This patch should have no functional impact.
v2: The English parts (as opposed to register names) of the comments
were reversed. (Damien)
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>
Chris Wilson [Tue, 28 May 2013 09:38:44 +0000 (10:38 +0100)]
drm/i915: Avoid promoting a simulated hang to 'wedged'
It appears that a beneficial side-effect of Mika's more accurate hangman
work is to speed up hang detection and execution. This exposes a bug in
the reset code that then treats repeated simulated hangs as an
indication that the machine is wedged. Jiggle the code around so that we
only do the simulation processing from the hangcheck and avoid confusing
it with a real hang.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65060 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>
Daniel Vetter [Tue, 28 May 2013 14:28:55 +0000 (16:28 +0200)]
drm/i915: drop a few really redundant WARNs in hsw mode_set
- Correct cpu->pch display matching is already check when we detect
the PCH type at driver load.
- Plane/pipe state is already checked both when a) enabling, b)
disabling and in c) the modeset state checker. No need to go
overboard and also check it in in between a) and b).
Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 28 May 2013 10:05:54 +0000 (12:05 +0200)]
drm/i915: add basic pipe config dump support
All this pipe config abstraction adds another layer of complexity, so
it's good to have better visibility into what's going on exactly.
Doesn't dump out everything yet, and some bits are a bit duplicated
but this should be a good start.
Note that at boot-up a lot of the fields are 0 even for enabled pipes,
this is simply because our hw state readout code doesn't support
everything.
v2: Remove a few more now redudant debug output lines.
v3: Review from Paulo
- use transcoder_name
- fix up format specifiers
- add missing ':' in debug output
Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Tue, 28 May 2013 09:35:02 +0000 (12:35 +0300)]
drm/i915: document why dvo/sdvo/crt need a special dpms function
In the cloned case, changing just one output but keeping the other, the
pipe state won't change and intel_crtc_update_dpms will be a nop, but we
still need to update the dpms state of the output being changed.
Only dvo, sdvo and crt are cloneable, so only those three have special
dpms functions.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 21 May 2013 22:50:23 +0000 (00:50 +0200)]
drm/i915: fixup i915_pipe_enabled check in i915_irq.c
Well, as well as we can without completely revamping the drm vblank
code. The issue are that
- The vblank code needs to work on both ums and kms.
- It deals always deals with pipes.
- It doesn't take any of the kms locks.
The last part is not really fixable without revamping the drm vblank
code, since the drm core <-> driver interactions is a veritable pile
of spaghettis. But the other pieces can be fixed by switching on the
MODESET driver flag and either checking the hw state directly (ums
case) or just querying our sw tracking (with broken locking, but
that's not worse than what we've had).
drm/i915: convert PIPECONF to use transcoder instead of pipe
for the ums case, which will fix a NULL deref (since we really don't
have any crtcs set up).
But the real reason to do this is to drop our reliance on the
cpu_transcoder: By only checking intel_crtc->active we don't need to
make sure that the pipe_config (or at least the cpu_transcoder)
contain safe values even when the pipe is off.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Thu, 16 May 2013 11:40:36 +0000 (14:40 +0300)]
drm/i915: replace is_cpu_edp() with a check for port A
The patch changes all remaining is_cpu_edp() check with a check for port
A. We can do this, since in all these cases ValleyView is handled
separately and port A is always a CPU side eDP port.
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Thu, 16 May 2013 11:40:35 +0000 (14:40 +0300)]
drm/i915: merge VLV eDP and DP AUX clock divider calculation
On ValleyView for both eDP and DP the AUX input clock is 200MHz, so we
can calculate for both the clock divider for the 2MHz target rate at the
same place. Afterwards we can also replace the is_cpu_edp() check with a
check for port A.
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Imre Deak [Thu, 23 May 2013 16:39:40 +0000 (19:39 +0300)]
drm/i915: stop using is_cpu_edp() in intel_disable/post_disable_dp
Based on 3739850b46f - "drm/i915: disable the cpu edp port after the
cpu pipe" and the bspec disabling sequence for IVB and older it seems we
have to distinguish only the CPU vs. PCH port case, whether it's a DP or
eDP doesn't seem to matter. For IVB and older on the CPU side we can
only have eDP on port A, DP ports can only be on the PCH side. On VLV we
have only CPU side eDP/DP ports, no PCH. So the condition for the
disabling sequence we need for CPU ports is port == A || IS_VLV.
This allows us to remove is_cpu_edp() completely in a later patch.
v2:
- simplify (and fix) the condition for CPU side ports and adjust the
commit message accordingly (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sat, 25 May 2013 19:26:39 +0000 (12:26 -0700)]
drm/i915: Call context fini at cleanup
If contexts were actually initialized, and we fail somewhere later during
init this would possibly leak memory, and lead to some error messages
about unclean takedown. As the odds of this occurring, and someone
actually caring/noticing are pretty slim, the patch isn't terribly
important.
Found by code inspection while working on something else.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sat, 25 May 2013 19:26:38 +0000 (12:26 -0700)]
drm/i915: context debug messages
Add some debug messages to help figure out what goes wrong on context
initialization.
Later in the PPGTT series, I ended up having a lot of failures after
reset. In many cases it was extra difficult to debug because I hadn't
even realized that contexts failed to reinitialize after reset (again an
artifact of some later patches).
This fairly benign patch does help debug some potential issues which
arise later.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Sat, 25 May 2013 19:26:36 +0000 (12:26 -0700)]
drm/i915: use mappable size for fb kickout
The GTT start is either 0 in the KMS case, or some value which is set
only after the init IOCTL in the UMS case. In both cases, we don't have
this information until after we've tried to kick out the firmware fb.
This patch should have no functional change since we kzalloc the GTT
struct anyway. It only clarifies the situation for people who end up
having to look at that code.
Ben Widawsky [Sat, 25 May 2013 19:26:35 +0000 (12:26 -0700)]
drm/i915: pre-fixes for checkpatch
Since I'll need to modify i915_gem_object_bind_to_gtt(), fix the errors
now to get checkpatch to not complain.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict with Chris' improved debug output, and
bikeshed the new variable with s/max/gtt_max/ a bit while at it.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Mon, 13 May 2013 13:32:11 +0000 (16:32 +0300)]
drm/i915: introduce i915_hangcheck_ring_hung
In preparation to track per ring progress in hangcheck,
add i915_hangcheck_ring_hung.
v2: omit dev parameter (Ben Widawsky)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Fri, 24 May 2013 14:16:07 +0000 (17:16 +0300)]
drm/i915: track ring progression using seqnos
Instead of relying in acthd, track ring seqno progression
to detect if ring has hung.
v2: put hangcheck stuff inside struct (Chris Wilson)
v3: initialize hangcheck.seqno (Ben Widawsky)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Mon, 13 May 2013 13:32:09 +0000 (16:32 +0300)]
drm/i915: pass seqno to i915_hangcheck_ring_idle
In preparation for next commit, pass seqno as a parameter
to i915_hangcheck_ring_idle as it will be used inside
i915_hangcheck_elapsed.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 24 May 2013 14:59:18 +0000 (11:59 -0300)]
drm/i915: add haswell_update_sprite_wm
On Haswell, whenever we change the sprites we need to completely
recalculate all the watermarks, because the sprites are one of the
parameters to the LP watermarks, so a change on the sprites may
trigger a change on which LP levels are enabled.
So on this commit we store all the parameters we need to store for
proper recalculation of the Haswell WMs and then call
haswell_update_wm.
Notice that for now our haswell_update_wm function is not really using
these parameters we're storing, but on the next commits we'll use
these parameters.
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>
Paulo Zanoni [Fri, 24 May 2013 14:59:17 +0000 (11:59 -0300)]
drm/i915: add "enable" argument to intel_update_sprite_watermarks
Because we want to call it from the "sprite disable" paths, since on
Haswell we need to update the sprite watermarks when we disable
sprites.
For now, all this patch does is to add the "enable" argument and call
intel_update_sprite_watermarks from inside ivb_disable_plane. This
shouldn't change how the code behaves because on
sandybridge_update_sprite_wm we just ignore the "!enable" case. The
patches that implement Haswell watermarks will make use of the changes
introduced by this patch.
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>
Andy Lutomirski [Mon, 13 May 2013 23:58:48 +0000 (23:58 +0000)]
drm: Don't leak phys_wc "handles" to userspace
I didn't fix this in the earlier patch -- it would have broken the
build due to the now-deleted garbage in drm_os_linux.h.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
Andy Lutomirski [Mon, 13 May 2013 23:58:47 +0000 (23:58 +0000)]
drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
There are no users left in drivers/gpu.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
Andy Lutomirski [Mon, 13 May 2013 23:58:46 +0000 (23:58 +0000)]
uvesafb: Clean up MTRR code
The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).
UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.
As an added bonus, any MTRR added is freed on unload.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
Andy Lutomirski [Mon, 13 May 2013 23:58:45 +0000 (23:58 +0000)]
radeon: Switch to arch_phys_wc_add and add a missing ..._del
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Andy Lutomirski [Mon, 13 May 2013 23:58:44 +0000 (23:58 +0000)]
i915: Use arch_phys_wc_{add,del}
i915 open-coded logic that was essentially equivalent to the new API.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
Andy Lutomirski [Mon, 13 May 2013 23:58:43 +0000 (23:58 +0000)]
drm, agpgart: Use pgprot_writecombine for AGP maps and make the MTRR optional
I'm not sure I understand the intent of the previous behavior. mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable. But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.
The new behavior just requests WC explicitly for all AGP maps.
If there is any code out there that expects cacheable access to the
AGP aperture (because the drm driver doesn't request an MTRR or
because it's using /dev/agpgart directly), then it will now end up
with a UC or WC mapping, depending on the architecture and PAT
availability. But cacheable access to the aperture seems like it's
asking for trouble, because, AIUI, the aperture is an alias of RAM.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
Andy Lutomirski [Mon, 13 May 2013 23:58:42 +0000 (23:58 +0000)]
drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.
Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine.
The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
hardcoding the bit twiddling.
The DRM_AGP case is unchanged for now.
[airlied: fix ppc build] Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
projects / linux-beck.git / log