IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Print out the HW context object information per ring. Even though the
existing code only utilizes the render ring, it's simple enough to
support future expansion.
I had this in a patch somewhere in a rev of the original implementation,
but I must have lost it.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: s/context/default context/ bikeshed applied.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yet another remnant ... this might explain why l3 remapping didn't
really work on HSW.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
Spotted-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The bit controlling whether PIPE_CONTROL DW/QW write targets
the global GTT or PPGTT moved moved from DW 2 bit 2 to
DW 1 bit 24 on IVB.
I verified on IVB that the fix is in fact effective. Without the fix
none of the scratch writes actually landed in the pipe control page.
With the fix the writes show up correctly.
v2: move PIPE_CONTROL_GLOBAL_GTT_IVB setup to where other flags are set
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similarly to:
commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Tue Dec 11 15:18:28 2012 +0000
drm/i915: Preserve the FDI line reversal override bit on CPT
DDI port support lane reversal to easy the PCB layouting work. Let's
preserve the bit configured by the BIOS (until we find how to correctly
retrieve the information from the VBT, but this does sound more fragile
then just relying on the BIOS that has, hopefully, been validated
already.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The FDI link has supported link reversal to make the PCB layout
engineer's life easier for quite a while and we have always presered
this bit as we programmed FDI_RX_CTL with a read/modify/write sequence.
We're trying to take a bit more control over what the BIOS leaves in
various register and with the introduction of DDI, started to program
FDI_RX_CTL fully.
There's a fused bit to indicate DMI link reversal and FDI defaults to
mirroring that configuration. We have a bit to override that behaviour
that we need to preserve from the BIOS.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Amending
commit 4518f611ba21ba165ea3714055938a8984a44ff9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jan 23 16:16:35 2013 +0100
drm/i915: dump UTS_RELEASE into the error_state
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Support for real RGB332 is a rarity, most hardware only really support
C8. So use C8 instead of RGB332 when determining the format based on
depth/bpp.
This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not
RGB332.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Tested-by: mlsemon35@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Set depth/bits_per_pixel to 8 for C8 format.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As explained by Chris Wilson gem objects in stolen memory are always
coherent with the GPU so we don't need to ever flush the CPU caches for
these.
This fixes a breakage - at least with the compact sg patches applied -
during the resume/restore gtt mappings path, when we tried to clflush an
FB object in stolen memory, but since stolen objects don't have backing
pages we passed an invalid page pointer to drm_clflush_page().
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If a GPU reset occurs while a page flip has been submitted to the ring,
the flip will never complete once the ring has been reset.
The GPU reset can be detected by sampling the reset_counter before the
flip is submitted, and then while waiting for the flip, the sampled
counter is compared with the current reset_counter value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Move the reset_counter assignment to an earlier place in
common code as discussed on the mailing list.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60140
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pending flip mask no longer set anywhere, so trying to wait for
while it's non-zero is a no-op. Remove it completely.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has been lost in the locking rework for intel_alloc_context_page:
commit 2c34b850ee1e9f86b41706149d0954eee58757a3
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Sat Mar 19 18:14:26 2011 -0700
drm/i915: fix ilk rc6 teardown locking
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already print the HWS addresses during init, so do the same for the
pipe control page. Reduces guesswork when looking at hex addresses
later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the previous patch "drm/i915: disable shared panel fitter for
pipe" we now disable the panel fitter at the right spot in the modeset
sequence in the crtc functions on all platforms. Hence the disabling
in intel_disable_lvds is no longer required and potentially harmful
(since the plane is still enabled at this point).
Similarly on the enabling side we enable the panel fitter in the lvds
callback only once the plane is enabled. Which is too late. Hence move
this into a new intel_pre_enable_lvds callback.
Finally we can ditch lvds_encoder->pfit_dirty - this was required to
work around the crtc helper semantics, but with the new i915 modeset
infrastructure we should enable/disable the pfit only when enabling or
disabling the entire output pipeline. So separate state tracking for
the pfit is no longer required.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Bikeshed the commit message a bit to stress that now we
enable/disable the pfit on i9xx platforms at the right point of time
compared to the old code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If encoder is switched off by BIOS, but the panel fitter is left on,
we never try to turn off the panel fitter and leave it still attached
to the pipe - which can cause blurry output elsewhere.
Based on work by Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
[danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny
comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some early bios versions seem to ship with the wrong tuning values for
the MCH, possible resulting in pipe underruns under load. Especially
on DP outputs this can lead to black screen, since DP really doesn't
like an occasional whack from an underrun.
Unfortunately the registers seem to be locked after boot, so the only
thing we can do is politely point out issues and suggest a BIOS
upgrade.
Arthur Runyan pointed us at this issue while discussion DP bugs - thus
far no confirmation from a bug report yet that it helps. But at least
some of my machines here have wrong values, so this might be useful in
understanding bug reports.
v2: After a bit more discussion with Art and Ben we've decided to only
the check the watermark values, since the OREF ones could be be a
notch more aggressive on certain machines.
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Runyan, Arthur J <arthur.j.runyan@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add an output panel driver for LCD panels. Tested with LCD3 cape on
beaglebone.
v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
Antoniou
v3: add backlight support
v4: rebase to latest of video timing helpers
v5: remove some unneeded fields from panel-info struct, add DT bindings
docs
Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>
Add output panel driver for i2c encoder slaves.
v1: original
v2: add DT bindings docs, and minor updates for review comments
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>
A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
CMA helpers. Currently only the TFP410 DVI encoder is supported
(tested with beaglebone + DVI cape). There are also various LCD
displays, for which support can be added (as I get hw to test on),
and an external i2c HDMI encoder found on some boards.
The display controller supports a single CRTC. And the encoder+
connector are split out into sub-devices. Depending on which LCD
or external encoder is actually present, the appropriate output
module(s) will be loaded.
v1: original
v2: fix fb refcnting and few other cleanups
v3: get +/- vsync/hsync from timings rather than panel-info, add
option DT max-bandwidth field so driver doesn't attempt to
pick a display mode with too high memory bandwidth, and other
small cleanups
v4: remove some unneeded stuff from panel-info struct, properly
set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>
We need to clear the local variable to get the refcounting right
(since the reference drm_mode_setplane holds is transferred to the
plane->fb pointer). But should be done _after_ we update the pointer.
Breakage introduced in
commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Dec 11 00:59:24 2012 +0100
drm: refcounting for sprite framebuffers
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rob Clark <rob@ti.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, "the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certain Extension Blocks".
For more information, please see the EDID spec, check the notes of the
table that explains the "Feature Support" byte (18h) and also the
notes on the tables of the section that explains "Display Range Limits
& Additional Timing Description Definition (tag #FDh)".
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
/me grabs a few brown paper bags
So it looks like I've broken compilation in
commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jan 20 17:32:21 2013 +0100
drm: review locking for drm_fb_helper_restore_fbdev_mode
Fix it up again.
v2: Only deref fbdev_cma once we're sure it's non-NULL, noticed by
Thierry Reding.
Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
that were dropped from linux next because of the merge conflicts
as requested by me and Olof. The reason was that at this point
we really should be able to do the arch/arm related changes
separately from driver changes to avoid dependencies between
branches.
These patches were initially part of the USB related MFD patches.
Based on our comments, Roger Quadros quickly reworked these
patches into a shared branch between ARM SoC tree and the MFD
tree, then separate patches for the OMAP platform data and
MFD driver.
Note that this branch will conflict with c1d1cd597fc7
("ARM: OMAP2+: omap_device: remove obsolete pm_lats and
early_device code"). Please see http://lkml.org/lkml/2013/2/11/16
for the merge resolution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRHR36AAoJEBvUPslcq6Vz6hEQAIIzgO4Rwf55/nMfRyMWqNEF
bM5h8KmMmix0M+MIrCigqciXzEmOY0y95ssQJcdxUoDl3kCpkHfcrxDTQmf6ehGD
cMxYkeYVB9JYDuYr3HUvqv7MvDQIge11Sh1Yfj1YG7UYHNDh5OP+4DBtSGByIhHf
clQ9I3c74EBxqEzyUWlE7BOYH6+WEQ2yh4RzzDnSgiQcyRn25jWd0RpXoroE2XQb
ZsW1wZtpFqsMfHsPrIdHm5KLsgn9tSvWZ+NEUlXVqnNumdl3zaxX65fOGNWGjAax
A8JRpntvwcGGl6XV54mCVV/yuStuA7kdDn9ABnghUFy8ZzgRA2hvJFe0Kc5lUgO1
RRKQ4+fsFyPYDyvMmo4tYsNOXxW+DryHSxvhUICHqjKvXyWEUSTHLJ3vHIvq2zjZ
cYV+opeZkF6ddwUhPhIVYUmFDfZeCriqOUlVnQYLxqAzRSTEk5buNW58WtX4ZNA1
f6k1xlepsLCvuMAr8IGZyWnM6SH3k+/f0Hs9Pl8mijV/nNSaF8JW4k9NVPnFwT9Q
PcwVhT23mLkKLr5ab03EEzCs/2a3VTkmUbQm70tC2FTtMQTwmHCpg+WQMf+aug6e
8++A6V+GqZ6ggW5rV95jJsJ39hBAAK0lCld+fNZ5MjQgMwlAe+mdl6FrQWib1TFa
obIzQnfifyPjomrRAdu5
=svW/
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v3.9/usb-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/soc
These changes contain the OMAP USB related platform data changes
that were dropped from linux next because of the merge conflicts
as requested by me and Olof. The reason was that at this point
we really should be able to do the arch/arm related changes
separately from driver changes to avoid dependencies between
branches.
These patches were initially part of the USB related MFD patches.
Based on our comments, Roger Quadros quickly reworked these
patches into a shared branch between ARM SoC tree and the MFD
tree, then separate patches for the OMAP platform data and
MFD driver.
Note that this branch will conflict with c1d1cd597fc7
("ARM: OMAP2+: omap_device: remove obsolete pm_lats and
early_device code"). Please see http://lkml.org/lkml/2013/2/11/16
for the merge resolution.
[arnd - resolved the merge conflict]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Simplify life for drivers using an encoder-slave, so that they can make
their drm_encoder_helper_funcs const, rather than needing to dynamically
allocate and populate them.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add helper to display fb's which can be used directly in drm_info_list:
static struct drm_info_list foo_debugfs_list[] = {
...
{ "fb", drm_fb_cma_debugfs_show, 0 },
};
to display information about CMA fb objects, as well as a
drm_gem_cma_describe() which can be used if the driver bothers to keep
a list of CMA GEM objects.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Initialize e->pipe.. some drivers set this themselves, others do not.
Setting it in drm_send_vblank_event() should help ensure more consistent
behavior with the different drivers.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We need to clear the local variable to get the refcounting right
(since the reference drm_mode_setplane holds is transferred to the
plane->fb pointer). But should be done _after_ we update the pointer.
Breakage introduced in
commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Dec 11 00:59:24 2012 +0100
drm: refcounting for sprite framebuffers
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
/me grabs a few brown paper bags
So it looks like I've broken compilation in
commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jan 20 17:32:21 2013 +0100
drm: review locking for drm_fb_helper_restore_fbdev_mode
Fix it up again.
Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will result in badness for drivers that do not implement
mode_set_base_atomic(). So don't pretend like we can support this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We don't need to hold onto mode_config.mutex any more to keep the fb
objects around. And locking dev->struct_mutex is also not required,
since omap_gem_describe only reads data anyway. And for a debug
interface it's better to grab fewer locks in case the driver is
deadlocked already ...
The only thing we need is to hold onto mode_config.fb_lock to ensure
the user-created fbs don't disappear. The fbcon fb doesn't need any
protection, since it lives as long as the driver (and so the debugfs
files) itself. And if the teardown/setup isn't following the right
sequence grabbing locks won't prevent a NULL deref on priv->fbdev if
the fb is not yet (or no longer) there.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Omapdrm doesn't do anything nefarious with crtc load detection or has
any shared resources, so this is enough. We also need to adjust the
WARN_ON.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Now that the omapdss interface has been reworked so that omapdrm can use
dispc directly, we have been able to fix the remaining functional kms
issues with omapdrm. And in the mean time the PM sequencing and many
other of that open issues have been solved. So I think it makes sense
to finally move omapdrm out of staging.
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's not that the assertion is incorrect, but rather that we can call
do_destroy early in loading, and we will falsely BUG().
Since contexts have been in for a while now, and in the internal APIs
are pretty stable, it should be fairly safe to remove this.
v2: Remove unused dev_priv, and dev
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ring initialization will differ a bit in upcoming generations, and
this split will prepare the code for what's needed.
This patch also fixes a bug introduced in:
commit 99433931950f33039d9e1a52b4ed9af3f1b58e84
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Jan 22 14:12:17 2013 +0200
drm/i915: use gem_set_seqno() on hardware init
After doing the extraction, the bad error handling became obvious. I
acknowledge that this should be two patches, but it's a pretty
small/trivial patch. If requested, I can certainly do the fix as a
distinct patch.
v2: Should be cleanup blt, not init blt on failure (Chris)
v3: Forgot to git add on v2
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When I refactored the code initially, I forgot that gen2 uses a
different bar for the CPU mappable aperture. The agp-less code knows
nothing of generations less than 5, so we have to expand the gtt_probe
function to include the mappable base and end.
It was originally broken by me:
commit baa09f5fd8a6d033ec075355dda99a65b7f6a0f3
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu Jan 24 13:49:57 2013 -0800
drm/i915: Add probe and remove to the gtt ops
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So we can remove duplicated code. Note that this function is used not
only on IBX, but also CPT and LPT.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Also bikeshed s/ironlake_enable_pch_hotplug/ibx_enable_hotplug
to keep consistent with our ibx for pch naming scheme.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have more than one sprite, so a boolean simply won't cut it.
Turn sprite_scaling_enabled into a bitmask and track the state
of sprite scaler for each sprite independently.
Also don't re-enable LP watermarks until the sprite registers
have actually been written, and thus sprite scaling has really
been disabled.
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>
They're physically the same pins and also the same bits, duplicating
only confuses the reader. This also makes it a bit obvious that we
have quite some code duplication going on here. Squashing that is for
a larger rework in our hpd handling though.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was a rebase error from when the patches originally landed. Since
the context size is unsigned, there is also no use in checking if it's
less than 0.
The existing code is not really wrong, but it's not simple as it should
be.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai <tiwai@suse.de>
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the drm fb helper cleanup, mostly motivated by strange things I've
seen in my locking rework and the i915 modeset revamp. Compared to the
original submission I've reinstated the setup flexibility you'd like to
retain, kerneldoc has been reviewed by Laurent Pinchart and Rob Clark
reviewed the code changes.
Quick overview of the changes:
- Cleaned-up library interface for drivers using the fb helper, also
simplified the fb allocation callback since no driver supported
reallocating the fb on-the-fly. And the fbdev/fbcon code keeps pointers
to the old mapping around anyway, so reallocating backing storage will
be much more work.
- No longer call the crtc helper "disable everything" function at init
time, but allow drivers to do so. Motivated by i915's fastboot effort
and allows us to drop a bunch of noop dummy functions just to avoid
calling NULL function pointers from i915.ko.
- Properly clear old state when doing modeset calls, the fb helper left
some old modes in there and unconditionally set an fb (even when
disabling a crtc). The crtc helpers didn't care, but i915 modeset code
can now drop a few special cases.
- Full kerneldoc for the fb helper. Yay!
- My version of the "don't sleep in panic ->unblank calls". The patch is
already in -mm, I guess Andrew can drop it as soon as this pull lands in
drm-next.
* 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm:
drm/fb-helper: remove unused members of struct drm_fb_helper
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress
drm/fb-helper: improve kerneldoc
drm/<drivers>: simplify ->fb_probe callback
drm/fb-helper: streamline drm_fb_helper_single_fb_probe
drm/fb-helper: directly call set_par from the hotplug handler
drm/fb-helper: fixup set_config semantics
drm/i915: rip out helper->disable noop functions
drm/fb-helper: don't disable everything in initial_config
drm/tegra: don't set up initial fbcon config twice
drm/fb-helper: unexport drm_fb_helper_single_fb_probe
drm/fb-helper: unexport drm_fb_helper_panic
drm/fb-helper: kill drm_fb_helper_restore
drm: review locking for drm_fb_helper_restore_fbdev_mode
My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds.
I get it the first time that the entire block is all 0xff..
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [v3.7]
Signed-off-by: Dave Airlie <airlied@redhat.com>
On tile architecture (with "make allyesconfig") including
<linux/swiotlb.h> is required to call swiotlb_nr_tbl().
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move drm_pcie_get_speed_cap_mask() under #ifdef CONFIG_PCI because it
it used only for PCI devices (evergreen, r600, r770), and it uses
PCI interfaces that only exist when CONFIG_PCI=y.
Previously, we tried to compile drm_pcie_get_speed_cap_mask() even when
CONFIG_PCI=n, which fails.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
i915 driver needs to do modeset when
1. system resumes from sleep
2. lid is opened
In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
thus it is the i915_resume code does the modeset rather than intel_lid_notify().
But in PM_SUSPEND_FREEZE state, this will be broken because
system is still responsive to the lid events.
1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid.
2. When we reopen the lid, intel_lid_notify() will do a modeset,
before the system is resumed.
here is the error log,
[92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]()
[92146.548076] Hardware name: VGN-Z540N
[92146.548078] pipe_off wait timed out
[92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e
[92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G W 3.8.0-rc3-s0i3-v3-test+ #9
[92146.548175] Call Trace:
[92146.548189] [<c10378e2>] warn_slowpath_common+0x72/0xa0
[92146.548227] [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548263] [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548270] [<c10379b3>] warn_slowpath_fmt+0x33/0x40
[92146.548307] [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548344] [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915]
[92146.548380] [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915]
[92146.548417] [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915]
[92146.548456] [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915]
[92146.548493] [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
[92146.548535] [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915]
[92146.548543] [<c15610d3>] notifier_call_chain+0x43/0x60
[92146.548550] [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80
[92146.548556] [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30
[92146.548563] [<c131a684>] acpi_lid_send_state+0x78/0xa4
[92146.548569] [<c131aa9e>] acpi_button_notify+0x3b/0xf1
[92146.548577] [<c12df56a>] ? acpi_os_execute+0x17/0x19
[92146.548582] [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc
[92146.548589] [<c12e2b82>] acpi_device_notify+0x16/0x18
[92146.548595] [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f
[92146.548600] [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b
[92146.548607] [<c1051208>] process_one_work+0x128/0x3f0
[92146.548613] [<c1564f73>] ? common_interrupt+0x33/0x38
[92146.548618] [<c104f8c0>] ? wake_up_worker+0x30/0x30
[92146.548624] [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e
[92146.548629] [<c10524f9>] worker_thread+0x119/0x3b0
[92146.548634] [<c10523e0>] ? manage_workers+0x240/0x240
[92146.548640] [<c1056e84>] kthread+0x94/0xa0
[92146.548647] [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
[92146.548652] [<c15649b7>] ret_from_kernel_thread+0x1b/0x28
[92146.548658] [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0
three different modeset flags are introduced in this patch
MODESET_ON_LID_OPEN: do modeset on next lid open event
MODESET_DONE: modeset already done
MODESET_SUSPENDED: suspended, only do modeset when system is resumed
In this way,
1. when lid is closed, MODESET_ON_LID_OPEN is set so that
we'll do modeset on next lid open event.
2. when lid is opened, MODESET_DONE is set
so that duplicate lid open events will be ignored.
3. when system suspends, MODESET_SUSPENDED is set.
In this case, we will not do modeset on any lid events.
Plus, locking mechanism is also introduced to avoid racing.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
