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
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
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.
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
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
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.
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
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;
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
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
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:
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
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:
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
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:
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
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:
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
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:
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
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:
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
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:
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
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:
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
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
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
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
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
dri-devel@lists.freedesktop.org