This simplifies cleanup paths and fixes a probe time crash in the error
path when trying to cleanup mode setting before it was initialized.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Warning that an invalid value is valid doesn't make much sense, fix the
message.
Reported-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
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>
The enabled field has been removed from struct drm_plane. Don't use it
in the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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:
// Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
//
// S0: P00-01 P02-03 P04-05 P06-07 P08-09 P10-11 P12-13 P14-15
// S1: P16-17 P18-19 P20-21 P22-23 P24-25 P26-27 P28-29 P30-31
// S2: P32-33 P34-35 P36-37 P38-39 P40-41 P42-43 P44-45 P46-47
// S3: P48-49 P50-51 P52-53 P54-55 P56-57 P58-59 P60-61 P62-63
// S4: X63-56 X55-48 X47-40 X39-32 X31-24 X23-16 X15-08 X07-00
// S5: A63-56 A55-48 A47-40 A39-32 A31-24 A23-16 A15-08 A07-00
//
// S0 to S5 = Slices 0 to 5
// P00 to P63 = Bitmap - pixels 0 to 63
// X00 to X63 = always 0 - pixels 0 to 63
// A00 to A63 = transparent markers - pixels 0 to 63
// 1 means colour, 0 means transparent
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>
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>
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>
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>
There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly. Eliminate them.
v2: Remove all of it from kernel-doc too
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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>
plane->enabled is never set, so this code didn't do anything.
Also drm_fb_helper_restore_fbdev_mode() will now disable all cursors
and sprites for us, so we don't have to bother anymore.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
v2: Follow the drm_crtc documentation fixes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
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>
drm_plane_force_disable() will forcibly disable the plane even if user
had previously requested the plane to be enabled.
This can be used to force planes to be off when restoring the fbdev
mode.
The code was simply pulled from drm_framebuffer_remove(), which now
calls the new function as well.
v2: Check plane->fb in drm_plane_force_disable(), drop bogus comment
about disabling crtc
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
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>
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>
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>
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
...
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>
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>
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>
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
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>
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>
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() produces:
DRM_FORMAT_XRGB8888: "XR24 little-endian (0x34325258)"
DRM_FORMAT_YUYV: "YUYV little-endian (0x56595559)"
DRM_FORMAT_RGB565|DRM_FORMAT_BIG_ENDIAN: "RG16 big-endian (0xb6314752)"
Unprintable characters: "D??? big-endian (0xff7f0244)"
v2: Fix patch author
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This allows importing bo's to own device to work without requiring that the buffer is pinned in GART.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Prevents buffers from being pinned forever.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The CMA-specific mapping code will be used to implement dma-buf mmap
support.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
The dma-buf mmap code was copied from the GEM mmap implementation.
Replace it with the new drm_gem_mmap_obj() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
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>
It just prints whether it's supported/enabled/disabled. Feature
requested by the power management team.
v2: Checkpatch started complaining about seq_printf with 1 argument.
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>
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>
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>
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.
For reference see
commit 2124b72e62
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Mar 22 14:07:23 2013 -0300
drm/i915: don't disable the power well yet
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>
This will let userland only try to use the new ring
when the appropriate kernel is present
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
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>
A user can run batchbuffer via VEBOX ring.
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
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>
v2: Removed rebase relic VECS ring from i915_gem_request_info (Damien)
v3: s/hsw/hws in debugfs which I introduced in v2 (Jon)
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
[Order changed, and modified by]
CC: "Bloomfield, Jon" <jon.bloomfield@intel.com>
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>
Similar to a patch originally written by:
v2: Reversed the meanings of masked and enabled (Haihao)
Made non-destructive writes in case enable/disabler rps runs first
(Haihao)
v3: Reword error message (Damien)
Modify postinstall to do the right thing based on previous fixup. (Ben)
CC: Xiang, Haihao <haihao.xiang@intel.com>
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>
v2: Use the correct lock to protect PM interrupt regs, this was
accidentally lost from earlier (Haihao)
Fix return types (Ben)
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>
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>
It's overkill on older gens, but it's useful for newer gens.
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>
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.
Disable RPS events:
IER := IER & ~GEN6_PM_RPS_EVENTS // Disable RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Disable any outstanding interrupts
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>
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>
