Hi Linus,
non-drm changes: one kref change we needed that went on list with no comments
New hardware: radeon: add support for Fusion APUs and Radeon HD6xxx chipsets nouveau: Fermi acceleration support (requires external fw for now)
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
There are also some switcheroo patches to further improve it, though I have a later patch blocking on an x86 platform driver for the nvidia/intel switcher.
Dave.
The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:
Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next
Alex Deucher (63): drm/radeon/kms: add pageflip ioctl support (v3) drm/radeon/kms: setup mc chremap properly on r7xx/evergreen drm/radeon/kms: upstream ObjectID.h updates drm/radeon/kms: upstream atombios.h updates drm/radeon/kms: upstream power table updates drm/radeon/kms: add new family id for AMD Ontario APUs drm/radeon/kms: atom changes for DCE4.1 devices drm/radeon/kms: Add support for external encoders on fusion APUs drm/radeon/kms: add support for ss overrides on Fusion APUs drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function drm/radeon/kms: MC setup changes for fusion APUs drm/radeon/kms: evergreen.c updates for fusion drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs drm/radeon/kms: add thermal sensor support for fusion APUs drm/radeon/kms: add bo blit support for Ontario fusion APUs drm/radeon/kms: refactor atombios power state fetching drm/radeon/kms: add power table parsing support for Ontario fusion APUs drm/radeon/kms: enable MSIs on fusion APUs drm/radeon/kms: add Ontario Fusion APU pci ids drm/radeon/kms: add Ontario APU ucode loading support drm/radeon/kms: improve pflip precision on r1xx-r4xx drm/radeon/kms: fix vram start calculation on ontario (v2) drm/radeon/kms: properly print ontario chip id drm/radeon/kms: fix DCE4.1 dig routing (v2) drm/radeon/kms/atom: clean up op_mask handler drm/radeon/kms: use LCD physical size from vbios tables if available drm/radeon/kms: parse the extended LCD info block drm/radeon/kms: disable bo moves using the blitter drm/radeon/kms: implement gpu lockup check for evergreen drm/radeon/kms: adjust quirk for acer laptop drm/radeon/kms: add quirk for Mac Radeon HD 2600 card drm/radeon/kms: add pcie get/set lane support for r6xx/r7xx/evergreen drm/radeon/kms: add support for gen2 pcie link speeds drm/radeon/kms: set the MSB of the HDP slice size drm/radeon/kms: fix some typos in evergreen pm4 defines drm/radeon/kms: clean up ASIC_IS_DCE41() macro drm/radeon/kms: add NI chip families drm/radeon/kms: update display watermark calculations for DCE5 drm/radeon/kms: DCE5 supports 16k display surfaces drm/radeon/kms: DCE5 atom SetPixelClock updates drm/radeon/kms: DCE5 atom spread spectrum updates drm/radeon/kms: DCE5 atom transmitter control updates drm/radeon/kms: DCE5 atom dig encoder updates drm/radeon/kms: dac dpms updates for DCE5 drm/radeon/kms: dvo dpms updates for DCE5 drm/radeon/kms: parse DCE5 encoder caps when setting up encoders drm/radeon/kms: handle NI thermal controller drm/radeon/kms: add disabled vbios accessor for NI asics drm/radeon/kms: fill gpu init for NI asics drm/radeon/kms: add backend map workaround for barts drm/radeon/kms: adjust default clock/vddc tracking for pm on DCE5 drm/radeon/kms: always use writeback/events for fences on NI drm/radeon/kms: add bo blit support for NI drm/radeon/kms: add ni_reg.h drm/radeon/kms: add support for DCE5 display LUTs drm/radeon/kms: add ucode loader for NI drm/radeon/kms/ni: load default sclk/mclk/vddc at pm init drm/radeon/kms: add radeon_asic struct for NI asics drm/radeon/kms: don't enable pcie gen2 on NI yet drm/radeon/kms: add NI pci ids drm/radeon/kms: only enable hdmi features if the monitor supports audio drm/radeon/kms: disable underscan by default
Ben Hutchings (1): drm/nouveau: Only select ACPI_VIDEO if its dependencies are met
Ben Skeggs (91): drm/nouveau: tidy fifo swmthd handler a little drm/nouveau: disallow fbcon accel if running in interrupt context drm/nouveau: add per-channel mutex, use to lock access to drm's channel drm/nouveau: add more fine-grained locking to channel list + structures drm/nouveau: switch to unlocked ioctls drm/nouveau: remove cpu_writers lock drm/nouveau: fix thinko in channel locking in semaphore path drm/nouveau: use interruptible waits during pushbuf validation drm/nouveau: return error from nouveau_ramht_remove() if not found drm/nouveau: hook up acpi power supply change tracking drm/nouveau: fallback to sw fbcon if we can't get mutex immediately drm/nv50: remove some unnecessary PDISPLAY init drm/nouveau: pass gpuobj alignment request down into backing allocator drm/nouveau: store engine type in gpuobj class structs drm/nouveau: use object class structs more extensively drm/nouveau: only expose the object classes that are supported by the chipset drm/nv84: add support for the PCRYPT engine drm/nv50: remove excessive alignment of graph/crypt contexts drm/nv50: create graph and crypt contexts on demand drm/nv50: clearer separation of the stages of evo init drm/nv50: move evo handling to nv50_evo.c drm/nv50: initial work to allow multiple evo channels drm/nv50: rework evo init to match nvidia more closely drm/nv50: improve evo error handler when more than just channel 0 active drm/nv50: fix evo instmem alignment drm/nv10: fix thinko and let nv17 do 3d again :) drm/nouveau: add support for MSI drm/nv50: regression fix, point NVAA/NVAC at correct PM functions drm/nv50: fix compute object class drm/nv50: 0x50c0 apparently works on NVA3+ too, so lets allow it drm/nouveau: allow irq handlers to be installed by engine-specific code drm/nv84: move PCRYPT ISR out of nouveau_irq.c drm/nv50: move GPIO ISR to nv50_gpio.c drm/nv50: use register/unregister functionality for PDISPLAY ISR drm/nouveau: move bitfield/enum helpers to nouveau_util.c drm/nv04-nv40: register vblank isr drm/nouveau: move PFIFO ISR into nv04_fifo.c drm/nouveau: tidy+move PGRAPH ISRs to their respective *_graph.c files drm/nv04-nv40: unregister irq handler on destroy drm/nv50: rework PGPIO IRQ handling and hotplug detection drm/nouveau: simplify gpuobj suspend/resume drm/nouveau: rework gpu-specific instmem interfaces drm/nv50: allocate page for unknown PFB object in nv50_fb.c drm/nv50: fix 0x100c90 init for NVAF drm/nouveau: remove dummy page use from PCI(E)GART, use PTE present instead drm/nv84: fix minor issues in PCRYPT implementation drm/nouveau: remove some useless GETPARAMs drm/nouveau: tidy up and extend dma object creation interfaces drm/nouveau: make fifo.create_context() responsible for mapping control regs drm/nouveau: implicitly insert non-DMA objects into RAMHT drm/nouveau: introduce a util function to wait on reg != val drm/nouveau: no need to zero dma objects, we fill them completely anyway drm/nouveau: wrap calls to ttm_bo_validate() drm/nouveau: fix use of drm_mm_node in semaphore object drm/nv50: implement custom vram mm drm/nv50: import new vm code drm/nv50: implement BAR1/BAR3 management on top of new VM code drm/nv50: implement global channel address space on new VM code drm/nv50: enable 4KiB pages for small vram allocations drm/nv50: enable non-contig vram allocations where requested drm/nv50: tidy up PCIEGART implementation drm/nouveau: allow gpuobj vinst to be a virtual address when necessary drm/nouveau: kick vram functions out into an "engine" drm/ttm: delay freeing of old node during move_memcpy until after iounmap drm/nv50: fix smatch warning in nv50_vram.c drm/nv50: add missing license header to nv50_fbcon.c drm/nouveau: modify vm to accomodate dual page tables for nvc0 drm/nvc0: import initial vm backend drm/nvc0: initial vm implementation, use for bar1/bar3 management drm/nvc0: create shared channel vm drm/nvc0: reject the notifier_alloc ioctl drm/nvc0: gpuobj_new need only check validity and init the relevant engine drm/nvc0: implement channel structure initialisation drm/nvc0: skip dma object creation for drm channel drm/nvc0: fix channel dma init paths drm/nvc0: implement fencing drm/nvc0: implement pfifo engine hooks drm/nvc0: implement pgraph engine hooks drm/nvc0: implement fbcon acceleration drm/nvc0: initial support for tiled buffer objects drm/nvc0: accelerate ttm buffer moves drm/nvc0: kill off a couple more magics drm/nvc0: nuke left-over debug messages drm/nvc0: parse a couple more PGRAPH_INTR drm/nv50: sync up gr data error names with rnn, use for nvc0 also drm/nvc0: reserve only subc 0 for kernel use drm/nvc0/pfifo: support for chipsets with only one PSUBFIFO (0xc1) drm/nvc0/pgraph: more unit names drm/nvc0/pgraph: fix 0x406028/0x405870 init drm/nvc0: fix init without firmware present drm/nouveau: create grctx on the fly on all chipsets
Chris Wilson (135): drm/i915/ringbuffer: Drop the redundant dev from the vfunc interface drm/i915: Propagate errors from writing to ringbuffer drm/i915: Move object to GPU domains after dispatching execbuffer drm/i915: Fix hangcheck to handle multiple rings drm/i915/debugfs: Include info for the other rings drm/i915: Remove the confusing global waiting/irq seqno drm/i915: Propagate error from failing to queue a request drm/i915: Bail early if we try to mmap an object too large to be mapped. drm/i915: Use the agp_size determined from the GTT drm/i915: Capture ERROR register on Sandybridge hangs drm/i915: Use pci_iomap for remapping the MMIO registers. drm/i915/ringbuffer: Check that we setup the ringbuffer drm/i915: Make the inactive object shrinker per-device drm/i915: Remove mmap_offset drm/i915: Eliminate nested get/put pages drm/i915: Kill GTT mappings when moving from GTT domain drm/i915: Do not return -1 from shrinker when nr_to_scan == 0 drm/i915: Convert BUG_ON(pin_count) from an impossible condition drm/i915: Only enforce fence limits inside the GTT. drm/i915: Remove the duplicate domain-change tracepoint for GPU flush drm/i915/ringbuffer: Disable the ringbuffer on cleanup. drm/i915: Record BLT engine error state drm/i915/ringbuffer: Remove duplicate initialisation of ring control agp/intel: Sandybridge doesn't require GMCH enabling drm/i915/debugfs: Display the contents of the BLT and BSD status pages drm/i915: Switch to using pci_iounmap in conjunction with pci_iomap drm/i915: Check if the GPU hung whilst waiting for the ring to clear drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism drm/i915: Record BSD engine error state drm/i915: Fix typo from e5281ccd in i915_gem_attach_phys_object() drm/i915: Evict just the purgeable GTT entries on the first pass agp/intel: the GMCH is always enabled for integrated processor graphics drm/i915/debugfs: Report ring in error state drm/i915: Apply big hammer to serialise buffer access between rings drm/i915: Move the invalidate|flush information out of the device struct Merge branch 'drm-intel-fixes' into drm-intel-next Revert "drm/i915: add MMIO debug output" Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915: Drop the iomem accessors when writing to the kmapped blt batch drm/i915: Ensure that if we ever try to pin+fence it is mappable. Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915: Handle GPU hangs during fault gracefully. drm/i915/ringbuffer: Be consistent in use of ring->size when initialising drm/i915/ringbuffer: Ignore failure to setup the ring on Sandybridge drm/i915: POSTING_READs are simply flushes and so irrelevant to tracing drm/i915: Fix unload after failed initialisation drm/i915: Unconditionally get the fence reg when pinning scanout drm/i915: Only add the lazy request if we end up waiting for it. drm/i915: Remove the global irq wait queue Revert "drm/i915/ringbuffer: Ignore failure to setup the ring on Sandybridge" drm/i915: Remove the definitions for Primary Ring Buffer drm/i915: Fix current tiling check for relaxed fencing Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915: Convert (void)I915_READ to POSTING_READ drm/i915/crt: Introduce struct intel_crt drm/i915: Capture pinned buffers on error drm/i915: Capture interesting display registers on error Merge branch 'drm-intel-fixes' into drm-intel-next Merge branch 'drm-intel-next' of arrandale:git/linux-2.6 into drm-intel-next drm/i915: Avoid oops when capturing NULL ring for inactive pinned buffers drm/i915/panel: Restore saved value of BLC_PWM_CTL drm/i915: Compute physical addresses from base of stolen memory agp/intel: Remove the artificial cap on stolen size agp/intel: Remove confusion of stolen entries not stolen memory drm/i915: Contract the magic IPS constants into a direct LUT Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915: Use drm_i915_gem_object as the preferred type drm/i915: Not all mappable regions require GTT fence regions agp/intel: Remove duplicate const drm/i915: Record fence registers on error. drm/i915: Move the implementation details of PIPE_CONTROL to the ringbuffer drm/i915: Remove a defunct BUG_ON drm/i915: Extend hangcheck timeout drm/i915: Thread the pipelining ring through the callers. drm/i915: Rework execbuffer pinning drm/i915: More accurately track last fence usage by the GPU drm/i915: Only save and restore fences for UMS drm/i915: Tweak on-error bbaddr parsing for clarity drm/i915: Mark a few functions as __must_check drm/i915: Defer accounting until read from debugfs drm/i915: Split i915_gem_execbuffer into its own file. drm/i915: Avoid allocation for execbuffer object list drm/i915/execbuffer: On error, starting unwinding from the previous object Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915: Release fenced GTT mapping on suspend drm/i915: Move instruction state invalidation from execbuffer to flush drm/i915/ringbuffer: Handle cliprects in the caller drm/i915/lvds: Disable panel-fitter on gen4 for 1:1 scale factors drm/i915: Prevent stalling for a GTT read back from a read-only GPU target drm/i915: Pipelined fencing [infrastructure] drm/i915: Remove inactive LRU tracking from set_domain_ioctl drm/i915: Kill the get_fence tracepoint Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915/lvds: Connect the PWM to the LVDS pipe drm/i915: Explain why we need to write DPLL twice drm/i915: Enable CB tuning of the Display PLL drm/i915: Re-enable RC6 for power-savings. drm/i915: Allow LVDS to be on pipe A for Ironlake+ drm/i915: Be paranoid and bail on resetting if we can't take the lock. drm/i915: Implement GPU semaphores for inter-ring synchronisation on SNB drm/i915: Enable self-refresh for Ironlake Merge branch 'drm-intel-fixes' into drm-intel-next Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915/dp: Trivial code tidy drm/i915: Avoid using PIPE_CONTROL on Ironlake drm/i915: Power Context register is only available for gen4 mobiles drm/i915: caps.has_rc6 is no longer used, remove it. drm/i915: Ignore fenced commands for gpu access on gen4 drm/i915: Uncouple render/power ctx before suspending drm/i915: Completely disable fence pipelining. drm/i915: Only emit a flush if there is an outstanding gpu write drm/i915: Wait for the bo if a display flip is pipelined on the other ring Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915: Disable renderctx powersaving support for Ironlake drm/i915: Re-arm the idle timers if the device is still busy drm/i915: Eliminate drm_gem_object_lookup during relocation drm/i915: Mark the user reloc error paths as unlikely drm/i915: driver.suspend and .resume are always set drm/i915: Restore GTT mapping first upon resume drm/i915/gtt: Clear the cachelines upon resume drm/i915: Terminate the FORCE WAKE after we have finished reading drm/i915: Enable RC6 autodownclocking on Sandybridge Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915/ringbuffer: Make IRQ refcnting atomic Merge branch 'drm-intel-fixes' into drm-intel-next drm/i915: Poll for seqno completion if IRQ is disabled drm/i915: Pass clock limits down to PLL matcher Revert "drm/i915: Avoid using PIPE_CONTROL on Ironlake" drm/i915: Wait for vblank before unpinning old fb Merge remote branch 'airlied/drm-core-next' into drm-intel-next drm/i915/sdvo: Border and stall select became test bits in gen5 drm/i915: Enable EI mode for RCx decision making on Sandybridge drm/i915: Allow the application to choose the constant addressing mode drm/i915: Undo "Uncouple render/power ctx before suspending" drm: Restore the old_fb upon modeset failure
Dan Carpenter (2): drm/nouveau: sizeof() vs ARRAY_SIZE() vga_switcheroo: comparing too few characters in strncmp()
Daniel Vetter (29): drm_mm: add support for range-restricted fair-lru scans drm/i915: range-restricted eviction support drm/i915: range-restricted bind_to_gtt drm/i915: unbind unmappable objects on fault/pin drm/i915: use the complete gtt intel-gtt: save PGETBL_CTL later in the setup process intel-gtt: maximize ggtt size on platforms that support this drm/i915: add mappable to gem_object_bind tracepoint drm/i915: add accounting for mappable objects in gtt v2 drm/i915: revert pageflip/mappable related abi breakage drm/i915: kill mappable/fenceable disdinction drm/i915: fix relaxed tiling for gen <= 3 && !g33 intel-gtt: drop dcache support for i830 and later intel-gtt: kill unneeded sandybridge memory types intel-gtt: switch i81x to the write_entry helpers intel-gtt: switch i81x to the common initialization helpers intel-gtt: fold i81x-only dcache support into the generic driver drm/i915|intel-gtt: consolidate intel-gtt.h headers drm/i915/gtt: call chipset flush directly drm: kill drm_agp_chipset_flush agp: kill agp_flush_chipset and corresponding ioctl drm/i915: track objects in the gtt drm/i915: restore gtt on resume in the drm instead of in intel-gtt.ko agp: kill agp_rebind_memory drm/i915: move gtt handling to i915_gem_gtt.c intel-gtt: export api for drm/i915 drm/i915: no more agp for gem drm/i915: Add a mechanism for pipelining fence register updates radeon: consolidate asic-specific function decls for pre-r600
Dave Airlie (20): drm/ttm: Add a bo list reserve fastpath (v2) Merge branch 'drm-ttm-next' into drm-core-next Merge branch 'drm-radeon-next' of ../drm-radeon-next into drm-core-next Merge branch 'drm-radeon-fusion' of ../drm-radeon-next into drm-core-next drm/radeon: add initial tracepoint support. Merge remote branch 'nouveau/drm-nouveau-next' of ../drm-nouveau-next into drm-core-next Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-core-next Merge remote branch 'intel/drm-intel-next' of /ssd/git/drm-next into drm-core-next Merge branch 'master' of /home/airlied/kernel/linux-2.6 into drm-core-next vga_switcheroo: print the IGD/DIS flag in the debugfs output. vga_switcheroo: make power switch handler optional vga_switcheroo: add debugging mux switch option. drm/nouveau: add delayed switch complete callback. nouveau/acpi: improve detection of what is IGD and what is DIS. vga_switcheroo: add reprobe hook for fbcon to recheck connected outputs. drm/switcheroo: track state of switch in drivers. vga_switcheroo: split switching into two stages. vga_switcheroo: fix build with non switcheroo enabled path. Merge remote branch 'nouveau/drm-nouveau-next' of ../drm-nouveau-next into drm-core-next Merge branch 'drm-radeon-ni' of ../drm-radeon-next into drm-core-next
David Fries (1): drm/kms: load fbcon from drm_kms_helper
Eric Anholt (5): drm/i915: Apply B-spec mandated workaround for read flushes on Ironlake. drm/i915: Apply display workaround required according to the B-Spec. drm/i915: Correct a comment about the use of the workqueue. drm/i915: Also reinit the BSD and BLT rings after a GPU reset. drm/i915: Add support for GPU reset on gen6.
Francisco Jerez (29): drm/nouveau: Leave BO eviction synchronization for later. drm/nouveau: Use lazy fence waits when doing software interchannel sync. drm/nouveau: Refactor context destruction to avoid a lock ordering issue. drm/nouveau: Fix race condition in channel refcount handling. drm/nouveau: Add unlocked variants of nouveau_channel_get/put. drm/nouveau: Fix lock unbalance on card take down. drm/nouveau: Implement weak channel references. drm/nouveau: Make fences take a weak channel reference. drm/nouveau: Avoid race in the interchannel sync code. drm/nouveau: Take fence spinlock in nouveau_fence_channel_fini(). drm/nv40: Ignore sync-to-vblank active when waiting for idle. drm/nv04: Make CRTC base changes effective in the next hsync. drm/nouveau: Implement the vblank DRM hooks. drm/nouveau: Implement the pageflip ioctl. drm/nouveau: Call drm_vblank_pre/post_modeset() around mode setting. drm/nv50: Keep track of the head a channel is vsync'ing to. drm/nouveau: Add a separate class for the kernel channel mutex. drm/nouveau: Rework tile region handling. drm/nv20: Add Z compression support. drm/nouveau: Fix sleep while atomic in nouveau_bo_fence(). drm/nouveau: fabricate DCB encoder table for iMac G4 drm/nv04-nv40: Give "gpuobj->cinst" the same meaning as on nv50. drm/nv04-nv10: Don't re-enable FIFO access multiple times after IRQ dispatch. drm/nouveau: Synchronize with the user channel before GPU object destruction. drm/nouveau: Use WC memory on the AGP GART. drm/nouveau: Spin for a bit in nouveau_fence_wait() before yielding the CPU. drm/nouveau: Avoid potential race between nouveau_fence_update() and context takedown. drm/nv04-nv40: Fix up PCI(E) GART DMA object bus address calculation. drm/nv50: fix a couple of vm init issues
James Simmons (2): drm/fb: Don't expose mmio for fbdev emulation layer drm: Update fbdev fb_fix_screeninfo
Jesse Barnes (1): drm/i915: dynamic render p-state support for Sandy Bridge
Keith Packard (2): drm/i915: Take advantage of auto-polling CRT hotplug detection on PCH hardware drm/i915: Fix restore of 965 fence regs since the register tracing change.
Lucas Stach (1): drm/nouveau: fix hwmon device binding
Marcin Slusarz (1): drm/nouveau: fix annoying nouveau_fence type issue
Marek Olšák (3): drm/radeon/kms: allow r500 US_FORMAT regs in the CS checker drm/radeon/kms: add ARGB2101010 colorbuffer support for r500 drm/radeon/kms: manage r300 CMASK RAM access and allow CMASK clear
Mario Kleiner (7): drm/vblank: Add support for precise vblank timestamping. drm/kms/radeon: Add support for precise vblank timestamping. drm/kms/radeon: Reorder vblank and pageflip interrupt handling. drm/kms/radeon: Use high precision timestamps for pageflip completion events. drm/i915: Add support for precise vblank timestamping (v2) drm/i915: Add Guess-o-matic for pageflip timestamping. drm-vblank: Always return true vblank count of scheduled vblank event.
Michel Hermier (1): drm/nouveau: Validate channel indices passed from userspace.
Tejun Heo (1): drm/radeon: use system_wq instead of dev_priv->wq
Thomas Hellstrom (9): kref: Add a kref_sub function drm/ttm: Use kref_sub instead of repeatedly calling kref_put drm/ttm: Optimize ttm_eu_backoff_reservation drm/ttm: Don't deadlock on recursive multi-bo reservations drm/ttm/radeon/nouveau: Kill the bo lock in favour of a bo device fence_lock drm/ttm: Improved fencing of buffer object lists drm/ttm/vmwgfx: Have TTM manage the validation sequence. drm/ttm: Fix up io_mem_reserve / io_mem_free calling drm/radeon: Use the ttm execbuf utilities
Tijl Coosemans (1): drm/radeon: Definition of R_0003C2_GENMO_WT seems wrong
Yuanhan Liu (5): drm/i915: trace down all the register write and read drm/i915: Add untraced register read/write interface drm/i915: filter out the read/write of GPIO registers from debug tracing drm/i915: Add self-refresh support on Sandybridge drm/i915: Add frame buffer compression on Sandybridge
Zhenyu Wang (2): agp/intel: fix cache control for sandybridge agp/intel: restore cache behavior on sandybridge
Zou Nan hai (2): drm/i915: SNB BLT workaround drm/i915/ringbuffer: set FORCE_WAKE bit before reading ring register
drivers/char/agp/agp.h | 1 - drivers/char/agp/compat_ioctl.c | 1 - drivers/char/agp/compat_ioctl.h | 1 - drivers/char/agp/frontend.c | 8 - drivers/char/agp/generic.c | 27 - drivers/char/agp/intel-agp.c | 5 - drivers/char/agp/intel-agp.h | 14 +- drivers/char/agp/intel-gtt.c | 778 +++--- drivers/gpu/drm/drm_agpsupport.c | 6 - drivers/gpu/drm/drm_crtc_helper.c | 18 +- drivers/gpu/drm/drm_fb_helper.c | 61 +- drivers/gpu/drm/drm_fops.c | 2 + drivers/gpu/drm/drm_irq.c | 566 ++++- drivers/gpu/drm/drm_mm.c | 40 +- drivers/gpu/drm/drm_stub.c | 10 + drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/i915_debugfs.c | 471 +++- drivers/gpu/drm/i915/i915_dma.c | 794 +++--- drivers/gpu/drm/i915/i915_drv.c | 80 +- drivers/gpu/drm/i915/i915_drv.h | 605 +++-- drivers/gpu/drm/i915/i915_gem.c | 3764 +++++++++----------------- drivers/gpu/drm/i915/i915_gem_debug.c | 23 +- drivers/gpu/drm/i915/i915_gem_evict.c | 125 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1343 +++++++++ drivers/gpu/drm/i915/i915_gem_gtt.c | 99 + drivers/gpu/drm/i915/i915_gem_tiling.c | 139 +- drivers/gpu/drm/i915/i915_irq.c | 724 ++++-- drivers/gpu/drm/i915/i915_reg.h | 193 ++- drivers/gpu/drm/i915/i915_suspend.c | 104 +- drivers/gpu/drm/i915/i915_trace.h | 91 +- drivers/gpu/drm/i915/intel_display.c | 999 ++++++-- drivers/gpu/drm/i915/intel_dp.c | 3 +- drivers/gpu/drm/i915/intel_drv.h | 22 +- drivers/gpu/drm/i915/intel_fb.c | 32 +- drivers/gpu/drm/i915/intel_i2c.c | 21 +- drivers/gpu/drm/i915/intel_lvds.c | 43 +- drivers/gpu/drm/i915/intel_opregion.c | 8 +- drivers/gpu/drm/i915/intel_overlay.c | 116 +- drivers/gpu/drm/i915/intel_panel.c | 52 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 1007 ++++--- drivers/gpu/drm/i915/intel_ringbuffer.h | 136 +- drivers/gpu/drm/i915/intel_sdvo.c | 7 +- drivers/gpu/drm/i915/intel_tv.c | 14 +- drivers/gpu/drm/nouveau/Kconfig | 2 +- drivers/gpu/drm/nouveau/Makefile | 17 +- drivers/gpu/drm/nouveau/nouveau_acpi.c | 11 +- drivers/gpu/drm/nouveau/nouveau_bios.c | 102 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 319 ++- drivers/gpu/drm/nouveau/nouveau_channel.c | 383 ++-- drivers/gpu/drm/nouveau/nouveau_connector.c | 54 +- drivers/gpu/drm/nouveau/nouveau_display.c | 207 ++ drivers/gpu/drm/nouveau/nouveau_dma.c | 32 +- drivers/gpu/drm/nouveau/nouveau_dma.h | 9 +- drivers/gpu/drm/nouveau/nouveau_dp.c | 6 +- drivers/gpu/drm/nouveau/nouveau_drv.c | 58 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 425 ++- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 189 +- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 18 +- drivers/gpu/drm/nouveau/nouveau_fence.c | 117 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 171 +- drivers/gpu/drm/nouveau/nouveau_hw.c | 11 +- drivers/gpu/drm/nouveau/nouveau_irq.c | 1210 +-------- drivers/gpu/drm/nouveau/nouveau_mem.c | 426 ++-- drivers/gpu/drm/nouveau/nouveau_mm.c | 271 ++ drivers/gpu/drm/nouveau/nouveau_mm.h | 67 + drivers/gpu/drm/nouveau/nouveau_notifier.c | 44 +- drivers/gpu/drm/nouveau/nouveau_object.c | 754 +++--- drivers/gpu/drm/nouveau/nouveau_pm.c | 33 +- drivers/gpu/drm/nouveau/nouveau_ramht.c | 11 +- drivers/gpu/drm/nouveau/nouveau_ramht.h | 2 +- drivers/gpu/drm/nouveau/nouveau_reg.h | 75 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 212 +- drivers/gpu/drm/nouveau/nouveau_state.c | 300 ++- drivers/gpu/drm/nouveau/nouveau_util.c | 69 + drivers/gpu/drm/nouveau/nouveau_util.h | 45 + drivers/gpu/drm/nouveau/nouveau_vm.c | 439 +++ drivers/gpu/drm/nouveau/nouveau_vm.h | 113 + drivers/gpu/drm/nouveau/nv04_crtc.c | 8 +- drivers/gpu/drm/nouveau/nv04_dac.c | 12 +- drivers/gpu/drm/nouveau/nv04_display.c | 21 + drivers/gpu/drm/nouveau/nv04_fbcon.c | 102 +- drivers/gpu/drm/nouveau/nv04_fifo.c | 240 ++- drivers/gpu/drm/nouveau/nv04_graph.c | 645 +++-- drivers/gpu/drm/nouveau/nv04_instmem.c | 50 +- drivers/gpu/drm/nouveau/nv10_fb.c | 124 +- drivers/gpu/drm/nouveau/nv10_fifo.c | 19 +- drivers/gpu/drm/nouveau/nv10_graph.c | 203 +- drivers/gpu/drm/nouveau/nv20_graph.c | 244 ++- drivers/gpu/drm/nouveau/nv30_fb.c | 23 +- drivers/gpu/drm/nouveau/nv40_fb.c | 22 +- drivers/gpu/drm/nouveau/nv40_fifo.c | 20 +- drivers/gpu/drm/nouveau/nv40_graph.c | 205 ++- drivers/gpu/drm/nouveau/nv50_crtc.c | 27 +- drivers/gpu/drm/nouveau/nv50_display.c | 422 +--- drivers/gpu/drm/nouveau/nv50_display.h | 2 - drivers/gpu/drm/nouveau/nv50_evo.c | 345 +++ drivers/gpu/drm/nouveau/nv50_evo.h | 10 + drivers/gpu/drm/nouveau/nv50_fb.c | 71 +- drivers/gpu/drm/nouveau/nv50_fbcon.c | 114 +- drivers/gpu/drm/nouveau/nv50_fifo.c | 42 +- drivers/gpu/drm/nouveau/nv50_gpio.c | 198 ++- drivers/gpu/drm/nouveau/nv50_graph.c | 677 +++++- drivers/gpu/drm/nouveau/nv50_instmem.c | 375 ++-- drivers/gpu/drm/nouveau/nv50_vm.c | 180 ++ drivers/gpu/drm/nouveau/nv50_vram.c | 190 ++ drivers/gpu/drm/nouveau/nv84_crypt.c | 140 + drivers/gpu/drm/nouveau/nvc0_fbcon.c | 269 ++ drivers/gpu/drm/nouveau/nvc0_fifo.c | 365 +++ drivers/gpu/drm/nouveau/nvc0_graph.c | 705 +++++- drivers/gpu/drm/nouveau/nvc0_graph.h | 64 + drivers/gpu/drm/nouveau/nvc0_grctx.c | 2874 ++++++++++++++++++++ drivers/gpu/drm/nouveau/nvc0_instmem.c | 317 ++-- drivers/gpu/drm/nouveau/nvc0_vm.c | 123 + drivers/gpu/drm/nouveau/nvc0_vram.c | 99 + drivers/gpu/drm/nouveau/nvreg.h | 3 +- drivers/gpu/drm/radeon/Makefile | 5 +- drivers/gpu/drm/radeon/ObjectID.h | 48 + drivers/gpu/drm/radeon/atom.c | 14 +- drivers/gpu/drm/radeon/atombios.h | 997 +++++++- drivers/gpu/drm/radeon/atombios_crtc.c | 57 +- drivers/gpu/drm/radeon/evergreen.c | 806 +++++-- drivers/gpu/drm/radeon/evergreen_blit_kms.c | 92 +- drivers/gpu/drm/radeon/evergreen_reg.h | 6 + drivers/gpu/drm/radeon/evergreend.h | 53 +- drivers/gpu/drm/radeon/ni.c | 316 +++ drivers/gpu/drm/radeon/ni_reg.h | 86 + drivers/gpu/drm/radeon/nid.h | 41 + drivers/gpu/drm/radeon/r100.c | 78 +- drivers/gpu/drm/radeon/r100d.h | 2 +- drivers/gpu/drm/radeon/r300.c | 21 +- drivers/gpu/drm/radeon/r300d.h | 1 + drivers/gpu/drm/radeon/r500_reg.h | 4 + drivers/gpu/drm/radeon/r600.c | 357 ++- drivers/gpu/drm/radeon/r600d.h | 48 + drivers/gpu/drm/radeon/radeon.h | 151 +- drivers/gpu/drm/radeon/radeon_asic.c | 153 +- drivers/gpu/drm/radeon/radeon_asic.h | 65 +- drivers/gpu/drm/radeon/radeon_atombios.c | 1246 ++++++---- drivers/gpu/drm/radeon/radeon_bios.c | 41 + drivers/gpu/drm/radeon/radeon_combios.c | 3 +- drivers/gpu/drm/radeon/radeon_connectors.c | 9 +- drivers/gpu/drm/radeon/radeon_cs.c | 17 +- drivers/gpu/drm/radeon/radeon_device.c | 35 +- drivers/gpu/drm/radeon/radeon_display.c | 391 +++- drivers/gpu/drm/radeon/radeon_drv.c | 11 +- drivers/gpu/drm/radeon/radeon_encoders.c | 205 ++- drivers/gpu/drm/radeon/radeon_family.h | 4 + drivers/gpu/drm/radeon/radeon_fb.c | 4 - drivers/gpu/drm/radeon/radeon_fence.c | 4 + drivers/gpu/drm/radeon/radeon_irq_kms.c | 46 +- drivers/gpu/drm/radeon/radeon_kms.c | 64 +- drivers/gpu/drm/radeon/radeon_mode.h | 16 +- drivers/gpu/drm/radeon/radeon_object.c | 57 +- drivers/gpu/drm/radeon/radeon_object.h | 7 +- drivers/gpu/drm/radeon/radeon_pm.c | 94 +- drivers/gpu/drm/radeon/radeon_reg.h | 13 + drivers/gpu/drm/radeon/radeon_trace.h | 82 + drivers/gpu/drm/radeon/radeon_trace_points.c | 9 + drivers/gpu/drm/radeon/reg_srcs/rv515 | 16 + drivers/gpu/drm/radeon/rs600.c | 118 +- drivers/gpu/drm/radeon/rv770.c | 196 ++- drivers/gpu/drm/radeon/rv770d.h | 47 + drivers/gpu/drm/ttm/ttm_bo.c | 156 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 138 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 29 +- drivers/gpu/drm/ttm/ttm_execbuf_util.c | 169 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 3 - drivers/gpu/vga/vga_switcheroo.c | 78 +- include/drm/drmP.h | 102 +- include/drm/drm_crtc.h | 9 + include/drm/drm_fb_helper.h | 3 - include/drm/drm_mm.h | 7 + include/drm/drm_pciids.h | 40 + include/drm/i915_drm.h | 12 + include/drm/intel-gtt.h | 35 +- include/drm/nouveau_drm.h | 5 +- include/drm/radeon_drm.h | 1 + include/drm/ttm/ttm_bo_api.h | 50 +- include/drm/ttm/ttm_bo_driver.h | 152 +- include/drm/ttm/ttm_execbuf_util.h | 11 +- include/linux/agp_backend.h | 2 - include/linux/intel-gtt.h | 20 - include/linux/kref.h | 2 + include/linux/vga_switcheroo.h | 2 + lib/kref.c | 30 + 187 files changed, 24781 insertions(+), 10722 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_gem_execbuffer.c create mode 100644 drivers/gpu/drm/i915/i915_gem_gtt.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_mm.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_mm.h create mode 100644 drivers/gpu/drm/nouveau/nouveau_util.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_util.h create mode 100644 drivers/gpu/drm/nouveau/nouveau_vm.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_vm.h create mode 100644 drivers/gpu/drm/nouveau/nv50_evo.c create mode 100644 drivers/gpu/drm/nouveau/nv50_vm.c create mode 100644 drivers/gpu/drm/nouveau/nv50_vram.c create mode 100644 drivers/gpu/drm/nouveau/nv84_crypt.c create mode 100644 drivers/gpu/drm/nouveau/nvc0_fbcon.c create mode 100644 drivers/gpu/drm/nouveau/nvc0_graph.h create mode 100644 drivers/gpu/drm/nouveau/nvc0_grctx.c create mode 100644 drivers/gpu/drm/nouveau/nvc0_vm.c create mode 100644 drivers/gpu/drm/nouveau/nvc0_vram.c create mode 100644 drivers/gpu/drm/radeon/ni.c create mode 100644 drivers/gpu/drm/radeon/ni_reg.h create mode 100644 drivers/gpu/drm/radeon/nid.h create mode 100644 drivers/gpu/drm/radeon/radeon_trace.h create mode 100644 drivers/gpu/drm/radeon/radeon_trace_points.c delete mode 100644 include/linux/intel-gtt.h
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airlied@linux.ie wrote:
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
I get millions of messages like:
... [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 30938, at 30938], missed IRQ? [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31068, at 31068], missed IRQ? [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31129, at 31129], missed IRQ? ...
and everything is very choppy. I assume it's the power saving thing that broke again, but that's just a total random guess, I have nothing to actually back that up with.
It worked fine after boot, but those problems began at 8287.139375 (about two hours after boot - it may have coincided with screen saver, but who knows?) and have been happening constantly since. The machine is not really usable, I'm writing this with annoying 2-second pauses every once in a while.
This is a regular Core i5-670 with up-to-date Fedora-14, fwiw. Not my sandybridge.
Linus
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airlied@linux.ie wrote:
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
I get millions of messages like:
... [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 30938, at 30938], missed IRQ? [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31068, at 31068], missed IRQ? [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31129, at 31129], missed IRQ? ...
and everything is very choppy. I assume it's the power saving thing that broke again, but that's just a total random guess, I have nothing to actually back that up with.
It worked fine after boot, but those problems began at 8287.139375 (about two hours after boot - it may have coincided with screen saver, but who knows?) and have been happening constantly since. The machine is not really usable, I'm writing this with annoying 2-second pauses every once in a while.
Okay I'll try and reproduce and curse Chris and Jesse, does booting with i915.powersave=0 help any?
Dave.
On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie airlied@gmail.com wrote:
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airlied@linux.ie wrote:
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
I get millions of messages like:
... [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 30938, at 30938], missed IRQ? [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31068, at 31068], missed IRQ? [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31129, at 31129], missed IRQ? ...
and everything is very choppy. I assume it's the power saving thing that broke again, but that's just a total random guess, I have nothing to actually back that up with.
It worked fine after boot, but those problems began at 8287.139375 (about two hours after boot - it may have coincided with screen saver, but who knows?) and have been happening constantly since. The machine is not really usable, I'm writing this with annoying 2-second pauses every once in a while.
Okay I'll try and reproduce and curse Chris and Jesse, does booting with i915.powersave=0 help any?
I've also noticed Chris has some more patches in drm-intel-next I haven't got in this pull request.
I don't think he's sent me a pull request though so not telling how stable they are.
Dave.
On Tue, 11 Jan 2011 14:51:40 +1000, Dave Airlie airlied@gmail.com wrote:
On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie airlied@gmail.com wrote:
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airlied@linux.ie wrote:
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
I get millions of messages like:
... [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 30938, at 30938], missed IRQ? [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31068, at 31068], missed IRQ? [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31129, at 31129], missed IRQ? ...
and everything is very choppy. I assume it's the power saving thing that broke again, but that's just a total random guess, I have nothing to actually back that up with.
It worked fine after boot, but those problems began at 8287.139375 (about two hours after boot - it may have coincided with screen saver, but who knows?) and have been happening constantly since. The machine is not really usable, I'm writing this with annoying 2-second pauses every once in a while.
Okay I'll try and reproduce and curse Chris and Jesse, does booting with i915.powersave=0 help any?
I've also noticed Chris has some more patches in drm-intel-next I haven't got in this pull request.
I don't think he's sent me a pull request though so not telling how stable they are.
Yes, there are a few pending fixes. I've been waiting on feedback from testing for some more before asking for a pull. In part because we have some more eDP fixes, courtesy of Jesse, that makes everyone but Jim Getty happy.
However, I've not seen anything like this so I doubt that d-i-n contains the fix.
Dave, is yours related to the DMAR errors that is plaguing your systems?
Linus, is anything else kicked off upon powersaving? A screen saver or is it just the blanking that triggers the mess? -Chris
"Dave Airlie" airlied@gmail.com wrote:
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airlied@linux.ie
wrote:
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
I get millions of messages like:
... [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 30938, at 30938],
missed
IRQ? [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31068, at 31068],
missed
IRQ? [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31129, at 31129],
missed
IRQ? ...
and everything is very choppy. I assume it's the power saving thing that broke again, but that's just a total random guess, I have
nothing
to actually back that up with.
It worked fine after boot, but those problems began at 8287.139375 (about two hours after boot - it may have coincided with screen
saver,
but who knows?) and have been happening constantly since. The
machine
is not really usable, I'm writing this with annoying 2-second pauses every once in a while.
Okay I'll try and reproduce and curse Chris and Jesse, does booting with i915.powersave=0 help any?
Dave.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
Thanks, -- Jesse Barnes, Intel Open Source Technology Center
On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
"Dave Airlie" airlied@gmail.com wrote:
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airlied@linux.ie
wrote:
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
I get millions of messages like:
... [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 30938, at 30938],
missed
IRQ? [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31068, at 31068],
missed
IRQ? [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31129, at 31129],
missed
IRQ? ...
and everything is very choppy. I assume it's the power saving thing that broke again, but that's just a total random guess, I have
nothing
to actually back that up with.
It worked fine after boot, but those problems began at 8287.139375 (about two hours after boot - it may have coincided with screen
saver,
but who knows?) and have been happening constantly since. The
machine
is not really usable, I'm writing this with annoying 2-second pauses every once in a while.
Okay I'll try and reproduce and curse Chris and Jesse, does booting with i915.powersave=0 help any?
Dave.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
I think he'd fixed them in the tree I pulled locally to test, I'm guessing this might be that we are running the Fedora userspace driver and you guys are all on master or something, which would mean some ABI guarantee got busted.
I'm going to try a local test upgrade to 2.14.0 just to see.
Dave.
On Tue, Jan 11, 2011 at 4:28 PM, Dave Airlie airlied@gmail.com wrote:
On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
"Dave Airlie" airlied@gmail.com wrote:
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airlied@linux.ie
wrote:
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
I get millions of messages like:
... [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 30938, at 30938],
missed
IRQ? [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31068, at 31068],
missed
IRQ? [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 31129, at 31129],
missed
IRQ? ...
and everything is very choppy. I assume it's the power saving thing that broke again, but that's just a total random guess, I have
nothing
to actually back that up with.
It worked fine after boot, but those problems began at 8287.139375 (about two hours after boot - it may have coincided with screen
saver,
but who knows?) and have been happening constantly since. The
machine
is not really usable, I'm writing this with annoying 2-second pauses every once in a while.
Okay I'll try and reproduce and curse Chris and Jesse, does booting with i915.powersave=0 help any?
Dave.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
I think he'd fixed them in the tree I pulled locally to test, I'm guessing this might be that we are running the Fedora userspace driver and you guys are all on master or something, which would mean some ABI guarantee got busted.
I'm going to try a local test upgrade to 2.14.0 just to see.
Okay that didn't help, dead in similar times, evince with a few flood maps from Brisbane seem to be a good trigger.
I'm not sure I'll be in a good place for bisection, need laptop to keep track of disaster.
Dave.
With kernel 2.6.37-git5, my PC hangs. ( I have an nvidia 8800GT and nouveau )
Foto attached.
Hi!
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
Heh, at this point I expected Linus to complain about milion merges in changelog...
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
Watermarking code? What goes on there? Pavel
On Tue, 11 Jan 2011 14:33:29 +0100, Pavel Machek pavel@ucw.cz wrote:
Hi!
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
Heh, at this point I expected Linus to complain about milion merges in changelog...
Applying bug fixes to one tree and pushing those to 2.6.37 and doing feature work in another which also depend upon those same bug fixes... The merges I felt were fairly infrequent, either after a pull request and subsequent fast-forward of -fixes (so that -next was always a superset of the current upstream rc) or I applied a patch to -fixes that would conflict with -next. After those, I did an immediate merge to resolve the conflict whilst the code was still fresh.
The whole point of trying to keep two trees intact is to be able to perform continuous testing on both. No matter how hard I try not to, it seems I always break Linus's machine.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
Watermarking code? What goes on there?
FIFO watermarks, they determine when the display fetches from the scanout buffer to fill the pipe. If we run out of FIFO entries then the display flickers at best, at worst we may hard hang the machine. -Chris
Hi!
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
Lowlights: it's broken.
Heh, at this point I expected Linus to complain about milion merges in changelog...
(Ok, I chould have put a smiley there :-).
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
Watermarking code? What goes on there?
FIFO watermarks, they determine when the display fetches from the scanout buffer to fill the pipe. If we run out of FIFO entries then the display flickers at best, at worst we may hard hang the machine.
Thanks for info. I was afraid it was trying to do some watermarks on video signal, to catch evil videotapers or something like that...
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
There's no way to bisect this thing - it started happening after 2 hours (first message at 8287.139375 seconds from boot, to be exact). So far only once, but that's possibly because I've been asleep for the last eight hours ;)
But yes, it worked before pulling Dave's tree, IOW, I haven't seen this message on this machine before.
And as mentioned, this is a regular machine, not one of my preproduction things that tend to have odd silicon or BIOSes. Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest part of that machine is the silent case ;)
Chris wrote:
Linus, is anything else kicked off upon powersaving? A screen saver or is it just the blanking that triggers the mess?
So I don't _know_ that it was the screen saver that triggered, but I do know that it started happening while I was out to pick up a kid from gymnastics. So the screen saver was pretty much the only thing going on apart from an idle desktop with a few terminals and chrome.
And it's not even a 3D screen saver or anything graphically fancy, it's just the "show random photos" one (it eventually does blank too, but I think I've set the blanking interval to an hour or something). But compiz was on.
Linus
On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Arg. It's been ok on my ILK systems, but Chris has found some issues with out watermarking code iirc; apparently we're underflowing the display FIFO, causing all sorts of trouble. If it works before the pull of Dave's tree, can you bisect?
There's no way to bisect this thing - it started happening after 2 hours (first message at 8287.139375 seconds from boot, to be exact). So far only once, but that's possibly because I've been asleep for the last eight hours ;)
But yes, it worked before pulling Dave's tree, IOW, I haven't seen this message on this machine before.
And as mentioned, this is a regular machine, not one of my preproduction things that tend to have odd silicon or BIOSes. Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest part of that machine is the silent case ;)
Chris wrote:
Linus, is anything else kicked off upon powersaving? A screen saver or is it just the blanking that triggers the mess?
So I don't _know_ that it was the screen saver that triggered, but I do know that it started happening while I was out to pick up a kid from gymnastics. So the screen saver was pretty much the only thing going on apart from an idle desktop with a few terminals and chrome.
And it's not even a 3D screen saver or anything graphically fancy, it's just the "show random photos" one (it eventually does blank too, but I think I've set the blanking interval to an hour or something). But compiz was on.
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/
Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait until is more stable ?
On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel anca.emanuel@gmail.com wrote:
Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait until is more stable ?
What I have done: git bisect log git bisect start # bad: [5b2eef966cb2ae307aa4ef1767f7307774bc96ca] Merge branch 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 git bisect bad 5b2eef966cb2ae307aa4ef1767f7307774bc96ca # good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37 git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5 # good: [c413521eb4e2d7ffd5ce432a144708d479054bd3] ARM: mach-shmobile: update for SMP changes. git bisect good c413521eb4e2d7ffd5ce432a144708d479054bd3 # bad: [78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 git bisect bad 78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252 # bad: [da40d036fd716f0efb2917076220814b1e927ae1] Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 git bisect bad da40d036fd716f0efb2917076220814b1e927ae1 # bad: [dc69d1af9e8d9cbbabff88bb35a6782187a22229] omap2: Make OMAP2PLUS select OMAP_DM_TIMER git bisect bad dc69d1af9e8d9cbbabff88bb35a6782187a22229
Second bisect bad: nouveau not loaded, but I have an usable system. I don't feel I'm doing it right.
Dave, in the future, can you make pull requests like Ingo ? What I mean: non-drm generic power nouveau radeon intel others
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
But yes, it worked before pulling Dave's tree, IOW, I haven't seen this message on this machine before.
.. and it's not a fluke. It happened again, and once more while I was away from the machine and the screen saver was running. So it does seem to have something to do with power-saving modes or something.
Linus
On Tue, 11 Jan 2011 11:00:13 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
But yes, it worked before pulling Dave's tree, IOW, I haven't seen this message on this machine before.
.. and it's not a fluke. It happened again, and once more while I was away from the machine and the screen saver was running. So it does seem to have something to do with power-saving modes or something.
Have you tried reproducing it using xset dpms force off or similar?
Chris, what are you using to trigger the watermark related issues you've found?
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went black - just the random photo thing was on. But no, forcing the screen saver on doesn't do it either (ie pressing the "lock screen" icon and waiting for a few pictures to cycle).
Maybe the screen just has to be inactive for a longer time: do you do some dynamic "let's power things down if nothing is changing"?
Linus
On Tue, 11 Jan 2011 11:25:39 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went black - just the random photo thing was on. But no, forcing the screen saver on doesn't do it either (ie pressing the "lock screen" icon and waiting for a few pictures to cycle).
Maybe the screen just has to be inactive for a longer time: do you do some dynamic "let's power things down if nothing is changing"?
There are some timeouts, the FBC engine will recompress about once every 15s; the self-refresh timers are much smaller though so it should be active anytime the CPU enters a deep sleep state. The clock frequency changes in millisecond time too, you can check the status of that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.
I wonder if re-enabling rc6 may have caused your issues? That would be:
commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Jan 5 12:01:24 2011 -0800
drm/i915: re-enable rc6 support for Ironlake+
On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Maybe the screen just has to be inactive for a longer time: do you do some dynamic "let's power things down if nothing is changing"?
There are some timeouts, the FBC engine will recompress about once every 15s; the self-refresh timers are much smaller though so it should be active anytime the CPU enters a deep sleep state. The clock frequency changes in millisecond time too, you can check the status of that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.
I assume you meant "info", not "status". If so, that doesn't look all that interesting:
[torvalds@i5 linux]$ cat /sys/kernel/debug/dri/0/i915_drpc_info HD boost: no Boost freq: 0 HW control enabled: no SW control enabled: no Gated voltage change: no Starting frequency: P0 Max P-state: P0 Min P-state: P0 RS1 VID: 0 RS2 VID: 38 Render standby enabled: yes [torvalds@i5 linux]$ cat /sys/kernel/debug/dri/0/i915_cur_delayinfo Requested P-state: 0 Requested VID: 0 Current VID: 37 Current P-state: 0
(This is in the "working state" - I rebooted because I can't stand working with a machine that feels like a 110baud terminal).
I wonder if re-enabling rc6 may have caused your issues? That would be:
commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
I don't have this commit at all, it wasn't part of the merged series.
Linus
On Tue, 11 Jan 2011 11:45:05 -0800, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Tue, 11 Jan 2011 11:25:39 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went black - just the random photo thing was on. But no, forcing the screen saver on doesn't do it either (ie pressing the "lock screen" icon and waiting for a few pictures to cycle).
Maybe the screen just has to be inactive for a longer time: do you do some dynamic "let's power things down if nothing is changing"?
There are some timeouts, the FBC engine will recompress about once every 15s; the self-refresh timers are much smaller though so it should be active anytime the CPU enters a deep sleep state. The clock frequency changes in millisecond time too, you can check the status of that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.
I wonder if re-enabling rc6 may have caused your issues? That would be:
commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Jan 5 12:01:24 2011 -0800
drm/i915: re-enable rc6 support for Ironlake+
We haven't actually got as far as that patch yet, that's waiting for a suitable juncture to send the request. Now that the trees have converged I can pick which patches need to go for rc1 and which can wait for -next.
Looking at the set of outstanding patch, my suspect would be the ring irq refcounting which needed a fix and seems implicated by the error message. -Chris
On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
Maybe the screen just has to be inactive for a longer time: do you do some dynamic "let's power things down if nothing is changing"?
So since this is _almost_ reproducible for me, I tried bisecting it.
The bisection is a bit iffy, since it's not entirely clear how long I need to wait for the screen saver to cause the problem, but sine I hit a very similar issue while bisecting, I think it's a pretty solid (partial) bisect.
What _seems_ to go on is that after commit b5ba177d8d71 ("drm/i915: Poll for seqno completion if IRQ is disabled") I get that "very chunky behavior". And _before_ that commit I actually get a BUG_ON(), and in fact that bug-on does not happen during normal use, but does trigger when the screen saver runs. So I think the old BUG_ON() is actually the exact same case that then causes the jerky problem for me.
NOTE! I didn't do a full bisect. I did verify that commit b5ba177d8d71 does expose the bad behavior, and I also verified that a few commits before that gets the BUG_ON, but there's something like three or four commits in between that I didn't test. But we're literally talking just three commits or so (eg commit 8d5203ca6253 gets that BUG_ON(), and 71f4566084eb is marked as "good" too for me, so the only untested commits are 9097eef024db and b13c2b96bf15).
I'll test the merge, but I thought I'd send out this note already at this point, because I'm pretty sure this is it.
The BUG_ON() that triggers is appended. And as mentioned, the jerky thing really seems to start happening in the exact same circumstance when this BUG_ON triggered.
Linus
--- [ 330.023447] ------------[ cut here ]------------ [ 330.025136] kernel BUG at drivers/gpu/drm/i915/intel_ringbuffer.c:354! [ 330.026758] invalid opcode: 0000 [#1] PREEMPT SMP [ 330.028396] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map [ 330.030040] CPU 2 [ 330.030049] Modules linked in: [last unloaded: scsi_wait_scan] [ 330.033313] [ 330.034929] Pid: 2723, comm: Xorg Not tainted 2.6.37-rc4-00295-g0cdab21 #16 P7H57D-V EVO/System Product Name [ 330.036581] RIP: 0010:[<ffffffff812f1cbd>] [<ffffffff812f1cbd>] render_ring_put_irq+0x20/0x88 [ 330.038266] RSP: 0018:ffff88023e001cf8 EFLAGS: 00010246 [ 330.039937] RAX: 0000000000000000 RBX: ffff88023fcdc030 RCX: 0000000000000000 [ 330.041607] RDX: 0000000000003736 RSI: 0000000000000001 RDI: ffff88023fcdc030 [ 330.043277] RBP: ffff88023e001d18 R08: ffff88023fcdd84c R09: 0000000000000000 [ 330.044917] R10: ffff88023e001cb8 R11: ffff88023e001cc8 R12: ffff88023fcdc000 [ 330.046571] R13: ffff88023ff69000 R14: ffff88023fcdd84c R15: ffff88023fcdc118 [ 330.048193] FS: 00007fe1b6342860(0000) GS:ffff8800bd900000(0000) knlGS:0000000000000000 [ 330.049822] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 330.051450] CR2: 00007f4379961000 CR3: 0000000229d41000 CR4: 00000000000006e0 [ 330.053088] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 330.054726] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 330.056364] Process Xorg (pid: 2723, threadinfo ffff88023e000000, task ffff880229db2c40) [ 330.057991] Stack: [ 330.059610] ffff88023fcdc030 ffff88023fcdc000 00000000000026b7 ffff88023fcdd84c [ 330.061255] ffff88023e001d98 ffffffff812da704 ffff88023e001e18 ffff880200000000 [ 330.062908] 0000000000000000 ffff880229db2c40 ffffffff81051e35 ffff88023e001d50 [ 330.064566] Call Trace: [ 330.066202] [<ffffffff812da704>] i915_gem_throttle_ioctl+0x163/0x1ac [ 330.067863] [<ffffffff81051e35>] ? autoremove_wake_function+0x0/0x34 [ 330.069510] [<ffffffff812ba08f>] drm_ioctl+0x290/0x35c [ 330.071136] [<ffffffff81054f24>] ? lock_hrtimer_base.clone.29+0x24/0x48 [ 330.072769] [<ffffffff812da5a1>] ? i915_gem_throttle_ioctl+0x0/0x1ac [ 330.074397] [<ffffffff81054f24>] ? lock_hrtimer_base.clone.29+0x24/0x48 [ 330.076025] [<ffffffff8153c02c>] ? _raw_spin_unlock_irq+0x2b/0x53 [ 330.077651] [<ffffffff810d2ed9>] do_vfs_ioctl+0x4c1/0x502 [ 330.079252] [<ffffffff810c56cd>] ? fget_light+0x13a/0x31a [ 330.080845] [<ffffffff8100202c>] ? sysret_check+0x27/0x62 [ 330.082416] [<ffffffff810d2f6b>] sys_ioctl+0x51/0x76 [ 330.083964] [<ffffffff81001ffb>] system_call_fastpath+0x16/0x1b [ 330.085501] Code: d7 f3 ab 5b 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 56 41 55 41 54 53 4c 8b 6f 18 41 83 bd e0 02 00 00 00 74 66 8b 47 60 85 c0 75 02 <0f> 0b ff c8 89 47 60 85 c0 75 54 49 8b 9d 98 05 00 00 4c 8d a3 [ 330.087351] RIP [<ffffffff812f1cbd>] render_ring_put_irq+0x20/0x88 [ 330.089039] RSP <ffff88023e001cf8> [ 330.099760] ---[ end trace acfb1e4669bf8ace ]--- [ 330.376659] [drm:drm_release] *ERROR* Device busy: 1
On Tue, 11 Jan 2011 14:16:54 -0800, Linus Torvalds torvalds@linux-foundation.org wrote:
The BUG_ON() that triggers is appended. And as mentioned, the jerky thing really seems to start happening in the exact same circumstance when this BUG_ON triggered.
Yes, that is the race in IRQ refcounting that I have an outstanding fix for.
I've put the patches up on drm-intel-staging as I begin retesting them before sending the pull request. In particular you need 01a03331e5fe91861937f8b8e72c259f5e9eae67. -Chris
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
I'll test the merge, but I thought I'd send out this note already at this point, because I'm pretty sure this is it.
Hmm. The merge already has the *ERROR* Hangcheck (together with jerky behavior), so it wasn't actually the polling patch that turned the BUG_ON() into a jerky experience. But I'll test that drm-intel-staging commit.
Linus
On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
... I'll test that drm-intel-staging commit.
Initial testing _seems_ to confirm that merging drm-intel-staging gets rid of the problem. But I haven't spent a whole lot of time in the screen saver. Will start driving kids around now, so more intense screen saver testing is coming up..
Linus
On Wed, Jan 12, 2011 at 11:36 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
... I'll test that drm-intel-staging commit.
Initial testing _seems_ to confirm that merging drm-intel-staging gets rid of the problem. But I haven't spent a whole lot of time in the screen saver. Will start driving kids around now, so more intense screen saver testing is coming up..
Its looking good here, I've pushed a drm-fixes branch with what Chris sent me + a couple of i915/iommu fixes to my repo,
I'm going to run it on my laptop for a few more hours then I'll send you a pull req, but none of the triggers I had yesterday seem to take it down.
Dave.
Linus
Am 10.01.2011 23:59, schrieb Dave Airlie:
Hi Linus,
non-drm changes: one kref change we needed that went on list with no comments
New hardware: radeon: add support for Fusion APUs and Radeon HD6xxx chipsets nouveau: Fermi acceleration support (requires external fw for now)
Highlights: core/drivers: add support for high precision vblank timestamps radeon: pageflipping support, Gen2 PCIE support nouveau: reworked VRAM and VM support intel: better ILK/SNB powersaving support, Full GTT support
There are also some switcheroo patches to further improve it, though I have a later patch blocking on an x86 platform driver for the nvidia/intel switcher.
Dave.
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
$ dmesg | grep drm [ 0.520906] [drm] Initialized drm 1.1.0 20060810 [ 0.521200] [drm] radeon defaulting to kernel modesetting. [ 0.521416] [drm] radeon kernel modesetting enabled. [ 0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [ 0.536664] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x084c00a2) [ 0.556998] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN [ 0.641884] [drm] nouveau 0000:01:00.0: ... appears to be valid [ 0.642058] [drm] nouveau 0000:01:00.0: BIT BIOS found [ 0.642227] [drm] nouveau 0000:01:00.0: Bios version 60.84.51.00 [ 0.642400] [drm] nouveau 0000:01:00.0: TMDS table version 2.0 [ 0.642567] [drm] nouveau 0000:01:00.0: BIT table 'd' not found [ 0.642736] [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0 [ 0.642969] [drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000323 00010034 [ 0.643141] [drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02811300 00000028 [ 0.643315] [drm] nouveau 0000:01:00.0: Raw DCB entry 2: 02822312 00010030 [ 0.643490] [drm] nouveau 0000:01:00.0: Raw DCB entry 3: 0000000e 00000000 [ 0.643662] [drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 14 2 [ 0.643836] [drm] nouveau 0000:01:00.0: 0: 0x00000040: type 0x40 idx 0 tag 0xff [ 0.644089] [drm] nouveau 0000:01:00.0: 1: 0x00000100: type 0x00 idx 1 tag 0xff [ 0.644317] [drm] nouveau 0000:01:00.0: 2: 0x00001231: type 0x31 idx 2 tag 0x07 [ 0.644543] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [ 0.688140] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [ 0.724028] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [ 0.724264] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [ 0.732117] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [ 0.732345] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xEFDF [ 0.756029] [drm] nouveau 0000:01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [ 0.775483] [drm] nouveau 0000:01:00.0: 3 available performance level(s) [ 0.775663] [drm] nouveau 0000:01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [ 0.775900] [drm] nouveau 0000:01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [ 0.776165] [drm] nouveau 0000:01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [ 0.776419] [drm] nouveau 0000:01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [ 0.777232] [drm] nouveau 0000:01:00.0: Detected 256MiB VRAM [ 0.817893] [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture) [ 0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 0.889565] [drm] No driver support for vblank timestamp query. [ 0.904293] [drm] nouveau 0000:01:00.0: ACPI backlight interface available, not registering our own [ 1.071762] [drm] nouveau 0000:01:00.0: allocated 1920x1200 fb: 0x60000000, bo ffff88013af63400 [ 1.071842] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 1.071866] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP1: Unhandled ustatus 0x00000001 [ 1.071871] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 1.071881] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x060c data 0x000004b0 [ 1.086542] drm: registered panic notifier [ 1.086564] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0 [ 32.672642] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672651] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP1: Unhandled ustatus 0x00000001 [ 32.672653] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672656] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672670] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672672] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672675] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x0000c676 [ 32.672688] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672691] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672693] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672706] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672709] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672711] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672724] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672727] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672729] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0814 data 0x00000000 [ 32.672742] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672745] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672747] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x6cc61800 [ 32.672760] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672763] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672765] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672777] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672780] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672782] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672795] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672798] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672800] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672813] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672816] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672818] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672831] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672834] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672836] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672849] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672852] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672854] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672867] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672870] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672872] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x18cc0030 [ 32.672885] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672888] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672890] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672903] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672905] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672907] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672920] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672923] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672925] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672938] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672941] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672943] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x7c306000 [ 32.672956] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672959] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672961] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672974] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672977] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672979] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 32.672992] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 32.672994] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 32.672996] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 292.805813] [drm] nouveau 0000:01:00.0: Disabling fbcon acceleration... [ 292.805815] [drm] nouveau 0000:01:00.0: Unpinning framebuffer(s)... [ 292.805868] [drm] nouveau 0000:01:00.0: Evicting buffers... [ 292.894426] [drm] nouveau 0000:01:00.0: Idling channels... [ 292.894642] [drm] nouveau 0000:01:00.0: Suspending GPU objects... [ 294.215429] [drm] nouveau 0000:01:00.0: And we're gone! [ 295.977202] [drm] nouveau 0000:01:00.0: We're back, enabling device... [ 295.977249] [drm] nouveau 0000:01:00.0: POSTing device... [ 295.977251] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [ 296.020249] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [ 296.056123] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [ 296.056182] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [ 296.064227] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [ 296.064231] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xEFDF [ 296.088139] [drm] nouveau 0000:01:00.0: Restoring GPU objects... [ 296.200888] [drm] nouveau 0000:01:00.0: Reinitialising engines... [ 296.200957] [drm] nouveau 0000:01:00.0: Restoring mode... [ 296.400184] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 296.400189] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 296.400196] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 296.518972] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 296.518977] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 296.518981] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572687] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572690] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572694] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572717] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572719] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572722] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x66c66c00 [ 750.572744] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572747] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572749] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572771] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572774] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572776] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572798] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572801] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572803] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572821] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572824] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572826] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572848] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572850] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572852] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572875] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572877] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572879] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572901] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572904] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572906] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572924] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572927] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572929] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572951] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572954] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572956] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.572978] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.572981] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.572983] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.573005] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573008] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573010] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.573032] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573035] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573037] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.573056] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573058] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573061] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.573083] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573085] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573087] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.573109] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573112] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573114] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.573136] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573138] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573141] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x36cc00d6 [ 750.573163] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573165] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573167] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 750.573186] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 750.573188] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 750.573191] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 4433.086943] [drm] nouveau 0000:01:00.0: Disabling fbcon acceleration... [ 4433.086946] [drm] nouveau 0000:01:00.0: Unpinning framebuffer(s)... [ 4433.087018] [drm] nouveau 0000:01:00.0: Evicting buffers... [ 4433.136993] [drm] nouveau 0000:01:00.0: Idling channels... [ 4433.137214] [drm] nouveau 0000:01:00.0: Suspending GPU objects... [ 4434.544626] [drm] nouveau 0000:01:00.0: And we're gone! [ 4436.393123] [drm] nouveau 0000:01:00.0: We're back, enabling device... [ 4436.393171] [drm] nouveau 0000:01:00.0: POSTing device... [ 4436.393173] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [ 4436.436181] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [ 4436.472068] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [ 4436.472129] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [ 4436.480155] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [ 4436.480157] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xEFDF [ 4436.504063] [drm] nouveau 0000:01:00.0: Restoring GPU objects... [ 4436.618075] [drm] nouveau 0000:01:00.0: Reinitialising engines... [ 4436.618162] [drm] nouveau 0000:01:00.0: Restoring mode... [ 4436.816114] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 4436.816117] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 4436.816120] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 4436.939497] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 4436.939501] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 4436.939505] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 4659.547242] [drm] nouveau 0000:01:00.0: Disabling fbcon acceleration... [ 4659.547245] [drm] nouveau 0000:01:00.0: Unpinning framebuffer(s)... [ 4659.547291] [drm] nouveau 0000:01:00.0: Evicting buffers... [ 4659.574552] [drm] nouveau 0000:01:00.0: Idling channels... [ 4659.574772] [drm] nouveau 0000:01:00.0: Suspending GPU objects... [ 4660.983319] [drm] nouveau 0000:01:00.0: And we're gone! [ 4662.857200] [drm] nouveau 0000:01:00.0: We're back, enabling device... [ 4662.857247] [drm] nouveau 0000:01:00.0: POSTing device... [ 4662.857250] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [ 4662.900194] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [ 4662.936079] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [ 4662.936127] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [ 4662.944177] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [ 4662.944179] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xEFDF [ 4662.968079] [drm] nouveau 0000:01:00.0: Restoring GPU objects... [ 4663.081161] [drm] nouveau 0000:01:00.0: Reinitialising engines... [ 4663.081233] [drm] nouveau 0000:01:00.0: Restoring mode... [ 4663.280132] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 4663.280135] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 4663.280139] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 4663.404469] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 4663.404473] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 4663.404477] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 5972.191217] [drm] nouveau 0000:01:00.0: Disabling fbcon acceleration... [ 5972.191219] [drm] nouveau 0000:01:00.0: Unpinning framebuffer(s)... [ 5972.191276] [drm] nouveau 0000:01:00.0: Evicting buffers... [ 5972.237659] [drm] nouveau 0000:01:00.0: Idling channels... [ 5972.237877] [drm] nouveau 0000:01:00.0: Suspending GPU objects... [ 5973.560045] [drm] nouveau 0000:01:00.0: And we're gone! [ 5975.517189] [drm] nouveau 0000:01:00.0: We're back, enabling device... [ 5975.517237] [drm] nouveau 0000:01:00.0: POSTing device... [ 5975.517240] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [ 5975.560229] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [ 5975.596110] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [ 5975.596173] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [ 5975.604211] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [ 5975.604214] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xEFDF [ 5975.628116] [drm] nouveau 0000:01:00.0: Restoring GPU objects... [ 5975.741878] [drm] nouveau 0000:01:00.0: Reinitialising engines... [ 5975.741948] [drm] nouveau 0000:01:00.0: Restoring mode... [ 5975.940156] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 5975.940161] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 5975.940168] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 5976.122264] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 5976.122269] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 5976.122273] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061038] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061046] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061056] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061075] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061082] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061089] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x66c66c00 [ 7620.061109] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061115] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061122] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061141] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061147] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061154] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061173] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061179] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061186] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061205] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061211] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061218] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061237] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061243] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061250] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061269] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061275] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061282] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061301] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061307] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061314] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061333] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061339] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061345] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061365] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061371] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061377] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061396] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061402] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061409] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061429] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061434] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061441] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061460] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061466] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061473] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061492] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061498] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061505] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061524] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061530] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061537] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061556] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061562] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061568] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061587] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061593] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061600] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x36cc00d6 [ 7620.061619] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061625] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061632] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000 [ 7620.061651] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - TP0: Unhandled ustatus 0x00000001 [ 7620.061657] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP [ 7620.061664] [drm] nouveau 0000:01:00.0: PGRAPH - ch 1 (0x0000388000) subc 2 class 0x502d mthd 0x0860 data 0x00000000
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
It's a *bit* easier to do if you start out at the drm merge, and only bisect that part, ie
MERGE=5b2eef966cb2ae307aa4ef1767f7307774bc96ca git bisect start git bisect bad $MERGE^2 git bisect good $MERGE^1
(the above assumes that the merge itself isn't what caused the problems) and that way you should only need to bisect through the actual new DRM commits.
Linus
Am 12.01.2011 00:28, schrieb Linus Torvalds:
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons jsimmons@infradead.org Date: Thu Dec 23 16:40:37 2010 +0000
drm: Update fbdev fb_fix_screeninfo
Reverting this on top of todays git also fixes my problem.
Christian
Am 12.01.2011 00:28, schrieb Linus Torvalds:
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons jsimmons@infradead.org Date: Thu Dec 23 16:40:37 2010 +0000
drm: Update fbdev fb_fix_screeninfo
Reverting this on top of todays git also fixes my problem.
I see the problem. Nouveau for some hardware does a accelerated clearing of the screen before we register the framebuffer. The above patch does fix a real issue so please don't revert it. Can you try this patch.
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..4ef24d6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
+ info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : + FB_VISUAL_TRUECOLOR; drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
Am 12.01.2011 13:49, schrieb James Simmons:
I see the problem. Nouveau for some hardware does a accelerated clearing of the screen before we register the framebuffer. The above patch does fix a real issue so please don't revert it. Can you try this patch.
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..4ef24d6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
Hmm, does not seem to work. Any more initialization missing?
Am 12.01.2011 13:49, schrieb James Simmons:
I see the problem. Nouveau for some hardware does a accelerated clearing of the screen before we register the framebuffer. The above patch does fix a real issue so please don't revert it. Can you try this patch.
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..4ef24d6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
Hmm, does not seem to work. Any more initialization missing?
Okay. The nouveau driver also uses the pitch as well. It really should be using the pitch field from drm_framebuffer instead of the line_length from fb_fix_screeninfo. This patch is just to make sure this is the issue. I will submit another patch later that uses drm_fb_framebuffer's pitch field. As for the visual unfortunely their is no real mapping between drm and fbdev.
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..de3b067 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
+ info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : + FB_VISUAL_TRUECOLOR; + info->fix.line_length = fb->pitch; drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
Am 12.01.2011 14:32, schrieb James Simmons:
Okay. The nouveau driver also uses the pitch as well. It really should be using the pitch field from drm_framebuffer instead of the line_length from fb_fix_screeninfo. This patch is just to make sure this is the issue. I will submit another patch later that uses drm_fb_framebuffer's pitch field. As for the visual unfortunely their is no real mapping between drm and fbdev.
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..de3b067 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
info->fix.line_length = fb->pitch; drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
That fixes _my_ nouveau frame buffer regression.
On Wed, Jan 12, 2011 at 5:32 AM, James Simmons jsimmons@infradead.org wrote:
Okay. The nouveau driver also uses the pitch as well. It really should be using the pitch field from drm_framebuffer instead of the line_length from fb_fix_screeninfo. This patch is just to make sure this is the issue. I will submit another patch later that uses drm_fb_framebuffer's pitch field. As for the visual unfortunely their is no real mapping between drm and fbdev.
Why do you want to remove the drm_fb_helper_fill_fix() call? Quite frankly, you're then replacing it with open-coding the function partially:
- info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
- FB_VISUAL_TRUECOLOR;
- info->fix.line_length = fb->pitch;
drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
Which seems to be just a regression. Why not just call "drm_fb_helper_fill_fix()" here like we used to?
IOW, I'm inclined to just do the revert. The "fix" clearly breaks things, and now you're adding random parts of the function back rather than just calling the "fill_fix()" function like things used to. Why?
The commit message in dfe63bb0ad98 doesn't support any of these hacks - it just seems to say that drm_fb_helper_fill_fix() should also have been called from setcolreg().
So why don't we just revert the commit and instead add that drm_fb_helper_fill_fix() to setcolreg()?
Linus
IOW, I'm inclined to just do the revert. The "fix" clearly breaks things, and now you're adding random parts of the function back rather than just calling the "fill_fix()" function like things used to. Why?
Its not the final patch. I'm trying to get feedback on what broke exactly.
The commit message in dfe63bb0ad98 doesn't support any of these hacks
- it just seems to say that drm_fb_helper_fill_fix() should also have
been called from setcolreg().
So why don't we just revert the commit and instead add that drm_fb_helper_fill_fix() to setcolreg()?
Fine by me. The real problem is the nouveau driver is using the framebuffer device (fb_fillrect) before set_par is ever called. Before calling set_par the framebuffer state is not defined.
On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Am 12.01.2011 00:28, schrieb Linus Torvalds:
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons jsimmons@infradead.org Date: Thu Dec 23 16:40:37 2010 +0000
drm: Update fbdev fb_fix_screeninfo
Reverting this on top of todays git also fixes my problem.
Christian
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/
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Am 12.01.2011 00:28, schrieb Linus Torvalds:
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons jsimmons@infradead.org Date: Thu Dec 23 16:40:37 2010 +0000
drm: Update fbdev fb_fix_screeninfo
Reverting this on top of todays git also fixes my problem.
Christian
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/
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
On Wed, Jan 12, 2011 at 3:45 PM, James Simmons jsimmons@infradead.org wrote:
On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Am 12.01.2011 00:28, schrieb Linus Torvalds:
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons jsimmons@infradead.org Date: Thu Dec 23 16:40:37 2010 +0000
drm: Update fbdev fb_fix_screeninfo
Reverting this on top of todays git also fixes my problem.
Christian
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/
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
My keyboard is not working, I can not make an log. I see 'something' on the screen, I hear the boot song sometimes.
I will test it your parch, but for me it will take over 1 hour.
Am 12.01.2011 14:45, schrieb James Simmons:
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not.
Christian
Am 12.01.2011 14:45, schrieb James Simmons:
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not.
I doubt they are related.
On Wed, Jan 12, 2011 at 3:45 PM, James Simmons jsimmons@infradead.org wrote:
On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Am 12.01.2011 00:28, schrieb Linus Torvalds:
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons jsimmons@infradead.org Date: Thu Dec 23 16:40:37 2010 +0000
drm: Update fbdev fb_fix_screeninfo
Reverting this on top of todays git also fixes my problem.
Christian
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/
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
On Wed, Jan 12, 2011 at 5:13 PM, Anca Emanuel anca.emanuel@gmail.com wrote:
On Wed, Jan 12, 2011 at 3:45 PM, James Simmons jsimmons@infradead.org wrote:
On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Am 12.01.2011 00:28, schrieb Linus Torvalds:
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger borntraeger@de.ibm.com wrote:
Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though...
Can you try to bisect?
dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons jsimmons@infradead.org Date: Thu Dec 23 16:40:37 2010 +0000
drm: Update fbdev fb_fix_screeninfo
Reverting this on top of todays git also fixes my problem.
Christian
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/
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded)
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded)
Is nouveau a module? Does X run? From my understanding is the xorg driver need KMS to run. I didn't see nouveau at all in your dmesg.
On Wed, Jan 12, 2011 at 5:40 PM, James Simmons jsimmons@infradead.org wrote:
I tested the revert: the boot screen did change the resolution (without it don't), but my PC still hangs. (using an nvidia 8800GT).
Try my most recent patch. Where does it hang at? Any logs?
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded)
Is nouveau a module? Does X run? From my understanding is the xorg driver
I didn't modified any option, from the standard Ubuntu 10.10
need KMS to run. I didn't see nouveau at all in your dmesg.
Exact. I mentioned this when I tested 'next' versions from last year. The answer is in dfe63bb0ad9810db13aab0058caba97866e0a681.
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded)
Okay, can you do one more experiment for me. Since you already reverted the patch to get it booting I like to ask you to add
drm_fb_helper_fill_fix(info, fb_helper->fb);
back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have something like this:
mutex_lock(&dev->mode_config.mutex); for (i = 0; i < fb_helper->crtc_count; i++) { crtc = fb_helper->crtc_info[i].mode_set.crtc; ret = crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set); if (ret) { mutex_unlock(&dev->mode_config.mutex); return ret; } drm_fb_helper_fill_fix(info, fb_helper->fb); } mutex_unlock(&dev->mode_config.mutex);
Tell me if your system is still usable after that. Thanks for testing for me.
On Thu, Jan 13, 2011 at 7:55 PM, James Simmons jsimmons@infradead.org wrote:
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded)
Okay, can you do one more experiment for me. Since you already reverted the patch to get it booting I like to ask you to add
drm_fb_helper_fill_fix(info, fb_helper->fb);
back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have something like this:
mutex_lock(&dev->mode_config.mutex); for (i = 0; i < fb_helper->crtc_count; i++) { crtc = fb_helper->crtc_info[i].mode_set.crtc; ret = crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set); if (ret) { mutex_unlock(&dev->mode_config.mutex); return ret; } drm_fb_helper_fill_fix(info, fb_helper->fb); } mutex_unlock(&dev->mode_config.mutex);
Tell me if your system is still usable after that. Thanks for testing for me.
after
git revert dfe63bb0ad9810db13aab0058caba97866e0a681
and
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5c4f9b9..2aad663 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info) mutex_unlock(&dev->mode_config.mutex); return ret; } + drm_fb_helper_fill_fix(info, fb_helper->fb->pitch, fb_helper->fb } mutex_unlock(&dev->mode_config.mutex);
I get an working system. ( the boot screen is not ok ) Tested suspend/resume. Dmesg attached.
On Thu, 13 Jan 2011, Anca Emanuel wrote:
On Thu, Jan 13, 2011 at 7:55 PM, James Simmons jsimmons@infradead.org wrote:
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded)
Okay, can you do one more experiment for me. Since you already reverted the patch to get it booting I like to ask you to add
drm_fb_helper_fill_fix(info, fb_helper->fb);
back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have something like this:
mutex_lock(&dev->mode_config.mutex); for (i = 0; i < fb_helper->crtc_count; i++) { crtc = fb_helper->crtc_info[i].mode_set.crtc; ret = crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set); if (ret) { mutex_unlock(&dev->mode_config.mutex); return ret; } drm_fb_helper_fill_fix(info, fb_helper->fb); } mutex_unlock(&dev->mode_config.mutex);
Tell me if your system is still usable after that. Thanks for testing for me.
after
git revert dfe63bb0ad9810db13aab0058caba97866e0a681
and
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5c4f9b9..2aad663 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info) mutex_unlock(&dev->mode_config.mutex); return ret; }
drm_fb_helper_fill_fix(info, fb_helper->fb->pitch, fb_helper->fb } mutex_unlock(&dev->mode_config.mutex);
I get an working system. ( the boot screen is not ok ) Tested suspend/resume. Dmesg attached.
Just as I thought. Even this breaks the nouveau driver.
Could you now add also in the drm_fb_helper_fill_fix function
DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch, fb_helper->fb->depth);
I have a feeling the values are not right. Thanks.
On Fri, Jan 14, 2011 at 6:38 PM, James Simmons jsimmons@infradead.org wrote:
On Thu, 13 Jan 2011, Anca Emanuel wrote:
On Thu, Jan 13, 2011 at 7:55 PM, James Simmons jsimmons@infradead.org wrote:
With your patch, I can boot the system. But nouveau is not loaded. dmesg attached.
Forget to mention: the revert makes first steps of boot look the same (change the resolution of the text) but with your patch, I see a big ugly ununtu logo, (I think that is because nouveau is not loaded)
Okay, can you do one more experiment for me. Since you already reverted the patch to get it booting I like to ask you to add
drm_fb_helper_fill_fix(info, fb_helper->fb);
back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have something like this:
mutex_lock(&dev->mode_config.mutex); for (i = 0; i < fb_helper->crtc_count; i++) { crtc = fb_helper->crtc_info[i].mode_set.crtc; ret = crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set); if (ret) { mutex_unlock(&dev->mode_config.mutex); return ret; } drm_fb_helper_fill_fix(info, fb_helper->fb); } mutex_unlock(&dev->mode_config.mutex);
Tell me if your system is still usable after that. Thanks for testing for me.
after
git revert dfe63bb0ad9810db13aab0058caba97866e0a681
and
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5c4f9b9..2aad663 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info) mutex_unlock(&dev->mode_config.mutex); return ret; }
- drm_fb_helper_fill_fix(info, fb_helper->fb->pitch, fb_helper->fb
} mutex_unlock(&dev->mode_config.mutex);
I get an working system. ( the boot screen is not ok ) Tested suspend/resume. Dmesg attached.
Just as I thought. Even this breaks the nouveau driver.
Could you now add also in the drm_fb_helper_fill_fix function
DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch, fb_helper->fb->depth);
I have a feeling the values are not right. Thanks.
Please make an patch to test.
Just as I thought. Even this breaks the nouveau driver.
Could you now add also in the drm_fb_helper_fill_fix function
DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch, fb_helper->fb->depth);
I have a feeling the values are not right. Thanks.
Please make an patch to test.
Done. I had to test the patch myself. No need to do a revert. Just apply this patch to linus tree. Then send the dmesg to me. Thanks.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0307d60..beded14 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb) { + DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth); info->fix.type = FB_TYPE_PACKED_PIXELS; info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR; @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
if (new_fb) { info->var.pixclock = 0; - drm_fb_helper_fill_fix(info, fb_helper->fb); if (register_framebuffer(info) < 0) { return -EINVAL; } diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..fe87319 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
+ drm_fb_helper_fill_fix(info, fb); drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
On Fri, Jan 14, 2011 at 8:26 PM, James Simmons jsimmons@infradead.org wrote:
Just as I thought. Even this breaks the nouveau driver.
Could you now add also in the drm_fb_helper_fill_fix function
DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch, fb_helper->fb->depth);
I have a feeling the values are not right. Thanks.
Please make an patch to test.
Done. I had to test the patch myself. No need to do a revert. Just apply this patch to linus tree. Then send the dmesg to me. Thanks.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0307d60..beded14 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb) {
- DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
info->fix.type = FB_TYPE_PACKED_PIXELS; info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR; @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
if (new_fb) { info->var.pixclock = 0;
- drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) { return -EINVAL; } diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..fe87319 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
- drm_fb_helper_fill_fix(info, fb);
drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
I will test it, but first, I will need to disable the cassini driver, because it can not compile.
On Fri, Jan 14, 2011 at 8:40 PM, Anca Emanuel anca.emanuel@gmail.com wrote:
On Fri, Jan 14, 2011 at 8:26 PM, James Simmons jsimmons@infradead.org wrote:
Just as I thought. Even this breaks the nouveau driver.
Could you now add also in the drm_fb_helper_fill_fix function
DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch, fb_helper->fb->depth);
I have a feeling the values are not right. Thanks.
Please make an patch to test.
Done. I had to test the patch myself. No need to do a revert. Just apply this patch to linus tree. Then send the dmesg to me. Thanks.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0307d60..beded14 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb) {
- DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
info->fix.type = FB_TYPE_PACKED_PIXELS; info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR; @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
if (new_fb) { info->var.pixclock = 0;
- drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) { return -EINVAL; } diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index a26d047..fe87319 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); info->screen_size = size;
- drm_fb_helper_fill_fix(info, fb);
drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
I will test it, but first, I will need to disable the cassini driver, because it can not compile.
I will test this first:
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0307d60..beded14 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb) { + DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth); info->fix.type = FB_TYPE_PACKED_PIXELS; info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR; @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h
if (new_fb) { info->var.pixclock = 0; - drm_fb_helper_fill_fix(info, fb_helper->fb); if (register_framebuffer(info) < 0) { return -EINVAL; } diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/n index a26d047..3896771 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0307d60..beded14 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb) { + DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth); info->fix.type = FB_TYPE_PACKED_PIXELS; info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR; @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h
if (new_fb) { info->var.pixclock = 0; - drm_fb_helper_fill_fix(info, fb_helper->fb); if (register_framebuffer(info) < 0) { return -EINVAL; }
On Mon, Jan 10, 2011 at 23:59, Dave Airlie airlied@linux.ie wrote:
The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:
Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next
...
drm/i915: Completely disable fence pipelining.
Reverting this commit helps in v2.6.38-rc5+ when screen is not fully updated, or has a corrupted picture like horizontal black or white stripes. Using a compositor like compiz may help to avoid the problem.
dri-devel@lists.freedesktop.org