* [git pull] drm merge for 3.9-rc1
@ 2013-02-26 0:05 Dave Airlie
2013-02-26 1:22 ` Linus Torvalds
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Dave Airlie @ 2013-02-26 0:05 UTC (permalink / raw)
To: torvalds; +Cc: DRI mailing list, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 64500 bytes --]
Hi Linus,
This is the main drm pull for the 3.9-rc1 merge, and my chance to have my
email published verbatim as an article by the worst news site ever.
So up front, this has a massive merge conflict in
drivers/gpu/drm/radeon/evergreen_cs.c I've fixed it up in drm-next-merged
in the same tree, I fixed up some small ordering issues in my merge as
well, however they aren't important if you want the fun of doing a major
conflict resolution.
Highlights:
TI LCD controller KMS driver
TI OMAP KMS driver merged from staging
drop gma500 stub driver
the fbcon locking fixes
the vgacon dirty like zebra fix.
open firmware videomode and hdmi common code helpers
major locking rework for kms object handling - pageflip/cursor won't block on polling anymore!
fbcon helper and prime helper cleanups
i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT
code,
radeon: CS ioctl unification, deprecated UMS support, gpu reset rework, VM fixes
nouveau: reworked thermal code, external dp/tmds encoder support (anx9805), fences sleep instead of polling,
exynos: all over the driver fixes.
Dave.
The following changes since commit 1589a3e7777631ff56dd58cd7dcdf275185e62b5:
Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2013-02-06 08:36:12 +1100)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux.git drm-next
for you to fetch changes up to 28ee46184fc64591e286fa0355845e09c39e2a84:
Merge branch 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux into drm-next (2013-02-24 12:39:42 +1000)
----------------------------------------------------------------
Aaron Plattner (3):
drm: add prime helpers
drm/nouveau: use prime helpers
drm/radeon: use prime helpers
Ajay Kumar (1):
drm/exynos: Add device tree based discovery support for G2D
Alan Cox (1):
fb: rework locking to fix lock ordering on takeover
Alex Deucher (29):
drm/radeon: add additional reset flags
drm/radeon: add a bios scratch asic hung helper
drm/radeon: rework GPU reset on r6xx/r7xx
drm/radeon: rework GPU reset on evergreen
drm/radeon: rework GPU reset on cayman/TN
drm/radeon: rework GPU reset on cayman/TN
drm/radeon: use status regs to determine what to reset (6xx/7xx)
drm/radeon: use status regs to determine what to reset (evergreen)
drm/radeon: use status regs to determine what to reset (cayman)
drm/radeon: use status regs to determine what to reset (si)
drm/radeon: halt engines before disabling MC (6xx/7xx)
drm/radeon: halt engines before disabling MC (evergreen)
drm/radeon: halt engines before disabling MC (cayman/TN)
drm/radeon: halt engines before disabling MC (si)
drm/radeon: use the reset mask to determine if rings are hung
drm/radeon: don't reset the MC on IGPs/APUs
drm/radeon: use IBs for VM page table updates v2
drm/radeon: switch back to using the DMA ring for VM PT updates
drm/radeon: add Oland chip family
drm/radeon: fill in gpu init for Oland
drm/radeon: add ucode loading support for Oland
drm/radeon: radeon-asic updates for Oland
drm/radeon: add Oland pci ids
drm/radeon/dce6: fix display powergating
drm/radeon: fix multi-head power profile stability on BTC+ asics
drm/radeon: remove overzealous warning in hdmi handling
drm/radeon: add a asic callback to get the xclk
drm/radeon: switch get_gpu_clock() to a callback (v2)
drm/radeon: properly validate the atpx interface
Andy Gross (2):
drm/omap: Add PM capabilities
drm/omap: Add OMAP5 support
Ben Hutchings (1):
nouveau: ACPI support depends on X86 and X86_PLATFORM_DEVICES
Ben Skeggs (55):
nvd0/therm: implement more appropriate pwm fan control functions
drm/nouveau/therm: fix various style issues, make more consistent
drm/nouveau/therm: collect fan tach info in common fan constructor
drm/nva3/therm: add support for hardware fan tachometer
drm/nvd0/therm: add support for hardware fan tachometer
drm/nouveau/therm: add interfaces to allow forcing off pwm fan control
drm/nouveau/therm: cleanly separate pwm control logic from therm
drm/nvc0/bus: report useful data on mmio fault
drm/nouveau/therm: better transitions and debug logging
drm/nouveau/hwmon: s/fan0/fan1/
drm/nouveau/hwmon: create hwmon attributes under hwmon device in sysfs
drm/nouveau: remove legacy vbios type detection
drm/nouveau: remove some more unnecessary legacy bios code
drm/nouveau/bios: add support for parsing xpio table data
drm/nouveau/bios: rename DCB_GPIO_PWM_FAN to DCB_GPIO_FAN
drm/nouveau/therm: don't try pwm/toggle control if GPIO_FAN is input
drm/nv50/disp: fix missing sor modectrl sync flags
drm/nouveau/fifo/nvc0: improve interrupt handler somewhat
drm/nouveau/core: basic event interface between core and drm
drm/nouveau/disp/nv04: implement a base display object class
drm/nouveau/disp: port vblank handling to event interface
drm/nouveau/fifo/nvc0-: use interrupt 31 as an event trigger
drm/nouveau/fifo/nv84: support user event trigger
drm/nouveau/fifo/nvc0: bash some magic reg to make uevent interrupt work
drm/nouveau/fence/nv84-: put processes to sleep while waiting on fences
drm/nouveau/drm: store full dcb gpio function data in connector
drm/nouveau/gpio: pass number of on-die gpio lines to base
drm/nouveau/gpio: use event interfaces for interrupt signalling
drm/nouveau/gpio/nve0: interrupt regs moved on kepler apparently
drm/nv84/fence: access fences with full virtual address, not offset
drm/nv84-/fence: abstract class emit/sync functions to virt+sequence
drm/nv17/fence: split from nv10 code
drm/nouveau/fence: make internal hooks part of the context
drm/nv84-/fence: prepare for emit/sync support of sysram sequences
drm/nv50/graph: avoid touching 400724, it doesn't exist
drm/nouveau/i2c: handle i2c/aux mux outside of port lookup function
drm/nouveau: store i2c port pointer directly in nouveau_encoder
drm/nouveau/bios: parse external transmitter type if off-chip
drm/nouveau/i2c: fix a bit of a thinko in nv_wri2cr helper functions
drm/nouveau/i2c: aux channels not necessarily on nvio
drm/nouveau/i2c: extend type to 16-bits, add lookup-by-type function
drm/nouveau/bios: store a type/mask hash in parsed dcb data
drm/nv50/devinit: reverse the logic for running encoder init scripts
drm/nv50-/disp: 0x0000 is a valid udisp config value
drm/nouveau/i2c: create proper chipset-specific class implementations
drm/nv50-/disp: handle supervisor tasks from workqueue
drm/nv50-/disp: move DP link training to core and train from supervisor
drm/nv50-/kms: remove unnecessary wait-for-completion points
drm/nv50-/disp: initial work towards supporting external encoders
drm/nv50-/disp: initial supervisor support for off-chip encoders
drm/nv50: initial kms support for off-chip TMDS/DP encoders
drm/nouveau/i2c: add support for ddc/aux, and dp link training on anx9805
drm/nv50/disp: handle multiple actions from one set of supervisor intrs
drm/nvd0/disp: handle multiple actions from one set of supervisor intrs
drm/nv50-/kms: remove UPDATE methods after each encoder disconnect
Ben Widawsky (28):
drm/i915: BUG() if fences are used on unsupported platform
drm/i915: Bug on unsupported swizzled platforms
drm/i915: Missed conversion to gtt_pte_t
drm/i915: Move even more gtt code to i915_gem_gtt
drm/i915: Move GSM mapping into dev_priv
drm/i915: Make GSM void
drm/i915: Kill gtt_end
drm/i915: Mappable_end can't ever be > end
drm/i915: Remove gtt_mappable_total
drm/i915: Create a gtt structure
drm/i915: Remove use on gma_bus_addr on gen6+
drm/i915: Remove use of gtt_mappable_entries
drm/i915: Cut out the infamous ILK w/a from AGP layer
drm/i915: Remove scratch page from shared
drm/i915: Needs_dmar, not
agp/intel: Add gma_bus_addr
drm/i915: Implement WaVSRefCountFullforceMissDisable
drm/i915: Error state should print /sys/kernel/debug
drm/i915: Add probe and remove to the gtt ops
drm/i915: remove intel_gtt structure
drm/i915: Reclaim GTT space for failed PPGTT
drm/i915: Fix CAGF for HSW
drm/i915: Fix RC6VIDS encode/decode
drm/i915: Clarify HW context size logic
drm/i915: Fix gen2 mappable calculations
drm/i915: Extract ring init from hw_init
drm/i915/ctx: Remove bad invariant
drm/i915: Print the hw context status is debugfs
Bjorn Helgaas (4):
drm/pci: Use the standard #defines for PCIe Link Capability bits
drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices
drm/pci: Use PCI Express Capability accessors
drm/pci: define drm_pcie_get_speed_cap_mask() only when CONFIG_PCI=y
Borislav Petkov (1):
x86/intel/cacheinfo: Shut up annoying warning
Carsten Emde (1):
drm: Load EDID: Explain better how to write your own EDID firmware
Changlong Xie (1):
drm/i915: gen6_gmch_remove can be static
Chris Metcalf (1):
drm: fix compile failure by including <linux/swiotlb.h>
Chris Wilson (32):
drm/i915/debugfs: Prune a couple of superfluous leading zeros from bo domains
drm: Introduce drm_mm_create_block()
drm: Introduce an iterator over holes in the drm_mm range manager
drm/i915: Fix detection of base of stolen memory
drm/i915: Avoid clearing preallocated regions from the GTT
drm/i915: Delay allocation of stolen space for FBC
drm/i915: Allow objects to be created with no backing pages, but stolen space
drm/i915: Support readback of stolen objects upon error
drm/i915: Introduce i915_gem_object_create_stolen()
drm/i915: Allocate fbcon from stolen memory
drm/i915: Allocate ringbuffers from stolen memory
drm/i915: Allocate overlay registers from stolen memory
drm/i915: Use a slab for object allocation
drm/i915: Tighten the checks for invalid relocation domains
drm/i915: Remove check for conflicting relocation write-domains
drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages
drm/i915: Open-code i915_gpu_idle() for handling seqno wrapping
drm/i915: Access to snooped system memory through the GTT is incoherent
drm/i915: Clear the stolen fb before enabling
drm/i915: Return the real error code from intel_set_mode()
drm/i915: Add a debug interface to forcibly evict and shrink our object caches
drm/i915: Bail if we attempt to allocate pages for a purged object
drm/i915: Mark a temporary allocation for copy-from-user as such
drm/i915: Take the handle idr spinlock once for looking up the exec objects
drm/i915: Move the execbuffer objects list from the stack into the tracker
drm/i915: Use the reloc.handle as an index into the execbuffer array
drm/i915: Only insert the mb() before updating the fence parameter
drm/i915: Only apply the mb() when flushing the GTT domain during a finish
drm/i915: Only run idle processing from i915_gem_retire_requests_worker
drm/udl: Inline memcmp() for RLE compression of xfer
drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
drm/i915: Handle untiled planes when computing their offsets
Christian König (1):
drm/radeon: Deprecate UMS support v2
Cong Ding (2):
staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage
drm/nouveau: remove unnecessary null pointer check from nouveau_fence_new
Damien Lespiau (10):
drm/i915: Fix dieing -> dying typo
drm/i915: Cleanup SHOTPLUG_CTL status bits definitions
drm/i915/hdmi: Read the HPD status before trying to read the EDID
drm/i915/dp: Read the HPD status before trying to read the DPCD
drm/i915/dp: Log the DPCD only if we have successfully retrieved one
drm/i915: Implement ibx_digital_port_connected() for IBX
drm/i915: Remove stale comment about intel_dp_detect()
drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment
drm/i915: Preserve the FDI line reversal override bit on CPT
drm/i915: Preserve the DDI link reversal configuration
Dan Carpenter (1):
drm/nouveau/disp: sizeof() wrong pointer
Daniel Kurtz (1):
drm: make frame duration time calculation more precise
Daniel Vetter (121):
drm/i915: remove duplicate register #defines
drm/i915: add encoder->pre_pll_enable callback
drm/i915: replace ad-hoc dual-link lvds checks
drm/i915: move is_dual_link_lvds to intel_lvds.c
drm/i915: track is_dual_link in intel_lvds
drm/i915: add intel_lvds->reg
drm/i915: move intel_update_lvds to intel_lvds->pre_pll_enable
drm/i915: enable intel_lvds->pre_pll_enable for ilk+, too
drm/i915: simplify shmem pwrite/pread slowpath handling
drm/i915: optimize the shmem_pwrite slowpath handling
drm/i915: optimize ilk/snb irq handler
drm/i915: fixup sparse warnings
drm/i915: haswell has the same irq handlers as ivb
drm/i915: don't handle PIPE_LEGACY_BLC_EVENT_STATUS on vlv
drm/i915: setup the hangcheck timer early
drm/i915: reorder setup sequence to have irqs for output setup
drm/i915: extract gmbus_wait_hw_status
drm/i915: wire up gmbus irq handler
drm/i915: use the gmbus irq for waits
drm/i915: use gmbus irq to wait for gmbus idle
drm/i915: wire up do aux channel done interrupt
drm/i915: irq-drive the dp aux communication
drm/i915: use _NOTRACE for gmbus/dp aux wait loops
drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set
drm/i915: move set_pll_edp to intel_dp.c
drm/i915: rip out pre-production ilk cpu edp w/a
drm/i915: use wait_for_vblank instead of msleep(17)
drm/i915: WARN on !crtc in intel_dp_link_down
drm/i915: drop unnecessary clearing of pch dp transcoder timings
drm/i915: extract common link_m_n helpers
drm/i915: Fixup hpd irq register setup ordering
drm/i915: rework locking for intel_dpio|sbi_read|write
drm/i915: clean up PIPECONF bpc #defines
drm/i915: fixup overlay stolen memory leak
drm/i915: wake up all pageflip waiters
drm/i915: Allow userspace to hint that the relocations were known
drm/i915: move dev_priv->mm out of line
drm/i915: extract hangcheck/reset/error_state state into substruct
drm/i915: move wedged to the other gpu error handling stuff
drm/i915: fix reset handling in the throttle ioctl
drm/i915: clear up wedged transitions
drm: review locking rules in drm_crtc.c
drm/doc: integrate drm_crtc.c kerneldoc
drm/<drivers>: reorder framebuffer init sequence
drm/vmwgfx: reorder framebuffer init sequence
drm/gma500: move fbcon restore to lastclose
drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex
drm/nouveau: try to protect nbo->pin_refcount
drm/<drivers>: Unified handling of unimplemented fb->create_handle
drm: encapsulate crtc->set_config calls
drm: add drm_modeset_lock|unlock_all
drm/i915: use drm_modeset_lock_all
drm/gma500: use drm_modeset_lock_all
drm/ast: use drm_modeset_lock_all
drm/shmobile: use drm_modeset_lock_all
drm/vmwgfx: use drm_modeset_lock_all
omapdrm: use modeset_lock_all
drm: add per-crtc locks
drm: only take the crtc lock for ->cursor_set
drm: only take the crtc lock for ->cursor_move
drm: revamp locking around fb creation/destruction
drm: create drm_framebuffer_lookup
drm: revamp framebuffer cleanup interfaces
drm: reference framebuffers which are on the idr
drm: nest modeset locks within fpriv->fbs_lock
drm: push modeset_lock_all into ->fb_create driver callbacks
drm: don't take modeset locks in getfb ioctl
drm: fb refcounting for dirtyfb_ioctl
drm: refcounting for sprite framebuffers
drm: refcounting for crtc framebuffers
drm/i915: dump refcount into framebuffer debugfs file
drm/vmwgfx: add proper framebuffer refcounting
drm: optimize drm_framebuffer_remove
drm: only grab the crtc lock for pageflips
drm: don't hold crtc mutexes for connector ->detect callbacks
drm/doc: updates for new framebuffer lifetime rules
drm/fb_helper: check whether fbcon is bound
drm/i915: create a race-free reset detection
drm/i915: clarify concurrent hang detect/gpu reset consistency
drm/i915: fixup sbi_read/write locking
drm/i915: fixup per-crtc locking in intel_release_load_detect_pipe
drm/i915: move modeset checks out of save/restore_modeset_reg
drm/i915: extract ums suspend/resume into i915_ums.c
drm/i915: dont save/restore VGA state for kms
drm/i915: move DP save/restore into i915_ums.c
drm/i915: vfuncs for gtt_clear_range/insert_entries
drm/i915: vfuncs for ppgtt
drm/i915: pte_encode is gen6+
drm/i915: extract hw ppgtt setup/cleanup code
drm/i915: kill cargo-culted locking from power well code
drm/i915: don't run hsw power well code on !hsw
drm/i915: dynamic Haswell display power well support
Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"
drm: review locking for drm_fb_helper_restore_fbdev_mode
drm/fb-helper: kill drm_fb_helper_restore
drm/fb-helper: unexport drm_fb_helper_panic
drm/fb-helper: unexport drm_fb_helper_single_fb_probe
drm/tegra: don't set up initial fbcon config twice
drm/fb-helper: don't disable everything in initial_config
drm/i915: rip out helper->disable noop functions
drm/fb-helper: fixup set_config semantics
drm/fb-helper: directly call set_par from the hotplug handler
drm/fb-helper: streamline drm_fb_helper_single_fb_probe
drm/<drivers>: simplify ->fb_probe callback
drm/fb-helper: improve kerneldoc
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress
drm/fb-helper: remove unused members of struct drm_fb_helper
drm/i915: write backlight harder
drm/i915: unify HDMI/DP hpd definitions
omapdrm: only take crtc->mutex in crtc callbacks
omapdrm: simplify locking in the fb debugfs file
drm/cma-helper: fixup compilation
drm: Don't set the plane->fb to NULL on successfull set_plane
drm/cma-helper: fixup compilation
drm: Don't set the plane->fb to NULL on successfull set_plane
drm/i915: detect wrong MCH watermark values
drm/i915: remove bogus mutex_unlock from error-path
drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
drm/i915: inverted brightness quirk for Acer Aspire 4736Z
intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
drm/i915: Revert hdmi HDP pin checks
Dave Airlie (27):
Merge tag 'drm-intel-next-2012-12-21' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Merge branch 'drm-kms-locking' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
vgacon/vt: clear buffer attributes when we load a 512 character font (v2)
fbcon: don't lose the console font across generic->chip driver switch
drm/usb: bind driver to correct device
drm/udl: make usage as a console safer
Merge tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
drm/udl: disable fb_defio by default
fbcon: fix locking harder
Revert "Revert "console: implement lockdep support for console_lock""
Merge branch 'fbcon-locking-fixes' of ssh://people.freedesktop.org/~airlied/linux into drm-next
Merge branch 'console-fixes' into drm-next
Merge branch 'udl-fixes' into drm-next
Merge tag 'of_videomode_helper' of git://git.pengutronix.de/git/str/linux into drm-next
Merge branch 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next
Merge branch 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux into drm-next
Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next
Merge branch 'omapdrm-next' of git://people.freedesktop.org/~robclark/linux into drm-next
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
Merge branch 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next
Merge branch 'tilcdc-next' of git://people.freedesktop.org/~robclark/linux into drm-next
Merge branch 'exynos-drm-next' of git://git.kernel.org/.../daeinki/drm-exynos into drm-next
Merge branch 'drm/tegra-for-3.9' of git://anongit.freedesktop.org/tegra/linux into drm-next
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Merge branch 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux into drm-next
Dexuan Cui (1):
drm/i915: Remove duplicate and unused register #defines in i915_reg.h
Egbert Eich (1):
drm/i915: Remove pch_rq_mask from struct drm_i915_private.
Emil Velikov (1):
drm/nouveau: set legacy bios data before parsing the structure
H. Peter Anvin (1):
x86, doc: Boot protocol 2.12 is in 3.8
Ilija Hadzic (12):
drm/radeon: remove unecessary assignment
drm/radeon: remove unused prototype from radeon_cs
drm/radeon: fix formatting
drm/radeon: implement common cs packet parse function
drm/radeon: use common cs packet parse function
drm/radeon: factor out cs_next_is_pkt3_nop function
drm/radeon: refactor vline packet parsing function
drm/radeon: add a check to wait_reg_mem command
drm/radeon: rename r100_cs_dump_packet to radeon_cs_dump_packet
drm/radeon: pull out common next_reloc function
drm/radeon: use common next_reloc function
drm/radeon: consolidate redundant macros and constants
Imre Deak (4):
drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment()
drm/i915: merge {i965, sandybridge}_write_fence_reg()
drm/i915: use gtt_get_size() instead of open coding it
drm/i915: don't clflush gem objects in stolen memory
Inki Dae (2):
drm/exynos: fix iommu address allocation order
drm/exynos: consider exception case to fb handle creation
Jan Beulich (1):
x86-64: Replace left over sti/cli in ia32 audit exit code
Jani Nikula (4):
drm/i915: add quirk to invert brightness on eMachines G725
drm/i915: add quirk to invert brightness on eMachines e725
drm/i915: add quirk to invert brightness on Packard Bell NCL20
drm/i915: add missing \n to UTS_RELEASE in the error_state
Jerome Glisse (1):
radeon/kms: cleanup async dma packet checking
Lee, Chun-Yi (1):
gpu: remove gma500 stub driver
Luis R. Rodriguez (1):
i915: convert struct spinlock to spinlock_t
Maarten Lankhorst (9):
drm/vmwgfx: always use ttm_bo_is_reserved
drm/nouveau: increase reservation sequence every retry
drm/ttm: remove lru_lock around ttm_bo_reserve
drm/ttm: cleanup ttm_eu_reserve_buffers handling
drm/ttm: add ttm_bo_reserve_slowpath
drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2
drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2
drm/ttm: unexport ttm_bo_wait_unreserved
drm: shut up invalid edid messages
Marcin Slusarz (20):
drm/nouveau: split fifo interrupt handler
drm/nouveau: use pr_cont
drm/nouveau: prepare for reporting channel owner
drm/nouveau: report channel owner in error messages
drm/nouveau: share fence structures between nv10+ and nv50 implementations
drm/nouveau: mark nv_printk_ as printf-like function
drm/nouveau/bios: tiny debugging messages fixes
drm/nouveau: quiet static-related sparse noise
drm/nouveau/fan: fix selection of fan speed when fan->get returns an error
drm/nvc0/graph: remove redundant null checks
drm/nouveau: use drm_property_create_range helper
drm/nouveau: use kmemdup for edid allocation/copying
drm/nouveau: handle backlight_device_register failure
drm/nouveau/therm: always initialize alarm_program_lock
drm/nouveau: report channel owner in ioctl error paths
drm/nouveau/therm: turn on fan only when threshold hit in positive direction
drm/nv40/therm: reset temperature sensor on init
drm/nouveau/therm: use workqueue to shutdown the machine
drm/nouveau/therm: reduce stack usage of nouveau_therm_ic_ctor
drm/nouveau: restore debugfs/vbios.rom support
Martin Peres (11):
drm/nouveau/fan: add toggle fan support
drm/nouveau/bios: parse fan bump/slow periods, and trip points
drm/nouveau/fan: obey fan bump/slow periods as defined by vbios
drm/nouveau/therm: implement automatic fan management
drm/nouveau/pbus: add a PBUS subdev that hands IRQs to the right subdevs
drm/nv41/bus: report useful data on mmio fault
drm/nouveau/therm: implement support for temperature alarms
drm/nouveau/hwmon: add missing alarm thresholds
drm/nouveau/doc: document the sysfs thermal management interface
drm/nouveau/therm: force a minimum hysteresis on temperature alarm thresholds
drm/nouveau/fan: handle the cases where we are outside of the linear zone
Mika Kuoppala (14):
drm/i915: Add debugfs entry to read/write next_seqno
drm/i915: Fix debugfs seqno info print to use uint
drm/i915: Split intel_ring_begin
drm/i915: Add intel_ring_handle_seqno wrap
drm/i915: Don't emit semaphore wait if wrap happened
drm/i915: Set initial seqno value close to wrap boundary
drm/i915: Introduce ring set_seqno
drm/i915: Initialize hardware semaphore state on ring init
drm/i915: Always clear semaphore mboxes on seqno wrap
drm/i915: Introduce i915_gem_set_seqno()
drm/i915: Make next_seqno debugs entry to use i915_gem_set_seqno
drm/i915: use gem_set_seqno() on hardware init
drm/i915: disable shared panel fitter for pipe
drm/i915: clean up panel fitter handling in lvds
Patrik Jakobsson (3):
drm/i915: Set i9xx lvds clock limits according to specifications
drm/i915: Set i9xx sdvo clock limits according to specifications
gma500: Fix n, m1 and m2 clock limits for sdvo and lvds
Paulo Zanoni (18):
drm/i915: intel_prepare_ddi_buffers should be static
drm/i915: remove Haswell code from ironlake_fdi_pll_enable
drm/i915: add HAS_DDI check
drm/i915: invert the log inside intel_prepare_ddi
drm/i915: kill intel_dp_link_clock()
drm/i915: be less verbose when handling gmbus/aux irqs
drm/i915: check for the PCH when setting pch_transcoder
drm/i915: remove leftover display.update_wm assignment
drm/i915: add intel_dp_set_signal_levels
drm/i915: don't save/restore DSPARB on gen5+
drm/i915: fix intel_init_power_wells
drm/i915: only disable enabled planes on intel_fb_restore_mode
drm/i915: set TRANSCODER_EDP even earlier
drm/i915: turn on the power well before suspending
drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A
drm/i915: check the power down well on assert_pipe()
drm/i915: add ibx_irq_postinstall
drm: don't add inferred modes for monitors that don't support them
Peter Huewe (1):
staging/omapdrm: Use kmemdup rather than duplicating its implementation
Rahul Sharma (3):
drm/exynos: add display-mode-check operation to exynos_mixer_ops struct
drm/exynos: implement display-mode-check callback in mixer driver
drm/exynos: mixer: set correct mode for range of resolutions
Rob Clark (11):
drm/i2c: give i2c it's own Kconfig
drm/omap: move out of staging
drm/omap: remove fbdev debug enter/leave hooks
drm: small fix in drm_send_vblank_event()
drm/cma: add debugfs helpers
drm: i2c encoder helper wrappers
drm/nouveau: use i2c encoder helper wrappers
drm/tilcdc: add TI LCD Controller DRM driver (v4)
drm/i2c: nxp-tda998x (v3)
drm/tilcdc: add encoder slave (v2)
drm/tilcdc: add support for LCD panels (v5)
Sachin Kamat (2):
drm/i915: Remove duplicate inclusion of drm/drm_edid.h
drm/exynos: Add missing braces around sizeof
Sean Paul (1):
drm/exynos: hdmi: support extra resolutions using drm_display_mode timings
Stefan de Konink (1):
drm/nouveau: Fix DPMS 1 on G4 Snowball, from snow white to coal black.
Steffen Trumtrar (7):
viafb: rename display_timing to via_display_timing
video: add display_timing and videomode
video: add of helper for display timings/videomode
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
Takashi Iwai (1):
fb: Yet another band-aid for fixing lockdep mess
Thierry Reding (18):
drm: Allow vblank support without DRIVER_HAVE_IRQ
drm: Remove duplicate drm_mode_cea_vic()
drm: Move mode tables to drm_edid.c
drm: Add some missing forward declarations
video: Add generic HDMI infoframe helpers
drm: Add HDMI infoframe helpers
drm: Add EDID helper documentation
drm/tegra: Use generic HDMI infoframe helpers
drm/radeon: Use generic HDMI infoframe helpers
drm: Add consistency check for page-flipping
drm/tegra: Remove bogus tegra_framebuffer structure
drm/tegra: Add plane support
drm/tegra: Implement .mode_set_base()
drm/tegra: Implement VBLANK support
drm/tegra: Implement page-flipping support
drm/tegra: Split DC_CMD_STATE_CONTROL register write
drm/tegra: Fix color expansion
drm/tegra: Add list of framebuffers to debugfs
Tim Gardner (2):
i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers
drm/radeon: Avoid NULL pointer dereference from atom_index_iio() allocation failure
Tomas Janousek (1):
drm/i915: don't prevent CPU idle states
Ville Syrjälä (46):
drm/i915: Kill i915_gem_execbuffer_wait_for_flips()
drm/i915: Fix SPRITE0_FLIP_DONE_INT_EN_VLV and SPRITE0_FLIPDONE_INT_STATUS_VLV
drm/i915: Fix RGB color range property for PCH platforms
drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
drm/edid: Add drm_rgb_quant_range_selectable()
drm/i915: Provide the quantization range in the AVI infoframe
drm/i915: Convert intel_hdmi to enum port
drm/i915: Convert intel_dp to enum port
drm/i915: Add display_display_mmio_offset to intel_device_info
drm/i915: AUD_VID_DID needs an offset on VLV
drm/i915: Per-pipe PP registers are for VLV only
drm/i915: VLV_VIDEO_DIP_CTL is for VLV only
drm/i915: PIPE M/N registers need an offset on VLV
drm/i915: Primary plane registers need an offset on VLV
drm/i915: Pipe registers need an offset on VLV
drm/i915: Cursor registers need an offset on VLV
drm/i915: VLV_DDL is VLV only and needs an offset
drm/i915: DSPFW registers need an offset on VLV
drm/i915: DPFLIPSTAT and DPINVGTT registers are VLV only and need an offset
drm/i915: Panel fitter registers need an offset on VLV
drm/i915: PORT_HOTPLUG registers need an offset on VLV
drm/i915: Pipe timing registers need an offset on VLV
drm/i915: Pipe palette registers need an offset on VLV
drm/i915: FB_BLC_SELF_VLV is VLV only and needs an offset
drm/i915: Make VLV_GUNIT_CLOCK_GATE register value more readable
drm/i915: Spell out VLV_DISPLAY_BASE for interrupt registers
drm/i915: DPIO registers are VLV only and need an offset
drm/i915: GPIO/GMBUS registers need an offset on VLV
drm/i915: Set display_mmio_offset for VLV
drm/i915: PLL registers need an offset on VLV
drm/i915: Always use adpa_reg
drm/i915: VLV doesn't have SDVO
drm/i915: Pass VLV_DISPLAY_BASE + reg to intel_{hdmi, dp}_init on VLV
drm/i915: Include display_mmio_offset in sequencer index/data registers
drm/i915: SWF screatch registers need an offset on VLV
drm/i915: Introduce i915_vgacntrl_reg()
drm/i915: Kill IS_DISPLAYREG()
drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too
drm/i915: Fix sprite_scaling_enabled for multiple sprites
drm/i915: Print the pipe control page GTT address
drm/i915: Kill obj->pending_flip
drm/i915: Don't wait for page flips if there was GPU reset
drm: Fill depth/bits_per_pixel for C8 format
drm: Use C8 instead of RGB332 when determining the format from depth/bpp
drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+
drm/i915: Implement pipe CSC based limited range RGB output
Wang Xingchao (1):
drm/i915: HDMI/DP - ELD info refresh support for Haswell
Yasuaki Ishimatsu (1):
GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c
YoungJun Cho (2):
drm/exynos: fix wrong pointer access at vm close.
drm/exynos: release resources properly when fb creation is failed.
Zhang Rui (1):
i915: ignore lid open event when resuming
Documentation/DocBook/drm.tmpl | 78 +-
Documentation/EDID/HOWTO.txt | 27 +-
.../devicetree/bindings/drm/tilcdc/panel.txt | 59 +
.../devicetree/bindings/drm/tilcdc/slave.txt | 18 +
.../devicetree/bindings/drm/tilcdc/tfp410.txt | 21 +
.../devicetree/bindings/drm/tilcdc/tilcdc.txt | 21 +
.../devicetree/bindings/video/display-timing.txt | 109 ++
Documentation/thermal/nouveau_thermal | 81 ++
drivers/char/agp/intel-gtt.c | 128 ++-
drivers/gpu/Makefile | 2 +-
drivers/gpu/drm/Kconfig | 8 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/ast/ast_drv.c | 4 +-
drivers/gpu/drm/ast/ast_drv.h | 2 +
drivers/gpu/drm/ast/ast_fb.c | 27 +-
drivers/gpu/drm/ast/ast_main.c | 12 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 27 +-
drivers/gpu/drm/cirrus/cirrus_main.c | 12 +-
drivers/gpu/drm/drm_crtc.c | 816 ++++++++------
drivers/gpu/drm/drm_edid.c | 843 +++++++++++++-
drivers/gpu/drm/drm_edid_modes.h | 774 -------------
drivers/gpu/drm/drm_encoder_slave.c | 63 ++
drivers/gpu/drm/drm_fb_cma_helper.c | 95 +-
drivers/gpu/drm/drm_fb_helper.c | 310 ++++--
drivers/gpu/drm/drm_fops.c | 1 +
drivers/gpu/drm/drm_gem_cma_helper.c | 21 +
drivers/gpu/drm/drm_irq.c | 12 +-
drivers/gpu/drm/drm_mm.c | 96 +-
drivers/gpu/drm/drm_modes.c | 70 ++
drivers/gpu/drm/drm_pci.c | 81 +-
drivers/gpu/drm/drm_prime.c | 186 +++-
drivers/gpu/drm/drm_usb.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fb.c | 55 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 39 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 33 +-
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12 +
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 1035 +++++++-----------
drivers/gpu/drm/exynos/exynos_mixer.c | 34 +-
drivers/gpu/drm/gma500/framebuffer.c | 43 +-
drivers/gpu/drm/gma500/psb_device.c | 8 +-
drivers/gpu/drm/gma500/psb_drv.c | 14 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 12 +-
drivers/gpu/drm/i2c/Kconfig | 28 +
drivers/gpu/drm/i2c/Makefile | 3 +
drivers/gpu/drm/i2c/ch7006_drv.c | 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 906 +++++++++++++++
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_debugfs.c | 254 ++++-
drivers/gpu/drm/i915/i915_dma.c | 94 +-
drivers/gpu/drm/i915/i915_drv.c | 131 +--
drivers/gpu/drm/i915/i915_drv.h | 475 +++++---
drivers/gpu/drm/i915/i915_gem.c | 516 ++++-----
drivers/gpu/drm/i915/i915_gem_context.c | 12 +-
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 5 +-
drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 333 +++---
drivers/gpu/drm/i915/i915_gem_gtt.c | 645 ++++++-----
drivers/gpu/drm/i915/i915_gem_stolen.c | 305 ++++--
drivers/gpu/drm/i915/i915_gem_tiling.c | 33 +-
drivers/gpu/drm/i915/i915_irq.c | 370 ++++---
drivers/gpu/drm/i915/i915_reg.h | 436 ++++----
drivers/gpu/drm/i915/i915_suspend.c | 540 +--------
drivers/gpu/drm/i915/i915_ums.c | 503 +++++++++
drivers/gpu/drm/i915/intel_crt.c | 46 +-
drivers/gpu/drm/i915/intel_ddi.c | 79 +-
drivers/gpu/drm/i915/intel_display.c | 975 +++++++----------
drivers/gpu/drm/i915/intel_dp.c | 374 ++++---
drivers/gpu/drm/i915/intel_drv.h | 41 +-
drivers/gpu/drm/i915/intel_dvo.c | 1 -
drivers/gpu/drm/i915/intel_fb.c | 55 +-
drivers/gpu/drm/i915/intel_hdmi.c | 108 +-
drivers/gpu/drm/i915/intel_i2c.c | 103 +-
drivers/gpu/drm/i915/intel_lvds.c | 250 ++++-
drivers/gpu/drm/i915/intel_modes.c | 6 +-
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 24 +-
drivers/gpu/drm/i915/intel_panel.c | 13 +-
drivers/gpu/drm/i915/intel_pm.c | 95 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 113 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 11 +-
drivers/gpu/drm/i915/intel_sdvo.c | 67 +-
drivers/gpu/drm/i915/intel_sprite.c | 46 +-
drivers/gpu/drm/i915/intel_tv.c | 4 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 28 +-
drivers/gpu/drm/mgag200/mgag200_main.c | 16 +-
drivers/gpu/drm/nouveau/Kconfig | 28 +-
drivers/gpu/drm/nouveau/Makefile | 29 +-
drivers/gpu/drm/nouveau/core/core/client.c | 10 +
drivers/gpu/drm/nouveau/core/core/enum.c | 11 +-
drivers/gpu/drm/nouveau/core/core/event.c | 106 ++
drivers/gpu/drm/nouveau/core/engine/copy/nva3.c | 6 +-
drivers/gpu/drm/nouveau/core/engine/crypt/nv84.c | 8 +-
drivers/gpu/drm/nouveau/core/engine/crypt/nv98.c | 6 +-
drivers/gpu/drm/nouveau/core/engine/disp/base.c | 52 +
drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 346 ++++++
drivers/gpu/drm/nouveau/core/engine/disp/dport.h | 78 ++
drivers/gpu/drm/nouveau/core/engine/disp/nv04.c | 33 +-
drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 371 ++++---
drivers/gpu/drm/nouveau/core/engine/disp/nv50.h | 37 +-
drivers/gpu/drm/nouveau/core/engine/disp/nv84.c | 12 +-
drivers/gpu/drm/nouveau/core/engine/disp/nv94.c | 24 +-
drivers/gpu/drm/nouveau/core/engine/disp/nva0.c | 9 +-
drivers/gpu/drm/nouveau/core/engine/disp/nva3.c | 24 +-
drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c | 309 +++---
drivers/gpu/drm/nouveau/core/engine/disp/nve0.c | 17 +-
.../gpu/drm/nouveau/core/engine/disp/piornv50.c | 140 +++
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c | 25 -
drivers/gpu/drm/nouveau/core/engine/disp/sornv94.c | 153 +--
drivers/gpu/drm/nouveau/core/engine/disp/sornvd0.c | 90 +-
drivers/gpu/drm/nouveau/core/engine/fifo/base.c | 21 +
drivers/gpu/drm/nouveau/core/engine/fifo/nv04.c | 187 ++--
drivers/gpu/drm/nouveau/core/engine/fifo/nv50.c | 5 +-
drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c | 22 +-
drivers/gpu/drm/nouveau/core/engine/fifo/nvc0.c | 109 +-
drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 64 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv04.c | 16 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv10.c | 16 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv20.c | 15 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv40.c | 16 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 53 +-
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 33 +-
drivers/gpu/drm/nouveau/core/engine/graph/nve0.c | 44 +-
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 7 +-
.../gpu/drm/nouveau/core/engine/software/nv50.c | 40 +-
.../gpu/drm/nouveau/core/engine/software/nvc0.c | 29 +-
drivers/gpu/drm/nouveau/core/include/core/class.h | 44 +-
drivers/gpu/drm/nouveau/core/include/core/client.h | 3 +-
drivers/gpu/drm/nouveau/core/include/core/device.h | 1 +
drivers/gpu/drm/nouveau/core/include/core/enum.h | 3 +-
drivers/gpu/drm/nouveau/core/include/core/event.h | 36 +
drivers/gpu/drm/nouveau/core/include/core/object.h | 12 +-
drivers/gpu/drm/nouveau/core/include/core/printk.h | 3 +-
drivers/gpu/drm/nouveau/core/include/engine/disp.h | 27 +-
drivers/gpu/drm/nouveau/core/include/engine/fifo.h | 4 +
.../gpu/drm/nouveau/core/include/engine/software.h | 4 +-
.../gpu/drm/nouveau/core/include/subdev/bios/dcb.h | 3 +
.../drm/nouveau/core/include/subdev/bios/gpio.h | 11 +-
.../gpu/drm/nouveau/core/include/subdev/bios/i2c.h | 2 +-
.../drm/nouveau/core/include/subdev/bios/therm.h | 16 +
.../drm/nouveau/core/include/subdev/bios/xpio.h | 19 +
drivers/gpu/drm/nouveau/core/include/subdev/bus.h | 41 +
drivers/gpu/drm/nouveau/core/include/subdev/gpio.h | 39 +-
drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 127 ++-
.../gpu/drm/nouveau/core/include/subdev/therm.h | 37 +-
.../gpu/drm/nouveau/core/include/subdev/timer.h | 8 +
drivers/gpu/drm/nouveau/core/os.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c | 32 +-
drivers/gpu/drm/nouveau/core/subdev/bios/extdev.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/bios/gpio.c | 11 +-
drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c | 15 +-
drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 15 +-
drivers/gpu/drm/nouveau/core/subdev/bios/therm.c | 28 +-
drivers/gpu/drm/nouveau/core/subdev/bios/xpio.c | 76 ++
drivers/gpu/drm/nouveau/core/subdev/bus/nv04.c | 95 ++
drivers/gpu/drm/nouveau/core/subdev/bus/nv31.c | 112 ++
drivers/gpu/drm/nouveau/core/subdev/bus/nv50.c | 105 ++
drivers/gpu/drm/nouveau/core/subdev/bus/nvc0.c | 101 ++
drivers/gpu/drm/nouveau/core/subdev/device/base.c | 5 +-
drivers/gpu/drm/nouveau/core/subdev/device/nv04.c | 7 +-
drivers/gpu/drm/nouveau/core/subdev/device/nv10.c | 25 +-
drivers/gpu/drm/nouveau/core/subdev/device/nv20.c | 13 +-
drivers/gpu/drm/nouveau/core/subdev/device/nv30.c | 16 +-
drivers/gpu/drm/nouveau/core/subdev/device/nv40.c | 50 +-
drivers/gpu/drm/nouveau/core/subdev/device/nv50.c | 51 +-
drivers/gpu/drm/nouveau/core/subdev/device/nvc0.c | 43 +-
drivers/gpu/drm/nouveau/core/subdev/device/nve0.c | 22 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv50.c | 14 +-
drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c | 64 +-
drivers/gpu/drm/nouveau/core/subdev/gpio/base.c | 140 +--
drivers/gpu/drm/nouveau/core/subdev/gpio/nv10.c | 40 +-
drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c | 45 +-
drivers/gpu/drm/nouveau/core/subdev/gpio/nvd0.c | 14 +-
drivers/gpu/drm/nouveau/core/subdev/gpio/nve0.c | 131 +++
drivers/gpu/drm/nouveau/core/subdev/gpio/priv.h | 17 +
drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 279 +++++
drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c | 154 +--
drivers/gpu/drm/nouveau/core/subdev/i2c/base.c | 481 ++++----
drivers/gpu/drm/nouveau/core/subdev/i2c/bit.c | 18 +-
drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c | 143 +++
drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c | 135 +++
drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c | 149 +++
drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.h | 32 +
drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c | 285 +++++
drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c | 124 +++
drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/nv98.c | 2 +
drivers/gpu/drm/nouveau/core/subdev/mc/nvc0.c | 2 +
drivers/gpu/drm/nouveau/core/subdev/mxm/mxms.c | 8 +-
drivers/gpu/drm/nouveau/core/subdev/therm/base.c | 218 +++-
drivers/gpu/drm/nouveau/core/subdev/therm/fan.c | 244 +++--
drivers/gpu/drm/nouveau/core/subdev/therm/fannil.c | 54 +
drivers/gpu/drm/nouveau/core/subdev/therm/fanpwm.c | 107 ++
drivers/gpu/drm/nouveau/core/subdev/therm/fantog.c | 115 ++
drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 54 +-
drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c | 82 +-
drivers/gpu/drm/nouveau/core/subdev/therm/nv50.c | 199 +++-
drivers/gpu/drm/nouveau/core/subdev/therm/nva3.c | 99 ++
drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c | 153 +++
drivers/gpu/drm/nouveau/core/subdev/therm/priv.h | 103 +-
drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 162 +++
drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 +
drivers/gpu/drm/nouveau/nouveau_bios.c | 130 +--
drivers/gpu/drm/nouveau/nouveau_bios.h | 12 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +-
drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 5 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 96 +-
drivers/gpu/drm/nouveau/nouveau_connector.h | 10 +-
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 64 ++
drivers/gpu/drm/nouveau/nouveau_debugfs.h | 22 +
drivers/gpu/drm/nouveau/nouveau_display.c | 95 +-
drivers/gpu/drm/nouveau/nouveau_display.h | 3 -
drivers/gpu/drm/nouveau/nouveau_dma.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_dp.c | 297 +----
drivers/gpu/drm/nouveau/nouveau_drm.c | 60 +-
drivers/gpu/drm/nouveau/nouveau_drm.h | 2 +
drivers/gpu/drm/nouveau/nouveau_encoder.h | 9 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 26 +-
drivers/gpu/drm/nouveau/nouveau_fence.c | 103 +-
drivers/gpu/drm/nouveau/nouveau_fence.h | 42 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 103 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 10 +-
drivers/gpu/drm/nouveau/nouveau_pm.c | 233 +++-
drivers/gpu/drm/nouveau/nouveau_prime.c | 173 +--
drivers/gpu/drm/nouveau/nv04_dfp.c | 4 +-
drivers/gpu/drm/nouveau/nv04_display.c | 18 +-
drivers/gpu/drm/nouveau/nv04_display.h | 1 +
drivers/gpu/drm/nouveau/nv04_fence.c | 6 +-
drivers/gpu/drm/nouveau/nv04_tv.c | 39 +-
drivers/gpu/drm/nouveau/nv10_fence.c | 118 +-
drivers/gpu/drm/nouveau/nv10_fence.h | 19 +
drivers/gpu/drm/nouveau/nv17_fence.c | 149 +++
drivers/gpu/drm/nouveau/nv17_tv.c | 2 +-
drivers/gpu/drm/nouveau/nv50_display.c | 307 +++++-
drivers/gpu/drm/nouveau/nv50_fence.c | 36 +-
drivers/gpu/drm/nouveau/nv84_fence.c | 214 +++-
drivers/gpu/drm/nouveau/nvc0_fence.c | 186 +---
drivers/{staging => gpu/drm}/omapdrm/Kconfig | 0
drivers/{staging => gpu/drm}/omapdrm/Makefile | 0
drivers/gpu/drm/omapdrm/TODO | 23 +
.../{staging => gpu/drm}/omapdrm/omap_connector.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c | 14 +-
.../{staging => gpu/drm}/omapdrm/omap_debugfs.c | 18 +-
.../{staging => gpu/drm}/omapdrm/omap_dmm_priv.h | 5 +
.../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c | 159 ++-
.../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h | 0
drivers/{staging => gpu/drm}/omapdrm/omap_drv.c | 20 +-
drivers/{staging => gpu/drm}/omapdrm/omap_drv.h | 8 +-
.../{staging => gpu/drm}/omapdrm/omap_encoder.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_fb.c | 18 +-
drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c | 34 +-
drivers/{staging => gpu/drm}/omapdrm/omap_gem.c | 34 +-
.../{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c | 8 +-
.../drm}/omapdrm/omap_gem_helpers.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_irq.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_plane.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c | 0
drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h | 0
drivers/{staging => gpu/drm}/omapdrm/tcm.h | 2 +
drivers/gpu/drm/radeon/Kconfig | 33 +-
drivers/gpu/drm/radeon/Makefile | 10 +-
drivers/gpu/drm/radeon/atom.c | 9 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 6 +-
drivers/gpu/drm/radeon/evergreen.c | 366 +++++--
drivers/gpu/drm/radeon/evergreen_cs.c | 1149 ++++++++------------
drivers/gpu/drm/radeon/evergreen_hdmi.c | 85 +-
drivers/gpu/drm/radeon/evergreen_reg.h | 1 +
drivers/gpu/drm/radeon/evergreend.h | 54 +-
drivers/gpu/drm/radeon/ni.c | 339 ++++--
drivers/gpu/drm/radeon/nid.h | 27 +-
drivers/gpu/drm/radeon/r100.c | 224 +---
drivers/gpu/drm/radeon/r100_track.h | 4 -
drivers/gpu/drm/radeon/r100d.h | 11 -
drivers/gpu/drm/radeon/r200.c | 26 +-
drivers/gpu/drm/radeon/r300.c | 42 +-
drivers/gpu/drm/radeon/r300_cmdbuf.c | 2 +
drivers/gpu/drm/radeon/r300d.h | 11 -
drivers/gpu/drm/radeon/r500_reg.h | 1 +
drivers/gpu/drm/radeon/r600.c | 401 ++++---
drivers/gpu/drm/radeon/r600_blit.c | 33 +-
drivers/gpu/drm/radeon/r600_blit_kms.c | 31 +
drivers/gpu/drm/radeon/r600_cp.c | 2 +
drivers/gpu/drm/radeon/r600_cs.c | 332 ++----
drivers/gpu/drm/radeon/r600_hdmi.c | 135 +--
drivers/gpu/drm/radeon/r600d.h | 17 +-
drivers/gpu/drm/radeon/radeon.h | 38 +-
drivers/gpu/drm/radeon/radeon_asic.c | 70 +-
drivers/gpu/drm/radeon/radeon_asic.h | 24 +-
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 73 +-
drivers/gpu/drm/radeon/radeon_cp.c | 2 +
drivers/gpu/drm/radeon/radeon_cs.c | 176 ++-
drivers/gpu/drm/radeon/radeon_cursor.c | 8 +-
drivers/gpu/drm/radeon/radeon_device.c | 10 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 91 +-
drivers/gpu/drm/radeon/radeon_drv.h | 16 +-
drivers/gpu/drm/radeon/radeon_family.h | 1 +
drivers/gpu/drm/radeon/radeon_fb.c | 27 +-
drivers/gpu/drm/radeon/radeon_gart.c | 60 +-
drivers/gpu/drm/radeon/radeon_irq.c | 2 +
drivers/gpu/drm/radeon/radeon_kms.c | 11 +-
drivers/gpu/drm/radeon/radeon_mem.c | 2 +
drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
drivers/gpu/drm/radeon/radeon_prime.c | 170 +--
drivers/gpu/drm/radeon/radeon_reg.h | 15 +
drivers/gpu/drm/radeon/radeon_ring.c | 19 +
drivers/gpu/drm/radeon/radeon_state.c | 2 +
drivers/gpu/drm/radeon/radeon_ttm.c | 1 +
drivers/gpu/drm/radeon/rv515d.h | 11 -
drivers/gpu/drm/radeon/rv770.c | 25 +
drivers/gpu/drm/radeon/rv770d.h | 4 +
drivers/gpu/drm/radeon/si.c | 509 ++++++---
drivers/gpu/drm/radeon/sid.h | 30 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +-
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/dc.c | 585 ++++++++--
drivers/gpu/drm/tegra/dc.h | 14 +-
drivers/gpu/drm/tegra/drm.c | 103 ++
drivers/gpu/drm/tegra/drm.h | 43 +-
drivers/gpu/drm/tegra/fb.c | 4 -
drivers/gpu/drm/tegra/hdmi.c | 226 ++--
drivers/gpu/drm/tegra/hdmi.h | 189 ----
drivers/gpu/drm/tilcdc/Kconfig | 13 +
drivers/gpu/drm/tilcdc/Makefile | 10 +
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 602 ++++++++++
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 611 +++++++++++
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 150 +++
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 436 ++++++++
drivers/gpu/drm/tilcdc/tilcdc_panel.h | 26 +
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 154 +++
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 376 +++++++
drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 +
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 419 +++++++
drivers/gpu/drm/tilcdc/tilcdc_tfp410.h | 26 +
drivers/gpu/drm/ttm/ttm_bo.c | 103 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 78 +-
drivers/gpu/drm/udl/udl_drv.h | 2 +
drivers/gpu/drm/udl/udl_fb.c | 78 +-
drivers/gpu/drm/udl/udl_transfer.c | 46 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 38 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 87 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +-
drivers/gpu/stub/Kconfig | 18 -
drivers/gpu/stub/Makefile | 1 -
drivers/gpu/stub/poulsbo.c | 64 --
drivers/gpu/vga/vga_switcheroo.c | 3 +
drivers/iommu/intel-iommu.c | 8 +-
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/omapdrm/TODO | 32 -
drivers/tty/vt/vt.c | 136 ++-
drivers/video/Kconfig | 26 +-
drivers/video/Makefile | 5 +
drivers/video/console/fbcon.c | 58 +-
drivers/video/console/vgacon.c | 22 +-
drivers/video/display_timing.c | 24 +
drivers/video/fbmem.c | 11 +-
drivers/video/fbmon.c | 94 ++
drivers/video/fbsysfs.c | 3 +
drivers/video/hdmi.c | 308 ++++++
drivers/video/of_display_timing.c | 239 ++++
drivers/video/of_videomode.c | 54 +
drivers/video/via/hw.c | 6 +-
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 2 +-
drivers/video/via/share.h | 2 +-
drivers/video/via/via_modesetting.c | 8 +-
drivers/video/via/via_modesetting.h | 6 +-
drivers/video/videomode.c | 39 +
include/drm/drmP.h | 34 +
include/drm/drm_crtc.h | 38 +-
include/drm/drm_edid.h | 6 +
include/drm/drm_encoder_slave.h | 20 +
include/drm/drm_fb_cma_helper.h | 5 +
include/drm/drm_fb_helper.h | 18 +-
include/drm/drm_gem_cma_helper.h | 4 +
include/drm/drm_mm.h | 40 +
include/drm/drm_pciids.h | 13 +
include/drm/intel-gtt.h | 22 +-
include/drm/ttm/ttm_bo_driver.h | 61 +-
include/linux/console.h | 2 +
include/linux/fb.h | 8 +
include/linux/hdmi.h | 231 ++++
include/linux/vt_kern.h | 3 +
include/uapi/drm/i915_drm.h | 20 +
.../omapdrm => include/uapi/drm}/omap_drm.h | 2 +-
include/video/display_timing.h | 124 +++
include/video/of_display_timing.h | 20 +
include/video/of_videomode.h | 18 +
include/video/videomode.h | 48 +
kernel/printk.c | 9 +
399 files changed, 23655 insertions(+), 11557 deletions(-)
create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt
create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
create mode 100644 Documentation/thermal/nouveau_thermal
delete mode 100644 drivers/gpu/drm/drm_edid_modes.h
create mode 100644 drivers/gpu/drm/i2c/Kconfig
create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
create mode 100644 drivers/gpu/drm/i915/i915_ums.c
create mode 100644 drivers/gpu/drm/nouveau/core/core/event.c
create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/base.c
create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/dport.c
create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/dport.h
create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/piornv50.c
create mode 100644 drivers/gpu/drm/nouveau/core/include/core/event.h
create mode 100644 drivers/gpu/drm/nouveau/core/include/subdev/bios/xpio.h
create mode 100644 drivers/gpu/drm/nouveau/core/include/subdev/bus.h
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bios/xpio.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nv04.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nv31.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nv50.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nvc0.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/gpio/nve0.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/gpio/priv.h
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.h
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/fannil.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/fanpwm.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/fantog.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/nva3.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_debugfs.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_debugfs.h
create mode 100644 drivers/gpu/drm/nouveau/nv10_fence.h
create mode 100644 drivers/gpu/drm/nouveau/nv17_fence.c
rename drivers/{staging => gpu/drm}/omapdrm/Kconfig (100%)
rename drivers/{staging => gpu/drm}/omapdrm/Makefile (100%)
create mode 100644 drivers/gpu/drm/omapdrm/TODO
rename drivers/{staging => gpu/drm}/omapdrm/omap_connector.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_debugfs.c (90%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_priv.h (96%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c (86%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h (100%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.c (97%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.h (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_encoder.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_fb.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c (95%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem.c (97%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_helpers.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_irq.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_plane.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c (100%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h (100%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm.h (99%)
create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
create mode 100644 drivers/gpu/drm/tilcdc/Makefile
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
delete mode 100644 drivers/gpu/stub/Kconfig
delete mode 100644 drivers/gpu/stub/Makefile
delete mode 100644 drivers/gpu/stub/poulsbo.c
delete mode 100644 drivers/staging/omapdrm/TODO
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/hdmi.c
create mode 100644 drivers/video/of_display_timing.c
create mode 100644 drivers/video/of_videomode.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/linux/hdmi.h
rename {drivers/staging/omapdrm => include/uapi/drm}/omap_drm.h (99%)
create mode 100644 include/video/display_timing.h
create mode 100644 include/video/of_display_timing.h
create mode 100644 include/video/of_videomode.h
create mode 100644 include/video/videomode.h
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-26 0:05 [git pull] drm merge for 3.9-rc1 Dave Airlie
@ 2013-02-26 1:22 ` Linus Torvalds
2013-02-26 1:59 ` Dave Airlie
2013-02-27 1:39 ` Linus Torvalds
2013-02-27 16:34 ` Josh Boyer
2 siblings, 1 reply; 26+ messages in thread
From: Linus Torvalds @ 2013-02-26 1:22 UTC (permalink / raw)
To: Dave Airlie; +Cc: DRI mailing list, Linux Kernel Mailing List
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> So up front, this has a massive merge conflict in
> drivers/gpu/drm/radeon/evergreen_cs.c I've fixed it up in drm-next-merged
> in the same tree, I fixed up some small ordering issues in my merge as
> well, however they aren't important if you want the fun of doing a major
> conflict resolution.
I did the fun conflict resolution, so my tree doesn't have the ordering changes.
I also did some things slightly differently from you - you had left
some direct ib[] accesses that I spotted (see for example "case 0x48"
(aka "Copy L2T Frame to Field"), and yours apparently has a few cases
where you use "idx_value" instead of my mindless conflict resolution
that just re-did the brute-force "repace direct ib[] read accesses
with the radeon_get_ib_value() helper function". But you don't do it
for *all* the radeon_get_ib_value(p, idx+2) users, so whatever.
Anyway - my conflict resolution isn't exactly the same as yours, and
maybe I screwed something up. But it's damn close, and the differences
_seem_ be all be benign.
Btw, why is it ok that some functions still read the ib[] array
directly (eg evergreen_vm_packet3_check() or evergreen_cs_check_reg()
etc)?
Whatever. I prefer doing my own resolutions just so that I know what's
going on, and it all seems to build and looks reasonable, but it's
always good to get a second opinion. Particularly since I can't
actually test the radeon stuff, so just eyeballing it and saying
"looks semantically identical to Dave's resolution" may not be 100%
sufficient..
Linus
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-26 1:22 ` Linus Torvalds
@ 2013-02-26 1:59 ` Dave Airlie
0 siblings, 0 replies; 26+ messages in thread
From: Dave Airlie @ 2013-02-26 1:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Airlie, DRI mailing list, Linux Kernel Mailing List
>
> I did the fun conflict resolution, so my tree doesn't have the ordering changes.
>
> I also did some things slightly differently from you - you had left
> some direct ib[] accesses that I spotted (see for example "case 0x48"
> (aka "Copy L2T Frame to Field"), and yours apparently has a few cases
> where you use "idx_value" instead of my mindless conflict resolution
> that just re-did the brute-force "repace direct ib[] read accesses
> with the radeon_get_ib_value() helper function". But you don't do it
> for *all* the radeon_get_ib_value(p, idx+2) users, so whatever.
Yeah the rules for radeon_get_ib_value are that they are meant to be sequential,
but it actually doesn't matter as long as the values are within a page
of each other,
I was just avoiding multiple calls to get the same value with the idx_value, but
I think Alex or Jerome can clean this up a bit further anyways.
> Anyway - my conflict resolution isn't exactly the same as yours, and
> maybe I screwed something up. But it's damn close, and the differences
> _seem_ be all be benign.
>
> Btw, why is it ok that some functions still read the ib[] array
> directly (eg evergreen_vm_packet3_check() or evergreen_cs_check_reg()
> etc)?
The semantics for that function are a bit underdocumented, and I thought
the other developers understood them after I explained them, but I found
out that they hadn't quite grasped the true extent of pain. So yes there
are other places that need to be cleaned up, but most of the time direct
ib access will work fine, until you have a buffer that straddles a
page boundary.
> Whatever. I prefer doing my own resolutions just so that I know what's
> going on, and it all seems to build and looks reasonable, but it's
> always good to get a second opinion. Particularly since I can't
> actually test the radeon stuff, so just eyeballing it and saying
> "looks semantically identical to Dave's resolution" may not be 100%
> sufficient..
Yup I've reviewed it and it looks fine, any cleanup is just going to be
an optimisation.
So I'll work with Alex/Jerome to clean up anything else out-of-band
and hopefully
we can avoid any big conflicts in future!
Dave.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-26 0:05 [git pull] drm merge for 3.9-rc1 Dave Airlie
2013-02-26 1:22 ` Linus Torvalds
@ 2013-02-27 1:39 ` Linus Torvalds
2013-02-27 2:25 ` Linus Torvalds
` (4 more replies)
2013-02-27 16:34 ` Josh Boyer
2 siblings, 5 replies; 26+ messages in thread
From: Linus Torvalds @ 2013-02-27 1:39 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter, Imre Deak
Cc: DRI mailing list, Linux Kernel Mailing List
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> Highlights:
>
> i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT
> code,
Lowlight:
There's something wrong with i915 DP detection or whatever. I get
stuff like this:
[ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
signal timeout (has irq: 1)!
[ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
signal timeout (has irq: 1)!
[ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
signal timeout (has irq: 1)!
[ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
signal timeout (has irq: 1)!
[ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
signal timeout (has irq: 1)!
[ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
0xa145003f
.....
[ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
0xa145003f
and after that the screen ends up black.
It's happened twice now, but is not 100% repeatable. It looks like the
message itself is new, but the black screen is also new and does seem
to happen when I get the message, so...
The second time I touched the power button, and the machine came back.
Apparently the suspend/resume cycle made it all magically work: the
suspend caused the same errors, but then the resume made it all good
again.
Some kind of missed initialization at bootup? It's not reliable enough
to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915:
irq-drive the dp aux communication") since that is where the message
was added..
Btw, looking at that commit, what do you think the semantics of the
timeout in something like
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
would be? What's that magic "10"? It's some totally random number.
Guys, it should be something meaningful. If you meant a tenth of a
second, use HZ/10 or something. Because just the plain "10" is crazy.
I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a
hundreth of a second. Was that what you intended? Because if it was,
it is still crap, since CONFIG_HZ might be 100, and then you're
waiting for ten times longer.
IOW, passing in a random number like that is crazy. It cannot possibly
be right.
I have no idea whether the timeout has anything to do with anything,
but it reinforces my suspicion that there is something wrong with that
commit.
Linus
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 1:39 ` Linus Torvalds
@ 2013-02-27 2:25 ` Linus Torvalds
2013-02-27 3:30 ` Dave Airlie
` (3 subsequent siblings)
4 siblings, 0 replies; 26+ messages in thread
From: Linus Torvalds @ 2013-02-27 2:25 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter, Imre Deak
Cc: DRI mailing list, Linux Kernel Mailing List
On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Lowlight:
>
> [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
Oh, forgot to mention - this is my trusty old Westmere chip (aka "Core
i5-670", aka Clarkdale, aka GMA-some-random-number). The one before
SB.
Linus
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 1:39 ` Linus Torvalds
2013-02-27 2:25 ` Linus Torvalds
@ 2013-02-27 3:30 ` Dave Airlie
2013-02-27 3:38 ` Linus Torvalds
2013-02-27 10:04 ` Chris Wilson
` (2 subsequent siblings)
4 siblings, 1 reply; 26+ messages in thread
From: Dave Airlie @ 2013-02-27 3:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Daniel Vetter, Imre Deak, Linux Kernel Mailing List,
DRI mailing list
[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]
On Wed, Feb 27, 2013 at 11:39 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>
>> Highlights:
>>
>> i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT
>> code,
>
> Lowlight:
>
> There's something wrong with i915 DP detection or whatever. I get
> stuff like this:
>
> [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
> .....
> [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
>
> and after that the screen ends up black.
>
> It's happened twice now, but is not 100% repeatable. It looks like the
> message itself is new, but the black screen is also new and does seem
> to happen when I get the message, so...
>
> The second time I touched the power button, and the machine came back.
> Apparently the suspend/resume cycle made it all magically work: the
> suspend caused the same errors, but then the resume made it all good
> again.
>
> Some kind of missed initialization at bootup? It's not reliable enough
> to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915:
> irq-drive the dp aux communication") since that is where the message
> was added..
>
> Btw, looking at that commit, what do you think the semantics of the
> timeout in something like
>
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
>
> would be? What's that magic "10"? It's some totally random number.
>
> Guys, it should be something meaningful. If you meant a tenth of a
> second, use HZ/10 or something. Because just the plain "10" is crazy.
> I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a
> hundreth of a second. Was that what you intended? Because if it was,
> it is still crap, since CONFIG_HZ might be 100, and then you're
> waiting for ten times longer.
Yeah the looks bogus, Daniel and Imre fail, though I think Daniel is
on holiday this week,
so maybe if you can make it revert, that might be the best option,
If you want to just bump it so Ironlake isn't affected, (patch attached).
Is this external DP monitor or eDP laptop panel btw?
Dave.
[-- Attachment #2: 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch --]
[-- Type: application/octet-stream, Size: 999 bytes --]
From 5d68af13f663833c7d3394ca4ecd597f4d8aba1c Mon Sep 17 00:00:00 2001
From: Dave Airlie <airlied@gmail.com>
Date: Wed, 27 Feb 2013 13:28:21 +1000
Subject: [PATCH] drm/i915: only use irq for dp on post-ilk
Linus reports his ILK is broken.
Signed-off-by: Dave Airlie <airlied@redhat.com>
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 31c0205..012553f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -379,7 +379,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
uint32_t status;
uint32_t aux_clock_divider;
int try, precharge;
- bool has_aux_irq = INTEL_INFO(dev)->gen >= 5 && !IS_VALLEYVIEW(dev);
+ bool has_aux_irq = INTEL_INFO(dev)->gen >= 6 && !IS_VALLEYVIEW(dev);
/* dp aux is extremely sensitive to irq latency, hence request the
* lowest possible wakeup latency and so prevent the cpu from going into
--
1.8.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 3:30 ` Dave Airlie
@ 2013-02-27 3:38 ` Linus Torvalds
0 siblings, 0 replies; 26+ messages in thread
From: Linus Torvalds @ 2013-02-27 3:38 UTC (permalink / raw)
To: Dave Airlie
Cc: Dave Airlie, Daniel Vetter, Imre Deak, Linux Kernel Mailing List,
DRI mailing list
On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie <airlied@gmail.com> wrote:
>
> If you want to just bump it so Ironlake isn't affected, (patch attached).
It works fine 95% of the time and isn't a hard failure when it
doesn't, so this isn't critical. I can wait for it to be fixed a
while.
> Is this external DP monitor or eDP laptop panel btw?
External monitor. Oh, and the monitor is actually connected to HDMI,
but the black screen and the DP messages definitely go hand-in-hand.
Linus
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 1:39 ` Linus Torvalds
2013-02-27 2:25 ` Linus Torvalds
2013-02-27 3:30 ` Dave Airlie
@ 2013-02-27 10:04 ` Chris Wilson
2013-03-03 15:39 ` Azat Khuzhin
2013-03-05 19:18 ` Daniel Vetter
4 siblings, 0 replies; 26+ messages in thread
From: Chris Wilson @ 2013-02-27 10:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Daniel Vetter, Imre Deak, Linux Kernel Mailing List,
DRI mailing list
On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote:
> >
> > Highlights:
> >
> > i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT
> > code,
>
> Lowlight:
>
> There's something wrong with i915 DP detection or whatever. I get
> stuff like this:
>
> [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
>
> and after that the screen ends up black.
>
> It's happened twice now, but is not 100% repeatable. It looks like the
> message itself is new, but the black screen is also new and does seem
> to happen when I get the message, so...
That message appears to be the canary. For whatever reason the DP
transfer is not functioning, likely the VDD is not powered up. However,
the failure to communicate there causes the modeset to abort, resulting
in the blank screen.
> The second time I touched the power button, and the machine came back.
> Apparently the suspend/resume cycle made it all magically work: the
> suspend caused the same errors, but then the resume made it all good
> again.
So it is reproducible during suspend. That should help narrow down the
sequence, thank you.
> Some kind of missed initialization at bootup? It's not reliable enough
> to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915:
> irq-drive the dp aux communication") since that is where the message
> was added..
>
> Btw, looking at that commit, what do you think the semantics of the
> timeout in something like
>
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
>
> would be? What's that magic "10"? It's some totally random number.
The hardware is required to return a timedout error message after 400
microseconds. The timeout here is to catch the dysfunction driver, and
so was intended to be 10 milliseconds, cf
https://patchwork.kernel.org/patch/2160541/
As it happens with your machine 10 jiffies is approximately 10
millisecond, and so we should not be aborting before the hardware has
had a chance to signal failure. One way to check whether it is a failure
to setup the IRQ or a failure to setup the DP comms would be:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7b8bfe8..f2486f1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -356,9 +356,11 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
else
done = wait_for_atomic(C, 10) == 0;
- if (!done)
- DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
- has_aux_irq);
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq: %i), status=%08x!\n",
+ has_aux_irq, status);
+ }
#undef C
return status;
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-26 0:05 [git pull] drm merge for 3.9-rc1 Dave Airlie
2013-02-26 1:22 ` Linus Torvalds
2013-02-27 1:39 ` Linus Torvalds
@ 2013-02-27 16:34 ` Josh Boyer
2013-02-27 20:20 ` Josh Boyer
2 siblings, 1 reply; 26+ messages in thread
From: Josh Boyer @ 2013-02-27 16:34 UTC (permalink / raw)
To: Dave Airlie, Alex Deucher, Jerome Glisse
Cc: torvalds, DRI mailing list, linux-kernel
On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
> Alex Deucher (29):
> drm/radeon: halt engines before disabling MC (6xx/7xx)
> drm/radeon: halt engines before disabling MC (evergreen)
> drm/radeon: halt engines before disabling MC (cayman/TN)
> drm/radeon: halt engines before disabling MC (si)
> drm/radeon: use the reset mask to determine if rings are hung
Something in this series of commits is causing the GPU to hang on reboot
on my Dell XPS 8300 machine. That has a:
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
ATI Caicos [Radeon HD 6450]
card in it. After reboots, I get a screen that looks like this:
http://t.co/tPnT6xQZUK
I can hit it fairly consistently after a few reboots, so I tried doing a
git bisect on the radeon driver and it came down to:
ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
commit ca57802e521de54341efc8a56f70571f79ffac72
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Wed Jan 23 18:56:08 2013 -0500
drm/radeon: halt engines before disabling MC (6xx/7xx)
It's better to halt the engines before we disable the MC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Basically what seems to be happening is drm:r600_ring_test fails the ring
0 test and disables GPU accel. Things go downhill from there, as the
driver continues to try and set hpd after the interrupts have been
disabled already. The relevant dmesg portions are below.
I think Alex has a patch to not do that and I built a kernel with that and
the splat went away, but the actual problem of the rainbow static screen
still remains.
I can send the bisect log if people are interested. I'll try reverting
that single commit and seeing if it fixes things on a known "bad" kernel.
I'd be happy to try further debugging suggestions if this doesn't make
sense.
josh
Full dmesg can be found here: http://paste.fedoraproject.org/3903/
[ 3.277618] [drm] radeon kernel modesetting enabled.
[ 3.277708] checking generic (d0000000 5b0000) vs hw (d0000000 10000000)
[ 3.277710] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
removing generic driver
[ 3.277787] Console: switching to colour dummy device 80x25
[ 3.282108] [drm] initializing kernel modesetting (CAICOS
0x1002:0x6779 0x1B0A:0x909D).
[ 3.282286] [drm] register mmio base: 0xFE620000
[ 3.282287] [drm] register mmio size: 131072
[ 3.282782] ATOM BIOS: DeLL
[ 3.282806] radeon 0000:01:00.0: GPU softreset: 0x00000400
[ 3.282808] radeon 0000:01:00.0: GRBM_STATUS = 0x00003828
[ 3.282810] radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007
[ 3.282812] radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007
[ 3.282814] radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0
[ 3.282816] radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000
[ 3.282818] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000
[ 3.282820] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000
[ 3.282822] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000
[ 3.282824] radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000
[ 3.282826] radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57
[ 3.291890] radeon 0000:01:00.0: SRBM_SOFT_RESET=0x00000800
[ 3.309450] radeon 0000:01:00.0: GRBM_STATUS = 0x00003828
[ 3.309452] radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007
[ 3.309454] radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007
[ 3.309456] radeon 0000:01:00.0: SRBM_STATUS = 0x200002C0
[ 3.309458] radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000
[ 3.309460] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000
[ 3.309462] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000
[ 3.309464] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000
[ 3.309466] radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000
[ 3.309468] radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57
[ 3.309997] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 -
0x000000003FFFFFFF (1024M used)
[ 3.310000] radeon 0000:01:00.0: GTT: 512M 0x0000000040000000 -
0x000000005FFFFFFF
[ 3.314766] [drm] Detected VRAM RAM=1024M, BAR=256M
[ 3.314770] [drm] RAM width 64bits DDR
[ 3.316172] [TTM] Zone kernel: Available graphics memory: 6131076 kiB
[ 3.316176] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 3.316179] [TTM] Initializing pool allocator
[ 3.316288] [TTM] Initializing DMA pool allocator
[ 3.316950] [drm] radeon: 1024M of VRAM memory ready
[ 3.316975] [drm] radeon: 512M of GTT memory ready.
[ 3.317367] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 3.317369] [drm] Driver supports precise vblank timestamp query.
[ 3.317529] radeon 0000:01:00.0: irq 44 for MSI/MSI-X
[ 3.317599] radeon 0000:01:00.0: radeon: using MSI.
[ 3.317882] [drm] radeon: irq initialized.
[ 3.317902] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 3.318405] [drm] probing gen 2 caps for device 8086:101 = 2/0
[ 3.318409] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[ 3.318739] [drm] Loading CAICOS Microcode
[ 3.343934] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[ 3.345316] radeon 0000:01:00.0: WB enabled
[ 3.345322] radeon 0000:01:00.0: fence driver on ring 0 use gpu
addr 0x0000000040000c00 and cpu addr 0xffff8803125a5c00
[ 3.345326] radeon 0000:01:00.0: fence driver on ring 3 use gpu
addr 0x0000000040000c0c and cpu addr 0xffff8803125a5c0c
[ 3.569822] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0xCAFEDEAD)
[ 3.569835] radeon 0000:01:00.0: disabling GPU acceleration
[ 3.576708] radeon 0000:01:00.0: ffff88031413eee8 unpin not necessary
[ 3.583089] [drm] Radeon Display Connectors
[ 3.583091] [drm] Connector 0:
[ 3.583093] [drm] HDMI-A-1
[ 3.583093] [drm] HPD2
[ 3.583095] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468
0x646c 0x646c
[ 3.583096] [drm] Encoders:
[ 3.583097] [drm] DFP1: INTERNAL_UNIPHY1
[ 3.583098] [drm] Connector 1:
[ 3.583098] [drm] DVI-D-1
[ 3.583099] [drm] HPD4
[ 3.583101] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458
0x645c 0x645c
[ 3.583101] [drm] Encoders:
[ 3.583102] [drm] DFP2: INTERNAL_UNIPHY
[ 3.583103] [drm] Connector 2:
[ 3.583104] [drm] VGA-1
[ 3.583105] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438
0x643c 0x643c
[ 3.583106] [drm] Encoders:
[ 3.583107] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 3.583257] ------------[ cut here ]------------
[ 3.583275] WARNING: at drivers/gpu/drm/radeon/evergreen.c:2659
evergreen_irq_set+0xaaa/0xac0 [radeon]()
[ 3.583276] Hardware name: XPS 8300
[ 3.583277] Can't enable IRQ/MSI because no handler is installed
[ 3.583278] Modules linked in: radeon(+) usb_storage i2c_algo_bit
drm_kms_helper ttm drm i2c_core
[ 3.583284] Pid: 197, comm: systemd-udevd Not tainted 3.8.0-rc3+ #23
[ 3.583285] Call Trace:
[ 3.583290] [<ffffffff8106a7bf>] warn_slowpath_common+0x7f/0xc0
[ 3.583292] [<ffffffff8106a8b6>] warn_slowpath_fmt+0x46/0x50
[ 3.583303] [<ffffffffa00f86ca>] evergreen_irq_set+0xaaa/0xac0 [radeon]
[ 3.583306] [<ffffffff817179e1>] ? _raw_spin_lock_irqsave+0x91/0xb0
[ 3.583318] [<ffffffffa00c74a2>] ?
radeon_irq_kms_enable_hpd+0x32/0x90 [radeon]
[ 3.583328] [<ffffffffa00c74db>]
radeon_irq_kms_enable_hpd+0x6b/0x90 [radeon]
[ 3.583339] [<ffffffffa00f5e64>] evergreen_hpd_init+0xb4/0x150 [radeon]
[ 3.583349] [<ffffffffa00bf655>] radeon_modeset_init+0x325/0xb90 [radeon]
[ 3.583359] [<ffffffffa009b220>] radeon_driver_load_kms+0xf0/0x180 [radeon]
[ 3.583366] [<ffffffffa001ddc6>] drm_get_pci_dev+0x186/0x2d0 [drm]
[ 3.583375] [<ffffffffa00980c1>] ? radeon_pci_probe+0xa1/0xf0 [radeon]
[ 3.583383] [<ffffffffa00980d3>] radeon_pci_probe+0xb3/0xf0 [radeon]
[ 3.583386] [<ffffffff8138f87b>] local_pci_probe+0x4b/0x80
[ 3.583389] [<ffffffff8138fad1>] pci_device_probe+0x111/0x120
[ 3.583392] [<ffffffff8146fa9b>] driver_probe_device+0x8b/0x390
[ 3.583393] [<ffffffff8146fe4b>] __driver_attach+0xab/0xb0
[ 3.583395] [<ffffffff8146fda0>] ? driver_probe_device+0x390/0x390
[ 3.583398] [<ffffffff8146da25>] bus_for_each_dev+0x55/0x90
[ 3.583400] [<ffffffff8146f3fe>] driver_attach+0x1e/0x20
[ 3.583402] [<ffffffff8146f020>] bus_add_driver+0x1b0/0x2a0
[ 3.583403] [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 3.583405] [<ffffffff81470547>] driver_register+0x77/0x170
[ 3.583407] [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 3.583409] [<ffffffff8138e894>] __pci_register_driver+0x64/0x70
[ 3.583414] [<ffffffffa001e02a>] drm_pci_init+0x11a/0x130 [drm]
[ 3.583416] [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 3.583417] [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 3.583425] [<ffffffffa015b05f>] radeon_init+0x5f/0x1000 [radeon]
[ 3.583428] [<ffffffff8100215a>] do_one_initcall+0x12a/0x180
[ 3.583431] [<ffffffff810ebfd4>] load_module+0x1b74/0x2230
[ 3.583433] [<ffffffff8137cfd0>] ? ddebug_proc_open+0xd0/0xd0
[ 3.583436] [<ffffffff8136870e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3.583438] [<ffffffff810ec767>] sys_init_module+0xd7/0x120
[ 3.583441] [<ffffffff81720e99>] system_call_fastpath+0x16/0x1b
[ 3.583442] ---[ end trace e25f56762621a4a9 ]---
[ 3.583482] [drm] Internal thermal controller with fan control
[ 3.585338] [drm] radeon: power management initialized
[ 3.640125] [drm] fb mappable at 0xD0142000
[ 3.640130] [drm] vram apper at 0xD0000000
[ 3.640132] [drm] size 8294400
[ 3.640134] [drm] fb depth is 24
[ 3.640136] [drm] pitch is 7680
[ 3.641668] fbcon: radeondrmfb (fb0) is primary device
[ 3.664208] Console: switching to colour frame buffer device 240x67
[ 3.672340] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 3.672344] radeon 0000:01:00.0: registered panic notifier
[ 3.672462] [drm] Initialized radeon 2.29.0 20080528 for
0000:01:00.0 on minor 0
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 16:34 ` Josh Boyer
@ 2013-02-27 20:20 ` Josh Boyer
2013-02-27 20:24 ` Josh Boyer
2013-02-28 0:01 ` Josh Boyer
0 siblings, 2 replies; 26+ messages in thread
From: Josh Boyer @ 2013-02-27 20:20 UTC (permalink / raw)
To: Dave Airlie, Alex Deucher, Jerome Glisse
Cc: torvalds, DRI mailing list, linux-kernel
On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>> Alex Deucher (29):
>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>> drm/radeon: halt engines before disabling MC (evergreen)
>> drm/radeon: halt engines before disabling MC (cayman/TN)
>> drm/radeon: halt engines before disabling MC (si)
>> drm/radeon: use the reset mask to determine if rings are hung
>
> Something in this series of commits is causing the GPU to hang on reboot
> on my Dell XPS 8300 machine. That has a:
>
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
> ATI Caicos [Radeon HD 6450]
>
> card in it. After reboots, I get a screen that looks like this:
>
> http://t.co/tPnT6xQZUK
>
> I can hit it fairly consistently after a few reboots, so I tried doing a
> git bisect on the radeon driver and it came down to:
>
> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
So I don't think that's actually the cause of the problem. Or at least
not that alone. I reverted it on top of Linus' latest tree and I still
get the lockups.
Thus far I've reverted:
drm/radeon: use status regs to determine what to reset (6xx/7xx)
drm/radeon: use status regs to determine what to reset (evergreen)
drm/radeon: use status regs to determine what to reset (cayman)
drm/radeon: use status regs to determine what to reset (si)
drm/radeon: halt engines before disabling MC (6xx/7xx)
drm/radeon: halt engines before disabling MC (evergreen)
drm/radeon: halt engines before disabling MC (cayman/TN)
drm/radeon: halt engines before disabling MC (si)
drm/radeon: use the reset mask to determine if rings are hung
and can still recreate the issue. I'm starting to think the problem is
in one of:
drm/radeon: rework GPU reset on r6xx/r7xx
drm/radeon: rework GPU reset on evergreen
drm/radeon: rework GPU reset on cayman/TN
drm/radeon: rework GPU reset on cayman/TN (which should be si)
Still trying to figure out exactly which code paths are used on this
card, but I'll keep poking at it. Any ideas or tips for debug are more
than welcome.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 20:20 ` Josh Boyer
@ 2013-02-27 20:24 ` Josh Boyer
2013-02-28 0:01 ` Josh Boyer
1 sibling, 0 replies; 26+ messages in thread
From: Josh Boyer @ 2013-02-27 20:24 UTC (permalink / raw)
To: Dave Airlie, Alex Deucher, Jerome Glisse
Cc: torvalds, DRI mailing list, linux-kernel
On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>> Alex Deucher (29):
>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>> drm/radeon: halt engines before disabling MC (evergreen)
>>> drm/radeon: halt engines before disabling MC (cayman/TN)
>>> drm/radeon: halt engines before disabling MC (si)
>>> drm/radeon: use the reset mask to determine if rings are hung
>>
>> Something in this series of commits is causing the GPU to hang on reboot
>> on my Dell XPS 8300 machine. That has a:
>>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>> ATI Caicos [Radeon HD 6450]
>>
>> card in it. After reboots, I get a screen that looks like this:
>>
>> http://t.co/tPnT6xQZUK
>>
>> I can hit it fairly consistently after a few reboots, so I tried doing a
>> git bisect on the radeon driver and it came down to:
>>
>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>
> So I don't think that's actually the cause of the problem. Or at least
> not that alone. I reverted it on top of Linus' latest tree and I still
> get the lockups.
>
> Thus far I've reverted:
>
> drm/radeon: use status regs to determine what to reset (6xx/7xx)
> drm/radeon: use status regs to determine what to reset (evergreen)
> drm/radeon: use status regs to determine what to reset (cayman)
> drm/radeon: use status regs to determine what to reset (si)
> drm/radeon: halt engines before disabling MC (6xx/7xx)
> drm/radeon: halt engines before disabling MC (evergreen)
> drm/radeon: halt engines before disabling MC (cayman/TN)
> drm/radeon: halt engines before disabling MC (si)
> drm/radeon: use the reset mask to determine if rings are hung
>
> and can still recreate the issue. I'm starting to think the problem is
Sigh. Of course I just realized that I haven't been regenerating the
initramfs, so I'm not even testing what I'm building at this point. So
all I know is that it's broken somewhere between the two commits in my
initial bisect log. I've had better days.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 20:20 ` Josh Boyer
2013-02-27 20:24 ` Josh Boyer
@ 2013-02-28 0:01 ` Josh Boyer
2013-02-28 1:14 ` Josh Boyer
1 sibling, 1 reply; 26+ messages in thread
From: Josh Boyer @ 2013-02-28 0:01 UTC (permalink / raw)
To: Dave Airlie, Alex Deucher, Jerome Glisse
Cc: torvalds, DRI mailing list, linux-kernel
On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>> Alex Deucher (29):
>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>> drm/radeon: halt engines before disabling MC (evergreen)
>>> drm/radeon: halt engines before disabling MC (cayman/TN)
>>> drm/radeon: halt engines before disabling MC (si)
>>> drm/radeon: use the reset mask to determine if rings are hung
>>
>> Something in this series of commits is causing the GPU to hang on reboot
>> on my Dell XPS 8300 machine. That has a:
>>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>> ATI Caicos [Radeon HD 6450]
>>
>> card in it. After reboots, I get a screen that looks like this:
>>
>> http://t.co/tPnT6xQZUK
>>
>> I can hit it fairly consistently after a few reboots, so I tried doing a
>> git bisect on the radeon driver and it came down to:
>>
>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>
> So I don't think that's actually the cause of the problem. Or at least
> not that alone. I reverted it on top of Linus' latest tree and I still
> get the lockups.
Actually, git bisect does seem to have gotten it correct. Once I
actually tested the revert of just that on top of Linus' tree (commit
d895cb1af1), things seem to be working much better. I've rebooted a
dozen times without a lockup. The most I've seen it take on a kernel
with that commit included is 3 reboots, so that's definitely at least an
improvement.
Now that I seem to have narrowed down which commit is broken, I'd be
happy to test fixes, etc. Sorry for the noise from earlier today.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 0:01 ` Josh Boyer
@ 2013-02-28 1:14 ` Josh Boyer
2013-02-28 13:38 ` Alex Deucher
0 siblings, 1 reply; 26+ messages in thread
From: Josh Boyer @ 2013-02-28 1:14 UTC (permalink / raw)
To: Dave Airlie, Alex Deucher, Jerome Glisse
Cc: torvalds, DRI mailing list, linux-kernel
On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>>> Alex Deucher (29):
>>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>> drm/radeon: halt engines before disabling MC (evergreen)
>>>> drm/radeon: halt engines before disabling MC (cayman/TN)
>>>> drm/radeon: halt engines before disabling MC (si)
>>>> drm/radeon: use the reset mask to determine if rings are hung
>>>
>>> Something in this series of commits is causing the GPU to hang on reboot
>>> on my Dell XPS 8300 machine. That has a:
>>>
>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>>> ATI Caicos [Radeon HD 6450]
>>>
>>> card in it. After reboots, I get a screen that looks like this:
>>>
>>> http://t.co/tPnT6xQZUK
>>>
>>> I can hit it fairly consistently after a few reboots, so I tried doing a
>>> git bisect on the radeon driver and it came down to:
>>>
>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>
>> So I don't think that's actually the cause of the problem. Or at least
>> not that alone. I reverted it on top of Linus' latest tree and I still
>> get the lockups.
>
> Actually, git bisect does seem to have gotten it correct. Once I
> actually tested the revert of just that on top of Linus' tree (commit
> d895cb1af1), things seem to be working much better. I've rebooted a
> dozen times without a lockup. The most I've seen it take on a kernel
> with that commit included is 3 reboots, so that's definitely at least an
> improvement.
I give up. GPU issues are not my thing. 2 reboots after I sent that it
gave me pretty rainbow static again. So it might have been an
improvement, but revert it is not a solution.
Looking at there rest of the commits, the whole GPU rework might be
suspect, but I clearly have no clue.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 1:14 ` Josh Boyer
@ 2013-02-28 13:38 ` Alex Deucher
2013-02-28 13:44 ` Josh Boyer
0 siblings, 1 reply; 26+ messages in thread
From: Alex Deucher @ 2013-02-28 13:38 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel,
DRI mailing list
On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>>>> Alex Deucher (29):
>>>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>>> drm/radeon: halt engines before disabling MC (evergreen)
>>>>> drm/radeon: halt engines before disabling MC (cayman/TN)
>>>>> drm/radeon: halt engines before disabling MC (si)
>>>>> drm/radeon: use the reset mask to determine if rings are hung
>>>>
>>>> Something in this series of commits is causing the GPU to hang on reboot
>>>> on my Dell XPS 8300 machine. That has a:
>>>>
>>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>>>> ATI Caicos [Radeon HD 6450]
>>>>
>>>> card in it. After reboots, I get a screen that looks like this:
>>>>
>>>> http://t.co/tPnT6xQZUK
>>>>
>>>> I can hit it fairly consistently after a few reboots, so I tried doing a
>>>> git bisect on the radeon driver and it came down to:
>>>>
>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>
>>> So I don't think that's actually the cause of the problem. Or at least
>>> not that alone. I reverted it on top of Linus' latest tree and I still
>>> get the lockups.
>>
>> Actually, git bisect does seem to have gotten it correct. Once I
>> actually tested the revert of just that on top of Linus' tree (commit
>> d895cb1af1), things seem to be working much better. I've rebooted a
>> dozen times without a lockup. The most I've seen it take on a kernel
>> with that commit included is 3 reboots, so that's definitely at least an
>> improvement.
>
> I give up. GPU issues are not my thing. 2 reboots after I sent that it
> gave me pretty rainbow static again. So it might have been an
> improvement, but revert it is not a solution.
>
> Looking at there rest of the commits, the whole GPU rework might be
> suspect, but I clearly have no clue.
GPUs are tricky beasts :)
ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
problem anyway since it only affects 6xx/7xx and your card is handled
by the evergreen code. I'll put together some patches to help narrow
down the problem.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 13:38 ` Alex Deucher
@ 2013-02-28 13:44 ` Josh Boyer
2013-02-28 15:09 ` Alex Deucher
0 siblings, 1 reply; 26+ messages in thread
From: Josh Boyer @ 2013-02-28 13:44 UTC (permalink / raw)
To: Alex Deucher
Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel,
DRI mailing list
On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>>>>> Alex Deucher (29):
>>>>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>>>> drm/radeon: halt engines before disabling MC (evergreen)
>>>>>> drm/radeon: halt engines before disabling MC (cayman/TN)
>>>>>> drm/radeon: halt engines before disabling MC (si)
>>>>>> drm/radeon: use the reset mask to determine if rings are hung
>>>>>
>>>>> Something in this series of commits is causing the GPU to hang on reboot
>>>>> on my Dell XPS 8300 machine. That has a:
>>>>>
>>>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>>>>> ATI Caicos [Radeon HD 6450]
>>>>>
>>>>> card in it. After reboots, I get a screen that looks like this:
>>>>>
>>>>> http://t.co/tPnT6xQZUK
>>>>>
>>>>> I can hit it fairly consistently after a few reboots, so I tried doing a
>>>>> git bisect on the radeon driver and it came down to:
>>>>>
>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>
>>>> So I don't think that's actually the cause of the problem. Or at least
>>>> not that alone. I reverted it on top of Linus' latest tree and I still
>>>> get the lockups.
>>>
>>> Actually, git bisect does seem to have gotten it correct. Once I
>>> actually tested the revert of just that on top of Linus' tree (commit
>>> d895cb1af1), things seem to be working much better. I've rebooted a
>>> dozen times without a lockup. The most I've seen it take on a kernel
>>> with that commit included is 3 reboots, so that's definitely at least an
>>> improvement.
>>
>> I give up. GPU issues are not my thing. 2 reboots after I sent that it
>> gave me pretty rainbow static again. So it might have been an
>> improvement, but revert it is not a solution.
>>
>> Looking at there rest of the commits, the whole GPU rework might be
>> suspect, but I clearly have no clue.
>
> GPUs are tricky beasts :)
Understatement ;).
> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
> problem anyway since it only affects 6xx/7xx and your card is handled
> by the evergreen code. I'll put together some patches to help narrow
> down the problem.
Yeah, that's the biggest problem I have, not knowing which functions are
actually being executed for this card. It looks like a combination of
stuff in evergreen.c and ni.c, but I have no idea.
Patches would be great. If nothing else, I'm really good at building
kernels and rebooting by now.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 13:44 ` Josh Boyer
@ 2013-02-28 15:09 ` Alex Deucher
2013-02-28 15:15 ` Josh Boyer
0 siblings, 1 reply; 26+ messages in thread
From: Alex Deucher @ 2013-02-28 15:09 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel,
DRI mailing list
[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]
On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>>>>>> Alex Deucher (29):
>>>>>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>>>>>> drm/radeon: halt engines before disabling MC (evergreen)
>>>>>>> drm/radeon: halt engines before disabling MC (cayman/TN)
>>>>>>> drm/radeon: halt engines before disabling MC (si)
>>>>>>> drm/radeon: use the reset mask to determine if rings are hung
>>>>>>
>>>>>> Something in this series of commits is causing the GPU to hang on reboot
>>>>>> on my Dell XPS 8300 machine. That has a:
>>>>>>
>>>>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
>>>>>> ATI Caicos [Radeon HD 6450]
>>>>>>
>>>>>> card in it. After reboots, I get a screen that looks like this:
>>>>>>
>>>>>> http://t.co/tPnT6xQZUK
>>>>>>
>>>>>> I can hit it fairly consistently after a few reboots, so I tried doing a
>>>>>> git bisect on the radeon driver and it came down to:
>>>>>>
>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>
>>>>> So I don't think that's actually the cause of the problem. Or at least
>>>>> not that alone. I reverted it on top of Linus' latest tree and I still
>>>>> get the lockups.
>>>>
>>>> Actually, git bisect does seem to have gotten it correct. Once I
>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>> d895cb1af1), things seem to be working much better. I've rebooted a
>>>> dozen times without a lockup. The most I've seen it take on a kernel
>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>> improvement.
>>>
>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it
>>> gave me pretty rainbow static again. So it might have been an
>>> improvement, but revert it is not a solution.
>>>
>>> Looking at there rest of the commits, the whole GPU rework might be
>>> suspect, but I clearly have no clue.
>>
>> GPUs are tricky beasts :)
>
> Understatement ;).
>
>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>> problem anyway since it only affects 6xx/7xx and your card is handled
>> by the evergreen code. I'll put together some patches to help narrow
>> down the problem.
>
> Yeah, that's the biggest problem I have, not knowing which functions are
> actually being executed for this card. It looks like a combination of
> stuff in evergreen.c and ni.c, but I have no idea.
>
> Patches would be great. If nothing else, I'm really good at building
> kernels and rebooting by now.
Two possible fixes attached. The first attempts a full reset of all
blocks if the MC (memory controller) is hung. That may work better
than just resetting the MC. The second just disables MC reset. I'm
not sure we can reliably tell if it's busy due to display requests
hitting the MC periodically which would lead to needlessly resetting
it possibly leading to failures like you are seeing.
Alex
[-- Attachment #2: 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch --]
[-- Type: text/x-patch, Size: 992 bytes --]
From 9a648b04474ed230601c3c3e816cb281ebaad604 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Thu, 28 Feb 2013 09:56:48 -0500
Subject: [PATCH] drm/radeon: XXX try a full reset if the MC is busy
See if this helps.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
drivers/gpu/drm/radeon/evergreen.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
index 3c38ea4..bbcac11 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2438,6 +2438,12 @@ static u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev)
if (tmp & L2_BUSY)
reset_mask |= RADEON_RESET_VMC;
+ /* reset everything if we attempt to reset the MC */
+ if (reset_mask & RADEON_RESET_MC) {
+ dev_info(rdev->dev, "MC busy: 0x%08X, resetting ALL\n", reset_mask);
+ reset_mask = 0xffffffff;
+ }
+
return reset_mask;
}
--
1.7.7.5
[-- Attachment #3: 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch --]
[-- Type: text/x-patch, Size: 1138 bytes --]
From 834c26ab02e3581ea97b39a90fc0637e7becfa67 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Thu, 28 Feb 2013 10:03:08 -0500
Subject: [PATCH] drm/radeon: XXX skip MC reset as it's probably not hung
The MC is mostly likely busy (e.g., display requests), not hung
so no need to reset it. Doing an MC reset is tricky and not
particularly reliable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
drivers/gpu/drm/radeon/evergreen.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
index 3c38ea4..0f15ada 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2438,6 +2438,12 @@ static u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev)
if (tmp & L2_BUSY)
reset_mask |= RADEON_RESET_VMC;
+ /* Skip MC reset as it's mostly likely not hung, just busy */
+ if (reset_mask & RADEON_RESET_MC) {
+ dev_info(rdev->dev, "MC busy: 0x%08X, clearing.\n", reset_mask);
+ reset_mask &= ~RADEON_RESET_MC;
+ }
+
return reset_mask;
}
--
1.7.7.5
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 15:09 ` Alex Deucher
@ 2013-02-28 15:15 ` Josh Boyer
2013-02-28 18:59 ` Josh Boyer
0 siblings, 1 reply; 26+ messages in thread
From: Josh Boyer @ 2013-02-28 15:15 UTC (permalink / raw)
To: Alex Deucher
Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel,
DRI mailing list
On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>>
>>>>>> So I don't think that's actually the cause of the problem. Or at least
>>>>>> not that alone. I reverted it on top of Linus' latest tree and I still
>>>>>> get the lockups.
>>>>>
>>>>> Actually, git bisect does seem to have gotten it correct. Once I
>>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>>> d895cb1af1), things seem to be working much better. I've rebooted a
>>>>> dozen times without a lockup. The most I've seen it take on a kernel
>>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>>> improvement.
>>>>
>>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it
>>>> gave me pretty rainbow static again. So it might have been an
>>>> improvement, but revert it is not a solution.
>>>>
>>>> Looking at there rest of the commits, the whole GPU rework might be
>>>> suspect, but I clearly have no clue.
>>>
>>> GPUs are tricky beasts :)
>>
>> Understatement ;).
>>
>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>>> problem anyway since it only affects 6xx/7xx and your card is handled
>>> by the evergreen code. I'll put together some patches to help narrow
>>> down the problem.
>>
>> Yeah, that's the biggest problem I have, not knowing which functions are
>> actually being executed for this card. It looks like a combination of
>> stuff in evergreen.c and ni.c, but I have no idea.
>>
>> Patches would be great. If nothing else, I'm really good at building
>> kernels and rebooting by now.
>
> Two possible fixes attached. The first attempts a full reset of all
> blocks if the MC (memory controller) is hung. That may work better
> than just resetting the MC. The second just disables MC reset. I'm
> not sure we can reliably tell if it's busy due to display requests
> hitting the MC periodically which would lead to needlessly resetting
> it possibly leading to failures like you are seeing.
OK. I'll test them individually. It will probably take a bit because
I'll want to do numerous reboots if things seem "fixed" with one or the
other.
I'll let you know how things go.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 15:15 ` Josh Boyer
@ 2013-02-28 18:59 ` Josh Boyer
2013-03-05 15:21 ` Josh Boyer
0 siblings, 1 reply; 26+ messages in thread
From: Josh Boyer @ 2013-02-28 18:59 UTC (permalink / raw)
To: Alex Deucher
Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel,
DRI mailing list
On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>>>
>>>>>>> So I don't think that's actually the cause of the problem. Or at least
>>>>>>> not that alone. I reverted it on top of Linus' latest tree and I still
>>>>>>> get the lockups.
>>>>>>
>>>>>> Actually, git bisect does seem to have gotten it correct. Once I
>>>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>>>> d895cb1af1), things seem to be working much better. I've rebooted a
>>>>>> dozen times without a lockup. The most I've seen it take on a kernel
>>>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>>>> improvement.
>>>>>
>>>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it
>>>>> gave me pretty rainbow static again. So it might have been an
>>>>> improvement, but revert it is not a solution.
>>>>>
>>>>> Looking at there rest of the commits, the whole GPU rework might be
>>>>> suspect, but I clearly have no clue.
>>>>
>>>> GPUs are tricky beasts :)
>>>
>>> Understatement ;).
>>>
>>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>>>> problem anyway since it only affects 6xx/7xx and your card is handled
>>>> by the evergreen code. I'll put together some patches to help narrow
>>>> down the problem.
>>>
>>> Yeah, that's the biggest problem I have, not knowing which functions are
>>> actually being executed for this card. It looks like a combination of
>>> stuff in evergreen.c and ni.c, but I have no idea.
>>>
>>> Patches would be great. If nothing else, I'm really good at building
>>> kernels and rebooting by now.
>>
>> Two possible fixes attached. The first attempts a full reset of all
>> blocks if the MC (memory controller) is hung. That may work better
>> than just resetting the MC. The second just disables MC reset. I'm
>> not sure we can reliably tell if it's busy due to display requests
>> hitting the MC periodically which would lead to needlessly resetting
>> it possibly leading to failures like you are seeing.
>
> OK. I'll test them individually. It will probably take a bit because
> I'll want to do numerous reboots if things seem "fixed" with one or the
> other.
>
> I'll let you know how things go.
I applied each individually on top of Linus' tree as of this morning
(commit 2a7d2b96d5) built, installed, and tested.
0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in
two reboots.
0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone
21 reboots without a hang/rainbow static. You'll understand if I'm
hesitant to declare success, but resetting the MC does indeed appear to
be the issue. I'll keep rebooting for a while to make sure.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 1:39 ` Linus Torvalds
` (2 preceding siblings ...)
2013-02-27 10:04 ` Chris Wilson
@ 2013-03-03 15:39 ` Azat Khuzhin
2013-03-05 19:18 ` Daniel Vetter
4 siblings, 0 replies; 26+ messages in thread
From: Azat Khuzhin @ 2013-03-03 15:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Daniel Vetter, Imre Deak, DRI mailing list,
Linux Kernel Mailing List
On Wed, Feb 27, 2013 at 5:39 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote:
>>
>> Highlights:
>>
>> i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT
>> code,
>
> Lowlight:
>
> There's something wrong with i915 DP detection or whatever. I get
> stuff like this:
>
> [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
> .....
> [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
I have the same messages after upgrading up to
b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50
But in my case when I reboot computer the second monitor, that plugged
via HDMI, didn't works, end when I run `xrandr`, I have next messages
in kern.log
Mar 3 18:09:15 home-spb kernel: [12321.758273] [drm:intel_dp_aux_ch]
*ERROR* dp_aux_ch not done status 0xa143003f
Mar 3 18:09:15 home-spb kernel: [12321.771715]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.782712]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.793715]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.804719]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.815725]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.817293] [drm:intel_dp_aux_ch]
*ERROR* dp_aux_ch not done status 0xa143003f
# lspci | fgrep -i graph
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09)
I tested some commits, and here the results:
- Breaked at v3.8-10206-gb0af9cd
- Works normal v3.8-rc3-139-g34f2be4
- Works normal v3.8-rc3-188-g10aa17c
- Works normal 6dc1c49
I've tested 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch and it
works for me.
Thank, Dave.
>
> and after that the screen ends up black.
>
> It's happened twice now, but is not 100% repeatable. It looks like the
> message itself is new, but the black screen is also new and does seem
> to happen when I get the message, so...
>
> The second time I touched the power button, and the machine came back.
> Apparently the suspend/resume cycle made it all magically work: the
> suspend caused the same errors, but then the resume made it all good
> again.
>
> Some kind of missed initialization at bootup? It's not reliable enough
> to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915:
> irq-drive the dp aux communication") since that is where the message
> was added..
>
> Btw, looking at that commit, what do you think the semantics of the
> timeout in something like
>
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
>
> would be? What's that magic "10"? It's some totally random number.
>
> Guys, it should be something meaningful. If you meant a tenth of a
> second, use HZ/10 or something. Because just the plain "10" is crazy.
> I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a
> hundreth of a second. Was that what you intended? Because if it was,
> it is still crap, since CONFIG_HZ might be 100, and then you're
> waiting for ten times longer.
>
> IOW, passing in a random number like that is crazy. It cannot possibly
> be right.
>
> I have no idea whether the timeout has anything to do with anything,
> but it reinforces my suspicion that there is something wrong with that
> commit.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Respectfully
Azat Khuzhin
Primary email a3at.mail@gmail.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 18:59 ` Josh Boyer
@ 2013-03-05 15:21 ` Josh Boyer
2013-03-05 15:48 ` Alex Deucher
0 siblings, 1 reply; 26+ messages in thread
From: Josh Boyer @ 2013-03-05 15:21 UTC (permalink / raw)
To: Alex Deucher
Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel,
DRI mailing list
On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>>>>
>>>>>>>> So I don't think that's actually the cause of the problem. Or at least
>>>>>>>> not that alone. I reverted it on top of Linus' latest tree and I still
>>>>>>>> get the lockups.
>>>>>>>
>>>>>>> Actually, git bisect does seem to have gotten it correct. Once I
>>>>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>>>>> d895cb1af1), things seem to be working much better. I've rebooted a
>>>>>>> dozen times without a lockup. The most I've seen it take on a kernel
>>>>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>>>>> improvement.
>>>>>>
>>>>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it
>>>>>> gave me pretty rainbow static again. So it might have been an
>>>>>> improvement, but revert it is not a solution.
>>>>>>
>>>>>> Looking at there rest of the commits, the whole GPU rework might be
>>>>>> suspect, but I clearly have no clue.
>>>>>
>>>>> GPUs are tricky beasts :)
>>>>
>>>> Understatement ;).
>>>>
>>>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>>>>> problem anyway since it only affects 6xx/7xx and your card is handled
>>>>> by the evergreen code. I'll put together some patches to help narrow
>>>>> down the problem.
>>>>
>>>> Yeah, that's the biggest problem I have, not knowing which functions are
>>>> actually being executed for this card. It looks like a combination of
>>>> stuff in evergreen.c and ni.c, but I have no idea.
>>>>
>>>> Patches would be great. If nothing else, I'm really good at building
>>>> kernels and rebooting by now.
>>>
>>> Two possible fixes attached. The first attempts a full reset of all
>>> blocks if the MC (memory controller) is hung. That may work better
>>> than just resetting the MC. The second just disables MC reset. I'm
>>> not sure we can reliably tell if it's busy due to display requests
>>> hitting the MC periodically which would lead to needlessly resetting
>>> it possibly leading to failures like you are seeing.
>>
>> OK. I'll test them individually. It will probably take a bit because
>> I'll want to do numerous reboots if things seem "fixed" with one or the
>> other.
>>
>> I'll let you know how things go.
>
> I applied each individually on top of Linus' tree as of this morning
> (commit 2a7d2b96d5) built, installed, and tested.
>
> 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in
> two reboots.
>
> 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone
> 21 reboots without a hang/rainbow static. You'll understand if I'm
> hesitant to declare success, but resetting the MC does indeed appear to
> be the issue. I'll keep rebooting for a while to make sure.
OK, I'm still running on the kernel with that patch and things still
work. The only other "issue" I'm seeing at the moment is my dmesg is
full of:
[349316.595749] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
[349436.654946] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
[349436.655997] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
[349496.698441] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
[349556.726767] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
[349556.727797] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
So hopefully your patch is on the way into Linus' tree at some point
soon.
josh
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-03-05 15:21 ` Josh Boyer
@ 2013-03-05 15:48 ` Alex Deucher
0 siblings, 0 replies; 26+ messages in thread
From: Alex Deucher @ 2013-03-05 15:48 UTC (permalink / raw)
To: Josh Boyer
Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel,
DRI mailing list
On Tue, Mar 5, 2013 at 10:21 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit
>>>>>>>>>
>>>>>>>>> So I don't think that's actually the cause of the problem. Or at least
>>>>>>>>> not that alone. I reverted it on top of Linus' latest tree and I still
>>>>>>>>> get the lockups.
>>>>>>>>
>>>>>>>> Actually, git bisect does seem to have gotten it correct. Once I
>>>>>>>> actually tested the revert of just that on top of Linus' tree (commit
>>>>>>>> d895cb1af1), things seem to be working much better. I've rebooted a
>>>>>>>> dozen times without a lockup. The most I've seen it take on a kernel
>>>>>>>> with that commit included is 3 reboots, so that's definitely at least an
>>>>>>>> improvement.
>>>>>>>
>>>>>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it
>>>>>>> gave me pretty rainbow static again. So it might have been an
>>>>>>> improvement, but revert it is not a solution.
>>>>>>>
>>>>>>> Looking at there rest of the commits, the whole GPU rework might be
>>>>>>> suspect, but I clearly have no clue.
>>>>>>
>>>>>> GPUs are tricky beasts :)
>>>>>
>>>>> Understatement ;).
>>>>>
>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the
>>>>>> problem anyway since it only affects 6xx/7xx and your card is handled
>>>>>> by the evergreen code. I'll put together some patches to help narrow
>>>>>> down the problem.
>>>>>
>>>>> Yeah, that's the biggest problem I have, not knowing which functions are
>>>>> actually being executed for this card. It looks like a combination of
>>>>> stuff in evergreen.c and ni.c, but I have no idea.
>>>>>
>>>>> Patches would be great. If nothing else, I'm really good at building
>>>>> kernels and rebooting by now.
>>>>
>>>> Two possible fixes attached. The first attempts a full reset of all
>>>> blocks if the MC (memory controller) is hung. That may work better
>>>> than just resetting the MC. The second just disables MC reset. I'm
>>>> not sure we can reliably tell if it's busy due to display requests
>>>> hitting the MC periodically which would lead to needlessly resetting
>>>> it possibly leading to failures like you are seeing.
>>>
>>> OK. I'll test them individually. It will probably take a bit because
>>> I'll want to do numerous reboots if things seem "fixed" with one or the
>>> other.
>>>
>>> I'll let you know how things go.
>>
>> I applied each individually on top of Linus' tree as of this morning
>> (commit 2a7d2b96d5) built, installed, and tested.
>>
>> 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in
>> two reboots.
>>
>> 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone
>> 21 reboots without a hang/rainbow static. You'll understand if I'm
>> hesitant to declare success, but resetting the MC does indeed appear to
>> be the issue. I'll keep rebooting for a while to make sure.
>
> OK, I'm still running on the kernel with that patch and things still
> work. The only other "issue" I'm seeing at the moment is my dmesg is
> full of:
>
> [349316.595749] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
> [349436.654946] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
> [349436.655997] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
> [349496.698441] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
> [349556.726767] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
> [349556.727797] radeon 0000:01:00.0: MC busy: 0x00000409, clearing.
>
I'll make those debug only when the patch goes upstream.
> So hopefully your patch is on the way into Linus' tree at some point
> soon.
It'll be in my next -fixes pull.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 1:39 ` Linus Torvalds
` (3 preceding siblings ...)
2013-03-03 15:39 ` Azat Khuzhin
@ 2013-03-05 19:18 ` Daniel Vetter
4 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2013-03-05 19:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Daniel Vetter, Imre Deak, DRI mailing list,
Linux Kernel Mailing List, Paulo Zanoni
On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote:
> >
> > Highlights:
> >
> > i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT
> > code,
>
> Lowlight:
>
> There's something wrong with i915 DP detection or whatever. I get
> stuff like this:
>
> [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
> .....
> [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
>
> and after that the screen ends up black.
>
> It's happened twice now, but is not 100% repeatable. It looks like the
> message itself is new, but the black screen is also new and does seem
> to happen when I get the message, so...
>
> The second time I touched the power button, and the machine came back.
> Apparently the suspend/resume cycle made it all magically work: the
> suspend caused the same errors, but then the resume made it all good
> again.
>
> Some kind of missed initialization at bootup? It's not reliable enough
> to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915:
> irq-drive the dp aux communication") since that is where the message
> was added..
>
> Btw, looking at that commit, what do you think the semantics of the
> timeout in something like
>
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
>
> would be? What's that magic "10"? It's some totally random number.
>
> Guys, it should be something meaningful. If you meant a tenth of a
> second, use HZ/10 or something. Because just the plain "10" is crazy.
> I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a
> hundreth of a second. Was that what you intended? Because if it was,
> it is still crap, since CONFIG_HZ might be 100, and then you're
> waiting for ten times longer.
>
> IOW, passing in a random number like that is crazy. It cannot possibly
> be right.
>
> I have no idea whether the timeout has anything to do with anything,
> but it reinforces my suspicion that there is something wrong with that
> commit.
Ok, I've merged two patches from Paulo, one to fixup the harmless jiffies
vs. msec confusion. And the other to plug a race in our irq handler which
did lead to missed dp aux interrupts according to some digging done by
Imre. The important patch is the current tip of
git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes
44498aea293b37af1d463acd9658cdce1ecdf427 drm/i915: also disable south interrupts when handling them
Just in case you want to give it a quick whirl. Since the failed dp aux
transaction caused the resume modeset to fail for you (resulting in the
black screen) I hope that this should fix both issues.
I'll forward the pull to Dave in a few days since atm I'm stalling a bit
for confirmation on another little regression fix. And there's nothing
earth-shattering in my -fixes queue right now.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-28 11:18 ` Chris Wilson
@ 2013-02-28 17:07 ` Sedat Dilek
0 siblings, 0 replies; 26+ messages in thread
From: Sedat Dilek @ 2013-02-28 17:07 UTC (permalink / raw)
To: Chris Wilson, Sedat Dilek, Dave Airlie, DRI, intel-gfx, LKML, linux-next
On Thu, Feb 28, 2013 at 12:18 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> > Hi,
>> >
>> > I am seeing this also on Linux-Next.
>> >
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > This seems to be hard reproducible...
>> > Laptop-LCD... Sandybridge Mobile-GT2.
>> >
>> > Is there a way to force the error?
>> >
>> > Possible patch see [1].
>> >
>> > - Sedat -
>> >
>> > [1] https://patchwork.kernel.org/patch/2192721/
>
> That was:
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + }
>
> You applied
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + {
>
> That second '{' is the source of the compile error.
Schei**e, OK I try with a v2.
A hint how to force the error?
- Sedat -
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 23:06 ` Sedat Dilek
@ 2013-02-28 11:18 ` Chris Wilson
2013-02-28 17:07 ` Sedat Dilek
0 siblings, 1 reply; 26+ messages in thread
From: Chris Wilson @ 2013-02-28 11:18 UTC (permalink / raw)
To: Sedat Dilek; +Cc: Dave Airlie, DRI, intel-gfx, LKML, linux-next
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> > Hi,
> >
> > I am seeing this also on Linux-Next.
> >
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > This seems to be hard reproducible...
> > Laptop-LCD... Sandybridge Mobile-GT2.
> >
> > Is there a way to force the error?
> >
> > Possible patch see [1].
> >
> > - Sedat -
> >
> > [1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ {
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
2013-02-27 22:36 Sedat Dilek
@ 2013-02-27 23:06 ` Sedat Dilek
2013-02-28 11:18 ` Chris Wilson
0 siblings, 1 reply; 26+ messages in thread
From: Sedat Dilek @ 2013-02-27 23:06 UTC (permalink / raw)
To: Chris Wilson; +Cc: Dave Airlie, DRI, intel-gfx, LKML, linux-next
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> Hi,
>
> I am seeing this also on Linux-Next.
>
> /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
> [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> (has irq: 1)!
> /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
> [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> (has irq: 1)!
>
> /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
> [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> (has irq: 1)!
>
> This seems to be hard reproducible...
> Laptop-LCD... Sandybridge Mobile-GT2.
>
> Is there a way to force the error?
>
> Possible patch see [1].
>
> - Sedat -
>
> [1] https://patchwork.kernel.org/patch/2192721/
Hmm, I tried to apply the test-patch against next-20130227 and it
fails building the i915 kernel-module.
- Sedat -
[-- Attachment #2: rebuild-with-intel_dp_aux_wait_done-fix.txt --]
[-- Type: text/plain, Size: 8615 bytes --]
LD drivers/gpu/drm/i915/built-in.o
CC [M] drivers/gpu/drm/i915/i915_drv.o
CC [M] drivers/gpu/drm/i915/i915_dma.o
CC [M] drivers/gpu/drm/i915/i915_irq.o
CC [M] drivers/gpu/drm/i915/i915_debugfs.o
CC [M] drivers/gpu/drm/i915/i915_suspend.o
CC [M] drivers/gpu/drm/i915/i915_gem.o
CC [M] drivers/gpu/drm/i915/i915_gem_context.o
CC [M] drivers/gpu/drm/i915/i915_gem_debug.o
CC [M] drivers/gpu/drm/i915/i915_gem_evict.o
CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o
CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o
CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o
CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o
CC [M] drivers/gpu/drm/i915/i915_sysfs.o
CC [M] drivers/gpu/drm/i915/i915_trace_points.o
CC [M] drivers/gpu/drm/i915/i915_ums.o
CC [M] drivers/gpu/drm/i915/intel_display.o
CC [M] drivers/gpu/drm/i915/intel_crt.o
CC [M] drivers/gpu/drm/i915/intel_lvds.o
CC [M] drivers/gpu/drm/i915/intel_bios.o
CC [M] drivers/gpu/drm/i915/intel_ddi.o
CC [M] drivers/gpu/drm/i915/intel_dp.o
drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_aux_wait_done':
drivers/gpu/drm/i915/intel_dp.c:352:1: error: invalid storage class for function 'intel_dp_aux_ch'
drivers/gpu/drm/i915/intel_dp.c:351:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
drivers/gpu/drm/i915/intel_dp.c:492:1: error: invalid storage class for function 'intel_dp_aux_native_write'
drivers/gpu/drm/i915/intel_dp.c:525:1: error: invalid storage class for function 'intel_dp_aux_native_write_1'
drivers/gpu/drm/i915/intel_dp.c:533:1: error: invalid storage class for function 'intel_dp_aux_native_read'
drivers/gpu/drm/i915/intel_dp.c:572:1: error: invalid storage class for function 'intel_dp_i2c_aux_ch'
drivers/gpu/drm/i915/intel_dp.c:669:1: error: invalid storage class for function 'intel_dp_i2c_init'
drivers/gpu/drm/i915/intel_dp.c:845:13: error: invalid storage class for function 'ironlake_set_pll_edp'
drivers/gpu/drm/i915/intel_dp.c:872:1: error: invalid storage class for function 'intel_dp_mode_set'
drivers/gpu/drm/i915/intel_dp.c:985:13: error: invalid storage class for function 'ironlake_wait_panel_status'
drivers/gpu/drm/i915/intel_dp.c:1004:13: error: invalid storage class for function 'ironlake_wait_panel_on'
drivers/gpu/drm/i915/intel_dp.c:1010:13: error: invalid storage class for function 'ironlake_wait_panel_off'
drivers/gpu/drm/i915/intel_dp.c:1016:13: error: invalid storage class for function 'ironlake_wait_panel_power_cycle'
drivers/gpu/drm/i915/intel_dp.c:1027:13: error: invalid storage class for function 'ironlake_get_pp_control'
drivers/gpu/drm/i915/intel_dp.c:1075:13: error: invalid storage class for function 'ironlake_panel_vdd_off_sync'
drivers/gpu/drm/i915/intel_dp.c:1097:13: error: invalid storage class for function 'ironlake_panel_vdd_work'
drivers/gpu/drm/i915/intel_dp.c:1244:13: error: invalid storage class for function 'ironlake_edp_pll_on'
drivers/gpu/drm/i915/intel_dp.c:1270:13: error: invalid storage class for function 'ironlake_edp_pll_off'
drivers/gpu/drm/i915/intel_dp.c:1325:13: error: invalid storage class for function 'intel_dp_get_hw_state'
drivers/gpu/drm/i915/intel_dp.c:1374:13: error: invalid storage class for function 'intel_disable_dp'
drivers/gpu/drm/i915/intel_dp.c:1390:13: error: invalid storage class for function 'intel_post_disable_dp'
drivers/gpu/drm/i915/intel_dp.c:1400:13: error: invalid storage class for function 'intel_enable_dp'
drivers/gpu/drm/i915/intel_dp.c:1419:13: error: invalid storage class for function 'intel_pre_enable_dp'
drivers/gpu/drm/i915/intel_dp.c:1432:1: error: invalid storage class for function 'intel_dp_aux_native_read_retry'
drivers/gpu/drm/i915/intel_dp.c:1457:1: error: invalid storage class for function 'intel_dp_get_link_status'
drivers/gpu/drm/i915/intel_dp.c:1483:1: error: invalid storage class for function 'intel_dp_voltage_max'
drivers/gpu/drm/i915/intel_dp.c:1496:1: error: invalid storage class for function 'intel_dp_pre_emphasis_max'
drivers/gpu/drm/i915/intel_dp.c:1538:1: error: invalid storage class for function 'intel_get_adjust_train'
drivers/gpu/drm/i915/intel_dp.c:1569:1: error: invalid storage class for function 'intel_gen4_signal_levels'
drivers/gpu/drm/i915/intel_dp.c:1608:1: error: invalid storage class for function 'intel_gen6_edp_signal_levels'
drivers/gpu/drm/i915/intel_dp.c:1636:1: error: invalid storage class for function 'intel_gen7_edp_signal_levels'
drivers/gpu/drm/i915/intel_dp.c:1667:1: error: invalid storage class for function 'intel_hsw_signal_levels'
drivers/gpu/drm/i915/intel_dp.c:1701:1: error: invalid storage class for function 'intel_dp_set_signal_levels'
drivers/gpu/drm/i915/intel_dp.c:1728:1: error: invalid storage class for function 'intel_dp_set_link_train'
drivers/gpu/drm/i915/intel_dp.c:1986:1: error: invalid storage class for function 'intel_dp_link_down'
drivers/gpu/drm/i915/intel_dp.c:2065:1: error: invalid storage class for function 'intel_dp_get_dpcd'
drivers/gpu/drm/i915/intel_dp.c:2096:1: error: invalid storage class for function 'intel_dp_probe_oui'
drivers/gpu/drm/i915/intel_dp.c:2117:1: error: invalid storage class for function 'intel_dp_get_sink_irq'
drivers/gpu/drm/i915/intel_dp.c:2131:1: error: invalid storage class for function 'intel_dp_handle_test_request'
drivers/gpu/drm/i915/intel_dp.c:2195:1: error: invalid storage class for function 'intel_dp_detect_dpcd'
drivers/gpu/drm/i915/intel_dp.c:2234:1: error: invalid storage class for function 'ironlake_dp_detect'
drivers/gpu/drm/i915/intel_dp.c:2256:1: error: invalid storage class for function 'g4x_dp_detect'
drivers/gpu/drm/i915/intel_dp.c:2284:1: error: invalid storage class for function 'intel_dp_get_edid'
drivers/gpu/drm/i915/intel_dp.c:2310:1: error: invalid storage class for function 'intel_dp_get_edid_modes'
drivers/gpu/drm/i915/intel_dp.c:2328:1: error: invalid storage class for function 'intel_dp_detect'
drivers/gpu/drm/i915/intel_dp.c:2364:12: error: invalid storage class for function 'intel_dp_get_modes'
drivers/gpu/drm/i915/intel_dp.c:2392:1: error: invalid storage class for function 'intel_dp_detect_audio'
drivers/gpu/drm/i915/intel_dp.c:2408:1: error: invalid storage class for function 'intel_dp_set_property'
drivers/gpu/drm/i915/intel_dp.c:2488:1: error: invalid storage class for function 'intel_dp_destroy'
drivers/gpu/drm/i915/intel_dp.c:2522:2: error: initializer element is not constant
drivers/gpu/drm/i915/intel_dp.c:2522:2: error: (near initialization for 'intel_dp_helper_funcs.mode_fixup')
drivers/gpu/drm/i915/intel_dp.c:2523:2: error: initializer element is not constant
drivers/gpu/drm/i915/intel_dp.c:2523:2: error: (near initialization for 'intel_dp_helper_funcs.mode_set')
drivers/gpu/drm/i915/intel_dp.c:2528:2: error: initializer element is not constant
drivers/gpu/drm/i915/intel_dp.c:2528:2: error: (near initialization for 'intel_dp_connector_funcs.detect')
drivers/gpu/drm/i915/intel_dp.c:2530:2: error: initializer element is not constant
drivers/gpu/drm/i915/intel_dp.c:2530:2: error: (near initialization for 'intel_dp_connector_funcs.set_property')
drivers/gpu/drm/i915/intel_dp.c:2531:2: error: initializer element is not constant
drivers/gpu/drm/i915/intel_dp.c:2531:2: error: (near initialization for 'intel_dp_connector_funcs.destroy')
drivers/gpu/drm/i915/intel_dp.c:2535:2: error: initializer element is not constant
drivers/gpu/drm/i915/intel_dp.c:2535:2: error: (near initialization for 'intel_dp_connector_helper_funcs.get_modes')
drivers/gpu/drm/i915/intel_dp.c:2541:2: error: initializer element is not constant
drivers/gpu/drm/i915/intel_dp.c:2541:2: error: (near initialization for 'intel_dp_enc_funcs.destroy')
drivers/gpu/drm/i915/intel_dp.c:2545:1: error: invalid storage class for function 'intel_dp_hot_plug'
drivers/gpu/drm/i915/intel_dp.c:2592:1: error: invalid storage class for function 'intel_dp_add_properties'
drivers/gpu/drm/i915/intel_dp.c:2611:1: error: invalid storage class for function 'intel_dp_init_panel_power_sequencer'
drivers/gpu/drm/i915/intel_dp.c:2696:1: error: invalid storage class for function 'intel_dp_init_panel_power_sequencer_registers'
drivers/gpu/drm/i915/intel_dp.c:2957:1: error: expected declaration or statement at end of input
drivers/gpu/drm/i915/intel_dp.c:2957:1: error: expected declaration or statement at end of input
drivers/gpu/drm/i915/intel_dp.c: At top level:
drivers/gpu/drm/i915/intel_dp.c:110:13: warning: 'intel_dp_link_down' used but never defined [enabled by default]
make[1]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1
make: *** [_module_drivers/gpu/drm/i915] Error 2
[-- Attachment #3: 0001-drm-i915-Add-some-debugging-to-intel_dp_aux_wait_don.patch --]
[-- Type: application/octet-stream, Size: 1048 bytes --]
From 539d97d259f42ce9a453497c48322c7a24a67089 Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Wed, 27 Feb 2013 23:48:45 +0100
Subject: [PATCH] drm/i915: Add some debugging to intel_dp_aux_wait_done()
Patch from [1].
[1] https://patchwork.kernel.org/patch/2192721/
---
drivers/gpu/drm/i915/intel_dp.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 01c4ec4..a31c6e1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -338,9 +338,11 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
msecs_to_jiffies(10));
else
done = wait_for_atomic(C, 10) == 0;
- if (!done)
- DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
- has_aux_irq);
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq: %i), status=%08x!\n",
+ has_aux_irq, status);
+ {
#undef C
return status;
--
1.8.1.4
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1
@ 2013-02-27 22:36 Sedat Dilek
2013-02-27 23:06 ` Sedat Dilek
0 siblings, 1 reply; 26+ messages in thread
From: Sedat Dilek @ 2013-02-27 22:36 UTC (permalink / raw)
To: Chris Wilson; +Cc: Dave Airlie, DRI, intel-gfx, LKML, linux-next
Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
This seems to be hard reproducible...
Laptop-LCD... Sandybridge Mobile-GT2.
Is there a way to force the error?
Possible patch see [1].
- Sedat -
[1] https://patchwork.kernel.org/patch/2192721/
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2013-03-05 19:16 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-26 0:05 [git pull] drm merge for 3.9-rc1 Dave Airlie
2013-02-26 1:22 ` Linus Torvalds
2013-02-26 1:59 ` Dave Airlie
2013-02-27 1:39 ` Linus Torvalds
2013-02-27 2:25 ` Linus Torvalds
2013-02-27 3:30 ` Dave Airlie
2013-02-27 3:38 ` Linus Torvalds
2013-02-27 10:04 ` Chris Wilson
2013-03-03 15:39 ` Azat Khuzhin
2013-03-05 19:18 ` Daniel Vetter
2013-02-27 16:34 ` Josh Boyer
2013-02-27 20:20 ` Josh Boyer
2013-02-27 20:24 ` Josh Boyer
2013-02-28 0:01 ` Josh Boyer
2013-02-28 1:14 ` Josh Boyer
2013-02-28 13:38 ` Alex Deucher
2013-02-28 13:44 ` Josh Boyer
2013-02-28 15:09 ` Alex Deucher
2013-02-28 15:15 ` Josh Boyer
2013-02-28 18:59 ` Josh Boyer
2013-03-05 15:21 ` Josh Boyer
2013-03-05 15:48 ` Alex Deucher
2013-02-27 22:36 Sedat Dilek
2013-02-27 23:06 ` Sedat Dilek
2013-02-28 11:18 ` Chris Wilson
2013-02-28 17:07 ` Sedat Dilek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).