Fixes "BUG: spinlock bad magic" on module load for nva3+ cards.
Introduced in commit "drm/nouveau/therm: implement support for temperature
alarms".
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
the variable chan is dereferenced in line 190, so it is no reason to check
null again in line 198.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It's safe to call kfree(NULL).
Found by smatch.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
fan->get returns int, but we write it to unsigned variable, and then check
whether it's >= 0 (it always is)
Found by smatch:
drivers/gpu/drm/nouveau/core/subdev/therm/fan.c:61 nouveau_fan_update() warn: always true condition '(duty >= 0) => (0-u32max >= 0)'
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
COPY_ZM_REG: destination and source addresses were swapped
RAM_RESTRICT_ZM_REG_GROUP: missing 0x prefix for register address
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We already rely on them having the same fields and layout.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This fixes a bug where, when temperature is outside of the linear range, fan
pwm would be outside of the allowed range ([0, 100]) and could get negative in
some cases.
It seems like a regression that happened when we re-worked the fan management
logic before merging.
Tested-by: Ozan Çağlayan <ozancag@gmail.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
- record channel owner process name
- add some helpers for accessing this information
- let nouveau_enum hold additional value (will be needed in the next patch)
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This should avoid the situation where a user gets its kernel logs flooded when
temperature oscillates around a threshold with 0°C hysteresis.
This patch is just meant to fix broken vbios (as reported on a nv4e on
sysfs hwmon interface.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit 767baf82 drm/nouveau: remove some more unnecessary legacy bios code
has introduced a regression my misplacing the code that sets the major/chip
versions, which are used whist parsing the bmp/bit structure in vbios
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
My GTX660 has the GPIO_FAN function, but it's configured in input-mode;
presumably to monitor the frequency set by an I2C fan controller?
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Expose all the hysteresis parameters + shutdown (emergency) +
fan_boost (fixed pwm trip point).
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
For now, we only boost the fan speed to the maximum and auto-mode
when hitting the FAN_BOOST threshold and halt the computer when it
reaches the shutdown temperature. The downclock and critical thresholds
do nothing.
On nv43:50 and nva3+, temperature is polled because of the limited hardware.
I'll improve the nva3+ situation by implementing alarm management in PDAEMON
whenever I can but polling once every second shouldn't be such a problem.
v2 (Ben Skeggs):
- rebased
v3: fixed false-detections and threshold reprogrammation handling on nv50:nvc0
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
We are going to use PTHERM's IRQs for thermal monitoring but we need to route
them first.
On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs.
It seems like nv10-31 GPIO interruptions aren't well handled. I kept the
original behaviour but it is wrong and may lead to an IRQ storm.
Since we enable all PBUS IRQs, we need a way to avoid being stormed if we
don't handle them. The solution I used was to mask the IRQs that have not been
handled. This will also print one message in the logs to let us know.
v2: drop the shared intr handler because of was racy
v3: style fixes
v4: drop a useless construct in the chipset-dependent INTR
v5: add BUS to the disable mask
v6 (Ben Skeggs):
- general tidy to match the rest of the driver's style
- nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes
that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's
not going to conflict
- removed the peephole and user stuff, for the moment.. will handle them
later if we find a good reason to actually care..
- limited INTR_EN to just what we can handle for now, mostly to prevent
spam of unknown status bits (seen on at least nv4x)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
v2: improved design but drops safety monitoring (to be in a later patch)
v3: fix locking and mode management
v4: gently fallback to the no-control mode when temperature cannot be got
and use kernel-provided min/max macros
v5 (Ben Skeggs):
- rebased on my previous patches
v6: fix hysterisis management in trip-based auto fan management
This commit also forbids access to fan management to nvc0+ chipsets as
fan management is already taken care of my PDAEMON's default fw.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
v2 (Ben Skeggs):
- split from larger patch
- fixed to not require alarm resched patch
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
v2: change percent from int to atomic_t
v3: random fixes
v4 (Ben Skeggs):
- adapted for split-out fan-control "protocol" structure
- removed need for timer resched
- support for forcing 'toggle' control on PWM boards
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Mostly to allow for the possibility of testing 'toggle' fan control easily.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
This info will be used by two more implementations in upcoming commits.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
So here's my promised pile of fixes for 3.9. I've dropped the core prep
patches for vt-switchless suspend/resume as discussed on irc. Highlights:
- Fix dmar on g4x. Not really gfx related, but I'm fed up with getting
blamed for dmar crapouts.
- Disable wc ptes updates on ilk when dmar is enabled (Chris). So again,
dmar, but this time gfx related :(
- Reduced range support for hsw, using the pipe CSC (Ville).
- Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is
already confirmed to fix 2 bug reports, so added cc: stable on that one.
- Regression fix for 8bit fb console (Ville).
- Preserve lane reversal bits on DDI/FDI ports (Damien).
- Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of
them, need to decide what to do with the currently still in-flight ones.
- Panel fitter regression fix from Mika Kuoppala (was accidentally left on
on some pipes with the new modset code since 3.7). This also improves
the modeset sequence and might help a few other unrelated issues with
lvds.
- Write backlight regs even harder ... another installement in our eternal
fight against the BIOS and backlights.
- Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for
new ACPI stuff, but closing the race itself seems worthwile on its own.
- A few other small fixes and tiny cleanups all over.
Lots of the patches are cc: stable since I've stalled on a few
not-so-important fixes for 3.8 due to the grumpy noise Linus made.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits)
intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
drm/i915: Implement pipe CSC based limited range RGB output
drm/i915: inverted brightness quirk for Acer Aspire 4736Z
drm/i915: Print the hw context status is debugfs
drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+
drm/i915: Set i9xx sdvo clock limits according to specifications
drm/i915: Set i9xx lvds clock limits according to specifications
drm/i915: Preserve the DDI link reversal configuration
drm/i915: Preserve the FDI line reversal override bit on CPT
drm/i915: add missing \n to UTS_RELEASE in the error_state
drm: Use C8 instead of RGB332 when determining the format from depth/bpp
drm: Fill depth/bits_per_pixel for C8 format
drm/i915: don't clflush gem objects in stolen memory
drm/i915: Don't wait for page flips if there was GPU reset
drm/i915: Kill obj->pending_flip
drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment
drm/i915: remove bogus mutex_unlock from error-path
drm/i915: Print the pipe control page GTT address
...
HSW no longer has the PIPECONF bit for limited range RGB output.
Instead the pipe CSC unit must be used to perform that task.
The CSC pre offset are set to 0, since the incoming data is full
[0:255] range RGB, the coefficients are programmed to compress the
data into [0:219] range, and then we use either the CSC_MODE black
screen offset bit, or the CSC post offsets to shift the data to
the correct [16:235] range.
Also have to change the confiuration of all planes so that the
data is sent through the pipe CSC unit. For simplicity send the
plane data through the pipe CSC unit always, and in case full
range output is requested, the pipe CSC unit is set up with an
identity transform to pass the plane data through unchanged.
I've been told by some hardware people that the use of the pipe
CSC unit shouldn't result in any measurable increase in power
consumption numbers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 4518f611ba
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 2c34b850ee
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 6c2a75325c
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 6aed8ec3f7
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>
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 6c2a75325c
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 6aed8ec3f7
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 9943393195
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 baa09f5fd8
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>
770c12312a is the first bad commit
commit 770c12312a
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>
The RC6 VIDS has a linear ramp starting at 250mv, which means any values
below 250 are invalid. The old buggy macros tried to adjust for this to
be more flexible, but there is no need. As Dan pointed out the ENCODE
only ever has one value. The only invalid value for decode is an input
of 0 which means something is really wonky, and the cases where DECODE
are used either don't matter (debug values), or would be implicitly
correct (the check for less than 450).
This patch makes simpler, easier to read macros which are actually
correct. Maybe this patch can actually fix some bugs now.
Thanks to Dan for catching this. /me hides
Cc: stable@kernel.org
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.
Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out. Inspired by a patch
from Konstantin Khlebnikov. The callchain leading to this, cut&pasted
from Konstantin's original patch:
callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
drm_modeset_lock_all()
mutex_lock(&dev->mode_config.mutex)
Note that the entire locking in the fb helper around panic/sysrq and
kdbg is ... non-existant. So we have a decent change of blowing up
everything. But since reworking this ties in with funny concepts like
the fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.
v2: Drop the -EBUSY return value I've copied, we don't need it since
the we'll take care of things ourselves anyway.
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
References: https://patchwork.kernel.org/patch/1878181/
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.
I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.
Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...
v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
Dave Airlie didn't want me to kill this one from the fb helper
interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
from the driver's ->fb_probe callback to setup the fbdev info
structure.
- Clarify what the ->fb_probe callback should all do - it needs to
setup both the fbdev info and allocate the drm framebuffer used as
backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
vfunc.
v3: Implement clarifications Laurent Pinchart suggested in his review.
v4: Fix another mispelling Laurent spotted.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to check whether we've allocated a new fb since we're not
always doing that. Also, we always need to register the fbdev and add
it to the panic notifier.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The idea behind calling down into the driver's ->fb_probe function on each
hotplug seems to be able to reallocate the backing storage (if e.g. a screen
with higher resolution gets added). But that requires quite a bit of work in the
fb helper itself, since currently we limit new screens to the currently
allocated fb. An no kms driver supports fbdev fb resizing.
So don't bother and start to simplify the code by calling drm_fb_helper_set_par
directly from the fbdev hotplug function, since that's the only thing left in
drm_fb_helper_single_fb_probe which does not concern itself with fb allocation
and initial setup. Follow-on patches will streamline the initial setup
code.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
screen).
- It unconditionally sets the fb, even if no mode will be set on a
given crtc.
- The initial setup is a bit fun since we need to pick crtcs to decide
the desired fb size, but also should set the modeset->fb pointer.
Explain what's going on in the fixup code after the fb is allocated.
The crtc helper didn't really care, but the new i915 modeset
infrastructure did, so I've had to add a bunch of special-cases to
catch this.
Fix this all up and enforce the interface by converting the checks in
drm/i915/intel_display.c to BUG_ONs.
v2: Fix commit message spell fail spotted by Rob Clark.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
through the real interface vfuncs, forcing i915 to fake all the
->disable callbacks used by the crtc helper to avoid ugly Oopsen
v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_fbdev_cma_init does the inital fbcon setup by calling down into
drm_fb_helper_initial_config, so no need at all to restore the just
set up configuration right away ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not called by anyone, and really, shouldn't be. Drivers are supposed
either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
Originally this was done differently, but is now consolidated in the
helper functions and no longer done by drivers directly.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It doesn't even show up in any header files and only used iternally.
Originally it was (ab)used to restore the fbcon on lastclose, but that
died with
commit e8e7a2b8cc
Author: Dave Airlie <airlied@redhat.com>
Date: Thu Apr 21 22:18:32 2011 +0100
drm/i915: restore only the mode of this driver on lastclose (v2)
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's only used internally for the sysrq and panic handlers provided by
the drm fb helper implementation. Hence just inline it, kill the
export and remove the confusing kerneldoc. Driver's are supposed to
call drm_fb_helper_restore_fbdev_mode on lastclose.
Note that locking is totally fubar - the sysrq case doesn't take any
locks at all. The panic handler probably shouldn't take any locks
since it'll only make things worse. Otoh it's probably better to
switch things over to the atomic modeset callbacks (and disable the
panic handler for those drivers which don't implement it).
But that's both better done in separate patches.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... it's required. Fix up exynos and the cma helper, and add a
corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.
Note that tegra calls the fbdev cma helper restore function also from
it's driver-load callback. Which is a bit against current practice,
since usually the call is only from ->lastclose, and initial setup is
done by drm_fb_helper_initial_config.
Also add the relevant drm DocBook entry.
v2: Add promised WARN to restore_fbdev_mode.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 6f33814bd4.
The quirk cause a regression, and it looks like the original bug was
simply a lack of FIFO bandwidth on the i915G of the reporter. Which
should eventually be fixed as soon as we get around to implemented
DSPARB FIFO reassignment on gen 3.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
TTM reservations changes, preparing for new reservation mutex system.
* 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux:
drm/ttm: unexport ttm_bo_wait_unreserved
drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2
drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2
drm/ttm: add ttm_bo_reserve_slowpath
drm/ttm: cleanup ttm_eu_reserve_buffers handling
drm/ttm: remove lru_lock around ttm_bo_reserve
drm/nouveau: increase reservation sequence every retry
drm/vmwgfx: always use ttm_bo_is_reserved
It is a bit more precise to compute the total number of pixels first and
then divide, rather than multiplying the line pixel count by the
already-rounded line duration.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use PCI Express Capability access functions to simplify this code a bit.
For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link
Capabilities 2 register, pcie_capability_read_dword() reads a zero.
Since we're only testing whether the bits we care about are set, there's no
need to mask out the other bits we *don't* care about.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For devices that conform to PCIe r3.0 and have a Link Capabilities 2
register, we test and report every bit in the Supported Link Speeds Vector
field. For a device that supports both 2.5GT/s and 5.0GT/s, we set both
DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask.
For pre-r3.0 devices, the Link Capabilities 0010b encoding
(PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are
supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this
case as well.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use the standard #defines rather than bare numbers for the PCIe Link
Capabilities speed bits.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Drivers that register interrupt handlers without the DRM core helpers
don't initialize the .irq_enabled field and drm_dev_to_irq() may fail
when called on them. This shouldn't preclude them from implementing
the vblank IOCTL.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
v2:
- Rename functions to radeon_gem_prime_get_sg_table and
radeon_gem_prime_import_sg_table.
- Delete the now-unused vmapping_count variable.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
v2: Rename functions to nouveau_gem_prime_get_sg_table and
nouveau_gem_prime_import_sg_table.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook functions:
gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT
gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export
gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
gem_prime_vmap, gem_prime_vunmap: map and unmap an object
These hooks are optional; drivers can opt in by using drm_gem_prime_import and
drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of
struct drm_driver.
v2:
- Drop .begin_cpu_access. None of the drivers this code replaces implemented
it. Having it here was a leftover from when I was trying to include i915 in
this rework.
- Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
did. This patch series shouldn't change that behavior.
- Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
Rename struct sg_table* variables to 'sgt' for clarity.
- Update drm.tmpl for these new hooks.
v3:
- Pass the vaddr down to the driver. This lets drivers that just call vunmap on
the pointer avoid having to store the pointer in their GEM private structures.
- Move documentation into a /** DOC */ comment in drm_prime.c and include it in
drm.tmpl with a !P line. I tried to use !F lines to include documentation of
the individual functions from drmP.h, but the docproc / kernel-doc scripts
barf on that file, so hopefully this is good enough for now.
- apply refcount fix from commit be8a42ae60
("drm/prime: drop reference on imported dma-buf come from gem")
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move this out of nouveau directory. As we start to add more encoder
slaves used by other drivers, it makes sense to put the Kconfig bits in
one place.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex writes:
- CS ioctl cleanup and unification. Unification of a lot of functionality
that was duplicated across multiple generates of hardware.
- Add support for Oland GPUs
- Deprecate UMS support. Mesa and the ddx dropped support for UMS and
apparently very few people still use it since the UMS CS ioctl was broken
for several kernels and no one reported it. It was fixed in 3.8/stable.
- Rework GPU reset. Use the status registers to determine what blocks
to reset. This better matches the recommended reset programming model.
This also allows us to properly reset blocks besides GFX and DMA.
- Switch the VM set page code to use an IB rather than the ring. This
fixes overflow issues when doing large page table updates using a small
ring like DMA.
- Several small cleanups and bug fixes.
* 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux: (38 commits)
drm/radeon/dce6: fix display powergating
drm/radeon: add Oland pci ids
drm/radeon: radeon-asic updates for Oland
drm/radeon: add ucode loading support for Oland
drm/radeon: fill in gpu init for Oland
drm/radeon: add Oland chip family
drm/radeon: switch back to using the DMA ring for VM PT updates
drm/radeon: use IBs for VM page table updates v2
drm/radeon: don't reset the MC on IGPs/APUs
drm/radeon: use the reset mask to determine if rings are hung
drm/radeon: halt engines before disabling MC (si)
drm/radeon: halt engines before disabling MC (cayman/TN)
drm/radeon: halt engines before disabling MC (evergreen)
drm/radeon: halt engines before disabling MC (6xx/7xx)
drm/radeon: use status regs to determine what to reset (si)
drm/radeon: use status regs to determine what to reset (cayman)
drm/radeon: use status regs to determine what to reset (evergreen)
drm/radeon: use status regs to determine what to reset (6xx/7xx)
drm/radeon: rework GPU reset on cayman/TN
drm/radeon: rework GPU reset on cayman/TN
...
videomode helpers for of + devicetree stuff, required for new kms drivers
(not the fbdev maintainer).
* tag 'of_videomode_helper' of git://git.pengutronix.de/git/str/linux:
drm_modes: add of_videomode helpers
drm_modes: add videomode helpers
fbmon: add of_videomode helpers
fbmon: add videomode helpers
video: add of helper for display timings/videomode
video: add display_timing and videomode
viafb: rename display_timing to via_display_timing
Fixes for usb/udl devices
* udl-fixes:
drm/udl: disable fb_defio by default
drm/udl: Inline memcmp() for RLE compression of xfer
drm/udl: make usage as a console safer
drm/usb: bind driver to correct device
This pulls in most of Linus tree up to -rc6, this fixes the worst lockdep
reported issues and re-enables fbcon lockdep.
(not the fbcon maintainer)
* 'fbcon-locking-fixes' of ssh://people.freedesktop.org/~airlied/linux: (529 commits)
Revert "Revert "console: implement lockdep support for console_lock""
fbcon: fix locking harder
fb: Yet another band-aid for fixing lockdep mess
fb: rework locking to fix lock ordering on takeover
Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.
In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,
this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.
This should fix the efifb regression seen by Maarten.
Tested-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Lu Hua <huax.lu@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There seems to be a bad interaction between gem/shmem and defio on top,
I get list corruption on the page lru in the shmem code.
Turn it off for now until we get some more digging done.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
As we use a variable length the compiler does not realise that it is a
fixed value of either 2 or 4 bytes. Instead of performing the inline
comparison itself, the compiler inserts a function call to the generic
memcmp routine which is optimised for long comparisons of variable
length. That turns out to be quite expensive...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel writes:
"Probably the last feature pull for 3.9, there's some fixes outstanding
thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ...
Anyway, highlights of this pull:
- Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements
on vlv, big thanks to Ville.
- Dynamic power well support for Haswell, shaves away a bit when only
using the eDP port on pipe A (Paulo). Plus unclaimed register fixes
uncovered by this.
- Clarifications of the gpu hang/reset state transitions, hopefully fixing
a few spurious -EIO deaths in userspace.
- Haswell ELD fixes.
- Some more (pp)gtt cleanups from Ben.
- A few smaller things all over.
Plus all the stuff from the previous rather small pull request:
- Broadcast RBG improvements and reduced color range fixes from Ville.
- Ben is on a "kill legacy gtt code for good" spree, first pile of patches
included.
- No-relocs and bo lut improvements for faster execbuf from Chris.
- Some refactorings from Imre."
* tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits)
GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c
drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too
drm/i915: Kill IS_DISPLAYREG()
drm/i915: Introduce i915_vgacntrl_reg()
drm/i915: gen6_gmch_remove can be static
drm/i915: dynamic Haswell display power well support
drm/i915: check the power down well on assert_pipe()
drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A
drm/i915: don't run hsw power well code on !hsw
drm/i915: kill cargo-culted locking from power well code
drm/i915: Only run idle processing from i915_gem_retire_requests_worker
drm/i915: Fix CAGF for HSW
drm/i915: Reclaim GTT space for failed PPGTT
drm/i915: remove intel_gtt structure
drm/i915: Add probe and remove to the gtt ops
drm/i915: extract hw ppgtt setup/cleanup code
drm/i915: pte_encode is gen6+
drm/i915: vfuncs for ppgtt
drm/i915: vfuncs for gtt_clear_range/insert_entries
drm/i915: Error state should print /sys/kernel/debug
...
Okay you don't really want to use udl devices as your console, but if
you are unlucky enough to do so, you run into a lot of schedule while atomic
due to printk being called from all sorts of funky places. So check if we
are in an atomic context, and queue the damage for later, the next printk
should cause it to appear. This isn't ideal, but it is simple, and seems to
work okay in my testing here.
(dirty area idea came from xenfb)
fixes a bunch of sleeping while atomic issues running fbcon on udl devices.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
While looking at plymouth on udl I noticed that plymouth was trying
to use its fb plugin not its drm one, it was trying to drmOpen a driver called
usb not udl, noticed that we actually had out driver pointing at the wrong
device.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Only enable it when we disable the display rather than
at DPMS time since enabling it requires a full modeset
to restore the display state. Fixes blank screens in
certain cases.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Pull radeon fixes from Dave Airlie:
"I got these late last week, the main chunks of these fix a rendering
regression since 3.7, and the settle ones all fix the issue where we
don't wait long enough for the memory controller to settle after
turning it off which causes bad memory reads, they all fix real users
bugs, and most of them are destined for stable.
Can't remember if you had net connection on that island :-)"
I don't know if the "two tin-cans and a string" thing here on "that
island" can really be considered internet, but I guess I can pull
things. Barely.
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: switch back to the CP ring for VM PT updates
drm/radeon: prevent crash in the ring space allocation
drm/radeon: Calling object_unrefer() when creating fb failure
drm/radeon/r5xx-r7xx: wait for the MC to settle after MC blackout
drm/radeon/evergreen+: wait for the MC to settle after MC blackout
drm/radeon: protect against div by 0 in backend setup
drm/radeon: fix backend map setup on 1 RB sumo boards
drm/radeon: add quirk for RV100 board
drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN
drm/radeon: fix MC blackout on evergreen+
Now that we have switched to using IBs for page table updates,
we can switch back the using the DMA ring.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For very large page table updates, we can exceed the
size of the ring. To avoid this, use an IB to perform
the page table update.
v2(ck): cleanup the IB infrastructure and the use it instead
of filling the struct ourself.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
acpi_bus_get_device() returns int not acpi_status.
The patch change not to apply ACPI_FAILURE() to the return value of
acpi_bus_get_device().
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fetch the reset mask and check if the relevant ring flags
are set to determine whether the ring is hung or not.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Marcin Slusarz