* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: Fix wrong initializer for "locked" variable in assert_panel_unlocked
i915: do not setup intel_backlight twice
Otherwise it just contains random memory.
Issue detected by cppcheck.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data
to i2c bus for a HDMI connector that is not implemented/existent
on the notebook's board.
Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC Lines
Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook
BugLink: http://bugs.launchpad.net/bugs/826677
Signed-off-by: Thomas Reim <reimth@gmail.com>
Acked-by: Chris Routh <routhy@gmail.com>
Cc: <stable@kernel.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was true for new TTM_PL_SYSTEM and new TTM_PL_TT cases, but wasn't
the case on TTM_PL_SYSTEM<->TTM_PL_TT moves, which causes trouble on some
paths as nouveau's move_notify() hook requires that the dma addresses be
valid at this point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau makes the assumption that if a TTM is bound there will be a mm_node
around for it and the backwards ordering here resulted in a use-after-free
on some eviction paths.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ttm_tt_destroy kfrees passed object, so we need to nullify
a reference to it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The commit "Not all systems expose a firmware or platform mechanism for
changing the backlight intensity on i915, so add native driver support"
adds calls to intel_panel_setup_backlight() from intel_{lvds,dp}_init
so do not call it again from intel_setup_outputs().
BugLink: http://bugs.launchpad.net/bugs/831542
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
ACKed-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise these would need to be painstakingly calculated looking at the source
code.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alpha needs to have available the system bus address for the Radeon's
local memory, so that it can be used in ttm_bo_vm_fault(), when building
the PTEs for accessing that VRAM. So, we make bus.addr hold the ioremap()
return, and then we can modify bus.base appropriately for use during page
fault processing.
Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel:
drm/i915: set GFX_MODE to pre-Ivybridge default value even on Ivybridge
Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that
MI_FLUSH would flush the TLBs in addition to the rest of the caches
indicated in the MI_FLUSH command. However starting with Ivybridge, the
register defaults to 0x2800 out of reset, meaning that to invalidate the
TLB we need to use PIPE_CONTROL. Since we're not doing that yet, go
back to the old default so things work.
v2: don't forget to actually *clear* the new bit
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: Cannot set clock gating under UMS
drm/i915: Can't do accurate vblank timestamps with UMS
Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support.
drm/i915: split out PCH refclk update code
drm/i915: show interrupt info on IVB
drm/i915: Remove unused 'reg' argument to dp_pipe_enabled
drm/i915: Fix PCH port pipe select in CPT disable paths
drm/i915: Leave LVDS registers unlocked
drm/i915: Wait for LVDS panel power sequence
The clock gating functions are only assigned under KMS, so don't try
to call them under UMS.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Disable this feature when KMS is not running by setting the
driver->get_vblank_timestamp function pointer to NULL.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com>
Tested-by: Michel Alexandre Salim <salimma@fedoraproject.org>
Tested-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Attempting to try and turn off disconnected display hw in the
hotput handler lead to more problems than it helped. For
now just register an event and only attempt the do something
interesting with DP. Other connectors are just too problematic:
- Some systems have an HPD pin assigned to LVDS, but it's rarely
if ever connected properly and we don't really care about hpd
events on LVDS anyway since it's always connected.
- The HPD pin is wired up correctly for eDP, but we don't really
have to do anything since the events since it's always connected.
- Some HPD pins fire more than once when you connect/disconnect
- etc.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39882
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
At least some Apples program the GPU into a state that wedges the engine
once userspace starts trying to perform accelerated operations. Executing
the Atom init scripts gets the hardware back into a working state. The
same hardware works fine when booted via BIOS emulation, so let's just
execute the init scripts on Apples when we're using EFI.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have two sources of information about panel capabilities on mobile
radeon - the BIOS, which gives us a native mode, and the panel's preferred
mode. In theory these two will always match, but there's some corner cases
where the BIOS hasn't been fully initialised and so the native mode in it
ends up with default values. However, if we get a panel with reasonable
EDID, it's probably the case that the panel's preferred mode does actually
represent the panel capabilities. This patch handles that case by replacing
the native mode with the panel's preferred mode if the resolutions don't
match. Systems without a valid internal panel EDID will still use the BIOS
native mode.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to add support for 4 crtcs when setting the possible crtcs
for the encoders.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we get a hotplug event on an connector that is off, don't
attempt to turn it on or off, it should already be off.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=728228
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
We ought to be calling this from our DPMS routines as well as global
state may change and we need to enable/disable clocks. So split out the
code in preparation for further changes.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
IVB uses the same interrupt reg layout as SNB, so add an IS_GEN7 to the
interrupt debugfs file.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Just an extra parameter which isn't actually needed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
CPT pipe select is different from previous generations (using two bits
instead of one). All of the paths from intel_disable_pch_ports were
not making this distinction.
Mode setting with pipe A turned off would then also force all outputs
on pipe B to get turned off as the disable code would mistakenly
decide that all of these outputs were on pipe A and turn them off.
This is an extension of the CPT DP disable fix (why didn't I fix this then?)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
During mode setting, check to make sure the panel power sequencing has
completed before doing further operations on the device. This
uncovered errors with DPMS not turning the device off as it was left locked.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
for a DVI connector that is not implemented/existent on the board.
Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC Lines
Tested for kernel 2.6.38 on Asus ECS A740GM-M board
BugLink: http://bugs.launchpad.net/bugs/810926
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Log PCI subsystem vendor and subsystem device ID in addition to
PCI vendor and device ID during kernel mode initialisation. This helps
to better identify radeon devices of third-party vendors, e. g. for
bug analysis.
Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some integrated ATI Radeon chipset implementations with add-on HDMI card
(e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even
when the add-on card is not plugged in or HDMI is disabled in BIOS setup.
In this case, drm_get_edid() and drm_edid_block_valid() periodically
dump data and kernel errors into system log files and onto terminals.
For these connectors DDC probing is extended by a check for a correct
EDID header. Only in case a valid EDID header is also found, the
(HDMI or DVI) connector will be used by the Radeon driver. This prevents
the kernel driver from useless flooding of logs and terminal sessions with
EDID dumps and error messages.
This patch adds a flag 'requires_extended_probe' to the radeon_connector
structure. In function radeon_connector_needs_extended_probe() this flag
can be set on a chipset family/vendor/connector type specific basis.
In addition, function radeon_ddc_probe() has been adapted to perform
extended DDC probing if required by the connector's flag.
Requires function drm_edid_header_is_valid() in DRM module provided by
[PATCH] drm: Separate EDID Header Check from EDID Block Check.
Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196
BugLink: http://bugs.launchpad.net/bugs/7228066
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Provides function drm_edid_header_is_valid() for EDID header check
and replaces EDID header check part of function drm_edid_block_valid()
by a call of drm_edid_header_is_valid().
This is a prerequisite to extend DDC probing, e. g. in function
radeon_ddc_probe() for Radeon devices, by a central EDID header check.
Tested for kernel 2.6.35, 2.6.38 and 3.0
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The struct drm_driver has some function pointers for irq. They are
gpu specific and some functions aren't essential things. This can
prevents creation of unnecessary dummy function for irq.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The registered irq should be unregistered by free_irq() if
irq_postinstall() returns the error after request_irq() is called
successfully.
[airlied: add vga switcheroo disable]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reg header files are generated so they are not cleaned automagically.
They need to be added to the clean-files list.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-next' of ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: (42 commits)
drm/i915: allow cache sharing policy control
drm/i915/hdmi: HDMI source product description infoframe support
drm/i915/hdmi: split infoframe setting from infoframe type code
drm: track CEA version number if present
drm/i915: Try enabling RC6 by default (again)
Revert "drm/i915/dp: Zero the DPCD data before connection probe"
drm/i915/dp: wait for previous AUX channel activity to clear
drm/i915: don't use uninitialized EDID bpc values when picking pipe bpp
drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend
drm/i915: apply phase pointer override on SNB+ too
drm/i915: Add quirk to disable SSC on Sony Vaio Y2
drm/i915: provide more error output when mode sets fail
drm/i915: add GPU max frequency control file
i915: add Dell OptiPlex FX170 to intel_no_lvds
drm/i915: Ignore GPU wedged errors while pinning scanout buffers
drm/i915/hdmi: send AVI info frames on ILK+ as well
drm/i915: fix CB tuning check for ILK+
drm/i915: Flush other plane register writes
drm/i915: flush plane control changes on ILK+ as well
drm/i915: apply timing generator bug workaround on CPT and PPT
...
The board has an lm63 compatible thermal chip, but no
thermal chip entry in the vbios tables.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39513
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This off by one range check was copy and pasted a couple places.
It's not really harmful, but we should fix it anyway.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Compute cs support was actually added in 2.11.0 rather than
2.10.0, but the patch was written prior. Update comment
to match.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Expose the SNB+ cache sharing policy register in debugfs. The new file,
i915_cache_sharing, has 4 values, 0-3, with 0 being "max uncore
resources" and 3 being the minimum. Exposing this control should make
benchmarking easier and help us choose a good default.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This makes it easier to add support for other infoframes (e.g. SPD,
vendor specific).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Drivers need to know the CEA version number in addition to other display
info (like whether the display is an HDMI sink) before enabling certain
features. So track the CEA version number in the display info
structure.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Jesse Barnes and I found a couple of issues where incorrect mode
setting would cause problems with RC6 enabled. We're hopeful that
fixing those will resolve the outstanding issues with a few machines
that had trouble before 3.0 with rc6.
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Francesco Allertsen <fallertsen@gmail.com>
Cc: Ted Phelps <phelps@gnusto.com>
Cc: Gu Rui <chaos.proton@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38332
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 97cdd71010.
Clearing the dpcd data means that if the fetch fails, any previous
data will be lost. On eDP, this is no fun as we only fetch dpcd at
init time, so the memset will destroy that the next time through.
