summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_dma.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: unbreak lastclose for failed driver initDaniel Vetter2012-07-251-1/+7
| | | | | | | | | | | | | | | | | | | | | | | We now refuse to load on gen6+ if kms is not enabled: commit 26394d9251879231b85e6c8cf899fa43e75c68f1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 26 21:33:18 2012 +0200 drm/i915: refuse to load on gen6+ without kms Which results in the drm core calling our lastclose function to clean up the mess, but that one is neatly broken for such failure cases since kms has been introduced in commit 79e539453b34e35f39299a899d263b0a1f1670bd Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 7 14:24:08 2008 -0800 DRM: i915: add mode setting support Reported-and-tested-by: Paulo Zanoni <przanoni@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: get rid of dev_priv->info->has_pch_splitPaulo Zanoni2012-07-051-2/+3
| | | | | | | | | | | | | | | | | | | | Previously we had has_pch_split to tell us whether we had a PCH or not and we also had dev_priv->pch_type to tell us which kind of PCH it was, but it could only be used if we were 100% sure we did have a PCH. Now that PCH_NONE was added to dev_priv->pch_type we don't need has_pch_split anymore: we can just check for pch_type != PCH_NONE. The HAS_PCH_{IBX,CPT,LPT} macros use dev_priv->pch_type, so they can only be called after intel_detect_pch. The HAS_PCH_SPLIT macro looks at dev_priv->info->has_pch_split, which is available earlier. Since the goal is to implement HAS_PCH_SPLIT using dev_priv->pch_type instead of dev_priv->info->has_pch_split, we need to make sure that intel_detect_pch is called before any calls to HAS_PCH_SPLIT are made. So we moved the intel_detect_pch call to an earlier stage. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Group the GT routines together in both code and vtableChris Wilson2012-07-031-1/+1
| | | | | | | | | | | | | | | Tidy up the routines for interacting with the GT (in particular the forcewake dance) which are scattered throughout the code in a single structure. v2: use wait_for_atomic for polling. v3: *really* use wait_for_atomic for polling. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't use dev->agpDaniel Vetter2012-06-251-1/+1
| | | | | | | | | This single leftover use is due to a patch that went into 3.5 through -fixes. With the fake agp stuff on demise, at least for gen6+ we can't use this any more. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: initialize the context idr unconditionallyDaniel Vetter2012-06-201-1/+1
| | | | | | | | | | | It doesn't hurt and it at least prevents us from OOPSing left and right at quite a few places. This also allows us to simplify the code a bit by folding the only line of context_open into the callsite. We obviuosly also need to run the cleanup code unconditionally, too. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix module unload after context mergeDaniel Vetter2012-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | commit 8e96d9c4d9843f00ebeb4a9b33596d96602ea101 Author: Ben Widawsky <ben@bwidawsk.net> Date: Mon Jun 4 14:42:56 2012 -0700 drm/i915: reset the GPU on context fini broke module unload because it reset the gpu before we've stopped touching it. Later on in the unload sequence the ringbuffer code complained that the gpu would idle properly (because intel_gpu_reset only resets the hw and not our sw state). v2: Reorder things so that we reset the gpu _before_ we release the backing storage of the default context. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51183 Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/context: create & destroy ioctlsBen Widawsky2012-06-141-0/+2
| | | | | | | | | | | | | | | | Add the interfaces to allow user space to create and destroy contexts. Contexts are destroyed automatically if the file descriptor for the dri device is closed. Following convention as usual here causes checkpatch warnings. v2: with is_initialized, no longer need to init at create drop the context switch on create (daniel) v3: Use interruptible lock (Chris) return -ENODEV in !GEM case (Chris) Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: preliminary context supportBen Widawsky2012-06-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Very basic code for context setup/destruction in the driver. Adds the file i915_gem_context.c This file implements HW context support. On gen5+ a HW context consists of an opaque GPU object which is referenced at times of context saves and restores. With RC6 enabled, the context is also referenced as the GPU enters and exists from RC6 (GPU has it's own internal power context, except on gen5). Though something like a context does exist for the media ring, the code only supports contexts for the render ring. In software, there is a distinction between contexts created by the user, and the default HW context. The default HW context is used by GPU clients that do not request setup of their own hardware context. The default context's state is never restored to help prevent programming errors. This would happen if a client ran and piggy-backed off another clients GPU state. The default context only exists to give the GPU some offset to load as the current to invoke a save of the context we actually care about. In fact, the code could likely be constructed, albeit in a more complicated fashion, to never use the default context, though that limits the driver's ability to swap out, and/or destroy other contexts. All other contexts are created as a request by the GPU client. These contexts store GPU state, and thus allow GPU clients to not re-emit state (and potentially query certain state) at any time. The kernel driver makes certain that the appropriate commands are inserted. There are 4 entry points into the contexts, init, fini, open, close. The names are self-explanatory except that init can be called during reset, and also during pm thaw/resume. As we expect our context to be preserved across these events, we do not reinitialize in this case. As Adam Jackson pointed out, The cutoff of 1MB where a HW context is considered too big is arbitrary. The reason for this is even though context sizes are increasing with every generation, they have yet to eclipse even 32k. If we somehow read back way more than that, it probably means BIOS has done something strange, or we're running on a platform that wasn't designed for this. v2: rename load/unload to init/fini (daniel) remove ILK support for get_size() (indirectly daniel) add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel) added comments (Ben) Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
* drm/i915: kick any firmware framebuffers before claiming the gttDaniel Vetter2012-06-131-17/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do when initializing the hw) because our fb/mmio space region moves around on a per-gen basis. So I've had to move it below the gtt initialization, but that seems to work, too. The important thing is that we do this before we set up the gtt wc mapping. Now an altogether different question is why people compile their kernels with vesafb enabled, but I guess making things just work isn't bad per se ... v2: - s/radeondrmfb/inteldrmfb/ - fix up error handling v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky. v4: Jani Nikula complained about the pointless bool primary initialization. v5: Don't oops if we can't allocate, noticed by Chris Wilson. v6: Resolve conflicts with agp rework and fixup whitespace. Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915 + agp/intel-gtt: prep work for direct setupDaniel Vetter2012-06-121-2/+11
| | | | | | | | | | | | | | | To be able to directly set up the intel-gtt code from drm/i915 and avoid setting up the fake-agp driver we need to prepare a few things: - pass both the bridge and gpu pci_dev to the probe function and add code to handle the gpu pdev both being present (for drm/i915) and not present (fake agp). - add refcounting to the remove function so that unloading drm/i915 doesn't kill the fake agp driver v2: Fix up the cleanup and refcount, noticed by Jani Nikula. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: stop using dev->agp->baseDaniel Vetter2012-06-121-8/+13
| | | | | | | | | For that to work we need to export the base address of the gtt mmio window from intel-gtt. Also replace all other uses of dev->agp by values we already have at hand. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add wait render timeout get paramBen Widawsky2012-06-061-0/+3
| | | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: wait render timeout ioctlBen Widawsky2012-05-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This helps implement GL_ARB_sync but stops short of allowing full blown sync objects. Finally we can use the new timed seqno waiting function to allow userspace to wait on a buffer object with a timeout. This implements that interface. The IOCTL will take as input a buffer object handle, and a timeout in nanoseconds (flags is currently optional but will likely be used for permutations of flush operations). Users may specify 0 nanoseconds to instantly check. The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any non-zero timeout parameter the wait ioctl will wait for the given number of nanoseconds on an object becoming unbusy. Since the wait itself does so holding struct_mutex the object may become re-busied before this completes. A similar but shorter race condition exists in the busy ioctl. v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris) Flush the object from the gpu write domain (Chris + Daniel) Fix leaked refcount in good case (Chris) Naturally align ioctl struct (Chris) v3: Drop lock after getting seqno to avoid ugly dance (Chris) v4: check for 0 timeout after olr check to allow polling (Chris) v5: Updated the comment. (Chris) v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel) Fix the commit message comment to be less ugly (Ben) Add a warning to check the return timespec (Ben) v7: Use DRM_AUTH for the ioctl. (Eugeni) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-next-2012-05-20' of ↵Dave Airlie2012-05-211-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-core-next Daniel wrote: The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly bugfixes: - last few patches for basic hsw enabling (Eugeni, infoframe support by Paulo) - Fix up infoframe support, we've hopefully squashed all the cargo-culting in there (Paulo). Among all the issues, this finally fixes some of the infoframe regressions seen on g4x and snb systems. - Fixup sdvo infoframe support, this fixes a regression from 2.6.37. - Correctly enable semaphores on snb, we've enabled it already for 3.5, but the dmar check was slightly wrong. - gen6 irq fixlets from Chris. - disable gmbus on i830, the hw seems to be simply broken. - fix up the pch pll fallout (Chris & me). - for_each_ring macro from Chris - I've figured I'll merge this now to avoid backport pain. - complain when the rps state isn't what we expect (Chris). Note that this is shockingly easy to hit and hence pretty much will cause a regression report. But it only tells us that the gpu turbo state got out of whack, a problem we know off since a long time (it cause the gpu to get stuck a a fixed frequency, usually the lowest one). Chris is working on a fix, but we haven't yet found a magic formula that works perfectly (only patches that massively reduce the frequency of this happening). - MAINTAINERS patch, I'm now officially the guy to beat up." * tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits) drm/i915: IBX has a fixed pch pll to pch pipe mapping drm/i915: implement hsw_write_infoframe drm/i915: small hdmi coding style cleanups drm/i915: fixup infoframe support for sdvo drm/i915: Enable the PCH PLL for all generations after link training drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN drm/i915: don't clobber the pipe param in sanitize_modesetting drm/i915: disable gmbus on i830 drm/i915: Replace the feature tests for BLT/BSD with ring init checks drm/i915: Check whether the ring is initialised prior to dispatch drm/i915: Introduce for_each_ring() macro drm/i915: Assert that the transcoder is indeed off before modifying it drm/i915: hook Haswell devices in place drm/i915: prepare HDMI link for Haswell drm/i915: move HDMI structs to shared location drm/i915: add WR PLL programming table drm/i915: add support for DDI-controlled digital outputs drm/i915: detect digital outputs on Haswell drm/i915: program iCLKIP on Lynx Point drm/i915: program WM_LINETIME on Haswell ...
| * drm/i915: Replace the feature tests for BLT/BSD with ring init checksChris Wilson2012-05-191-2/+2
| | | | | | | | | | | | | | | | | | | | When userspace asks whether the driver supports the BLT or BSD rings for this chip, simply report whether those particular rings are initialised v2: Use intel_ring_initialized() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | vga_switcheroo: Introduce struct vga_switcheroo_client_opsTakashi Iwai2012-05-131-4/+7
|/ | | | | | | | | | | This changes the API as a clean-up. Instead of passing multiple function pointers at each time, introduce a new struct holding the whole callback functions and pass it to the registration. The same struct will be used for the upcoming audio client registration, too. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* drm/i915: move pnv|ilk_gem_mem_freq to intel_pm.cDaniel Vetter2012-05-031-112/+0
| | | | | | | | Because this is the place where we actually use the results of them. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fixup __iomem mixups in ringbuffer.cDaniel Vetter2012-05-031-1/+1
| | | | | | | | | | | | | | | | Two things: - ring->virtual start is an __iomem pointer, treat it accordingly. - dev_priv->status_page.page_addr is now always a cpu addr, no pointer casting needed for that. Take the opportunity to remove the unnecessary drm indirection when setting up the ringbuffer iomapping. v2: Add a compiler barrier before reading the hw status page. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rework legacy GFX HWS handlingDaniel Vetter2012-05-031-13/+16
| | | | | | | | | | | | | | | | | | | | | | To get the fun stuff out of the way, the legacy hws is allocated by userspace when the gpu needs a gfx hws. And there's no reference-counting going on, so userspace can simply screw everyone over. At least it's not as horrible as i810, where the ringbuffer is allocated by userspace ... We can't fix this disaster, but we can at least tidy up the code a bit to make things clearer: - Drop the drm ioremap indirection. - Add a new new read_legacy_status_page to paper over the differences between the legacy gfx hws and the physical hws shared with the new ringbuffer code. - Add a pointer in dev_priv->dri1 for the cpu addresses - that one is an iomem remapping as opposed to all other hw status pages. This is just prep work to make sparse happy. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move the ips code to intel_pm.cDaniel Vetter2012-05-031-475/+3
| | | | | | | | | We now have a nice home for power management code, so let's use it! v2: Resolve conflict agains "Only enable IPS polling for gen5" Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move LP_RING&friends to i915_dma.cDaniel Vetter2012-05-031-0/+26
| | | | | | | | | | | | Wohoo! Now we only need to move all the gem/kms stuff that accidentally landed in i915_dma.c out of it, and this will be our legacy dri1 grave-yard. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: extract dri1 breadcrumb update from irq handlerDaniel Vetter2012-05-031-0/+13
| | | | | | | | | | | | | ... and hide it in i915_dma.c. This way all the legacy stuff dealing with READ_BREADCRUMB and LP_RING and friends is in i915_dma.c. v2: Rebase on top of Chris Wilson's rework irq handling code. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move dri1 irq ioctl code to i915_dma.cDaniel Vetter2012-05-031-0/+110
| | | | | | | | | | Let's just get this out of the way. v2: Rebase against ENODEV changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rip out dev_priv->tex_lru_log_granularityDaniel Vetter2012-05-031-1/+0
| | | | | | | | | | Assigned in setparam, used never. I didn't bother to dig through the archives to figure out what this was supposed to do. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: create dev_priv->dri1 dragon dungeon^W^W sub-structDaniel Vetter2012-05-031-4/+4
| | | | | | | | | | ... and shove allow_batchbuffer in there. More dragons will follow suit. There's the curious case that we allow this for KMS ... Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move dri1 vblank stubs to i915_dma.cDaniel Vetter2012-05-031-1/+43
| | | | | | | | | | | | | | i915_dma.c contains most of the old dri1 horror-show, so move the remaining bits there, too. The code has been removed and the only thing left are some stubs to ensure that userspace doesn't try to use this stuff. vblank_pipe_set only returns 0 without any side-effects, so we can even stub it out with the canonical drm_noop. v2: Rebase against ENODEV changes. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Only enable IPS polling for gen5Chris Wilson2012-05-031-5/+10
| | | | | | | | | | | | | | | | On SandyBridge IPS was entirely implemented in hardware and not reliant on the driver monitoring power consumption and feeding back desired run states, so the hardware is able to adapt quicker and more flexibly. Which is a huge relief for us as we no longer have to carry empirically derived magic algorithms. Yet despite the advance in technology, the driver was still doing its IPS polling on all machines. Restrict it to the only supported hardware, Clarkdale/Arrandale. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove do_retire from i915_wait_requestBen Widawsky2012-05-031-1/+2
| | | | | | | | | | | | | | | | | This originates from a hack by me to quickly fix a bug in an earlier patch where we needed control over whether or not waiting on a seqno actually did any retire list processing. Since the two operations aren't clearly related, we should pull the parameter out of the wait function, and make the caller responsible for retiring if the action is desired. The only function call site which did not get an explicit retire_request call (on purpose) is i915_gem_inactive_shrink(). That code was already calling retire_request a second time. v2: don't modify any behavior excepit i915_gem_inactive_shrink(Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: pending_flip_is_done is gen3, name it soChris Wilson2012-05-031-4/+0
| | | | | | | | And remove the cargo-culted copy from the valleyview irq handler. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: check for kms in dri1 ioctlsDaniel Vetter2012-05-031-0/+18
| | | | | | | | | | | | Calling these when gem assumes full control of the hw won't end in anything else than tears. So be a bit more paranoid here. Just serves as documentation. v2: Bail out with ENODEV as suggested by Chris Wilson. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rip out dev_priv->has_gemDaniel Vetter2012-05-031-5/+2
| | | | | | | | | | | | | | Always true these days. It has been added originally to work around some issues with the agp layer in 2.6.29: commit ac5c4e76180a74c7f922f6fa71ace0cef45fa433 Author: Dave Airlie <airlied@redhat.com> Date: Fri Dec 19 15:38:34 2008 +1000 drm/i915: GEM on PAE has problems - disable it for now. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Move GEM initialisation from i915_dma.c to i915_gem.cChris Wilson2012-05-031-65/+1
| | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Split the stolen handling for GEM out of i915_dma.cChris Wilson2012-05-031-149/+12
| | | | | | | | | | | We slightly modify the initialisation sequence to move the initialisation of the memory managers earlier and in particular before probing outputs and detecting any existing output configuration. This is essential if we wish to track preallocated objects and preserve them whilst initialising GEM. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: haswell has 3 pipes as wellEugeni Dodonov2012-04-171-1/+1
| | | | | | | | They work differently, but the count is the same. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rc6 in sysfsBen Widawsky2012-04-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge rc6 information into the power group for our device. Until now the i915 driver has not had any sysfs entries (aside from the connector stuff enabled by drm core). Since it seems like we're likely to have more in the future I created a new file for sysfs stubs, as well as the rc6 sysfs functions which don't really belong elsewhere (perhaps i915_suspend, but most of the stuff is in intel_display,c). displays rc6 modes enabled (as a hex mask): cat /sys/class/drm/card0/power/rc6_enable displays #ms GPU has been in rc6 since boot: cat /sys/class/drm/card0/power/rc6_residency_ms displays #ms GPU has been in deep rc6 since boot: cat /sys/class/drm/card0/power/rc6p_residency_ms displays #ms GPU has been in deepest rc6 since boot: cat /sys/class/drm/card0/power/rc6pp_residency_ms Important note: I've seen on SNB that even when RC6 is *not* enabled the rc6 register seems to have a random value in it. I can only guess at the reason reason for this. Those writing tools that utilize this value need to be careful and probably want to scrutinize the value very carefully. v2: use common rc6 residency units to milliseconds for the other RC6 types v3: don't create sysfs files for GEN <= 5 add a rc6_enable to show a mask of enabled rc6 types use unmerge instead of remove for sysfs group squash intel_enable_rc6() extraction into this patch v4: rename sysfs files (Chris) CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Daniel Vetter <daniel.vetter@ffwll.ch>f CC: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: squash in the 64bit division fix by Chris Wilson.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'drm-intel-next' of ↵Dave Airlie2012-04-121-33/+52
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-core-next Daniel Vetter wrote First pull request for 3.5-next, slightly large than usual because new things kept coming in since the last pull for 3.4. Highlights: - first batch of hw enablement for vlv (Jesse et al) and hsw (Eugeni). pci ids are not yet added, and there's still quite a few patches to merge (mostly modesetting). To make QA easier I've decided to merge this stuff in pieces. - loads of cleanups and prep patches spurred by the above. Especially vlv is a real frankenstein chip, but also hsw is stretching our driver's code design. Expect more to come in this area for 3.5. - more gmbus fixes, cleanups and improvements by Daniel Kurtz. Again, there are more patches needed (and some already queued up), but I wanted to split this a bit for better testing. - pwrite/pread rework and retuning. This series has been in the works for a few months already and a lot of i-g-t tests have been created for it. Now it's finally ready to be merged. Note that one patch in this series touches include/pagemap.h, that patch is acked-by akpm. - reduce mappable pressure and relocation throughput improvements from Chris. - mmap offset exhaustion mitigation by Chris Wilson. - a start at figuring out which codepaths in our messy dri1/ums+gem/kms driver we actually need to support by bailing out of unsupported case. The driver now refuses to load without kms on gen6+ and disallows a few ioctls that userspace never used in certain cases. More of this will definitely come. - More decoupling of global gtt and ppgtt. - Improved dual-link lvds detection by Takashi Iwai. - Shut up the compiler + plus fix the fallout (Ben) - Inverted panel brightness handling (mostly Acer manages to break things in this way). - Small fixlets and adjustements and some minor things to help debugging. Regression-wise QA reported quite a few issues on ivb, but all of them turned out to be hw stability issues which are already fixed in drm-intel-fixes (QA runs the nightly regression tests on -next alone, without -fixes automatically merged in). There's still one issue open on snb, it looks like occlusion query writes are not quite as cache coherent as we've expected. With some of the pwrite adjustements we can now reliably hit this. Kernel workaround for it is in the works." * 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits) drm/i915: VCS is not the last ring drm/i915: Add a dual link lvds quirk for MacBook Pro 8,2 drm/i915: make quirks more verbose drm/i915: dump the DMA fetch addr register on pre-gen6 drm/i915/sdvo: Include YRPB as an additional TV output type drm/i915: disallow gem init ioctl on ilk drm/i915: refuse to load on gen6+ without kms drm/i915: extract gt interrupt handler drm/i915: use render gen to switch ring irq functions drm/i915: rip out old HWSTAM missed irq WA for vlv drm/i915: open code gen6+ ring irqs drm/i915: ring irq cleanups drm/i915: add SFUSE_STRAP registers for digital port detection drm/i915: add WM_LINETIME registers drm/i915: add WRPLL clocks drm/i915: add LCPLL control registers drm/i915: add SSC offsets for SBI access drm/i915: add port clock selection support for HSW drm/i915: add S PLL control drm/i915: add PIXCLK_GATE register ... Conflicts: drivers/char/agp/intel-agp.h drivers/char/agp/intel-gtt.c drivers/gpu/drm/i915/i915_debugfs.c
| * drm/i915: refuse to load on gen6+ without kmsDaniel Vetter2012-04-091-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spurred by an irc discussion, let's start to clear up which parts of our kms + ums/gem + ums/dri1 + vbios/dri1 kernel driver pieces userspace in the wild actually uses. The idea is that we introduce checks at entry-points (module load time, ioctls, ...) first and then reap any obviously dead code in a second step. As a first step refuse to load without kms on chips where userspace never supported ums. Now upstream hasn't supported ums on ilk, ever. But RHEL had the great idea to backport the kms support to their ums driver. Cc: Dave Airlie <airlied@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Initialise GTT MTRR to -1Chris Wilson2012-03-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | Fixes a regression from 9e984bc1 (drm/i915: Don't do MTRR setup if PAT is enabled) where we left the MTRR as 0 and so tried to free a MTRR we did not own during unload. Reported-and-tested-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: clear the entire gtt when using gemDaniel Vetter2012-03-271-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've lost our guard page somewhere in the gtt rewrite, this patch here will restore it. Exercised by i-g-t/tests/gem_cs_prefetch. v2: Substract the guard page from the range we're supposed to manage with gem. Suggested by Chris Wilson to increase the odds of old ums + gem userspace not blowing up. To compensate for the loss of a page, don't substract the guard page in the modeset init code any longer. Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44748 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: the intel gtt is _not_ an agp bridge!Daniel Vetter2012-03-271-15/+9
| | | | | | | | | | | | | | | | | | | | So don't call it like that. Also rip out a confusing comment and instead explain what's really going on. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: s/i915_gem_do_init/i915_gem_init_global_gttDaniel Vetter2012-03-271-2/+3
| | | | | | | | | | | | | | | | | | ... because this is what it actually doesn now that we have the global gtt vs. ppgtt split. Also move it to the other global gtt functions in i915_gem_gtt.c Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add HAS_ALIASING_PPGTT parameter for userspaceDaniel Vetter2012-03-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On Sanybridge a few MI read/write commands only work when ppgtt is enabled. Userspace therefore needs to be able to check whether ppgtt is enabled. For added hilarity, you need to reset the "use global GTT" bit on snb when ppgtt is enabled, otherwise it won't work. Despite what bspec says about automatically using ppgtt ... Luckily PIPE_CONTROL (the only write cmd current userspace uses) is not affected by all this, as tested by tests/gem_pipe_control_store_loop. Reviewed-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * i915: Add and use pr_fmt and pr_<level>Joe Perches2012-03-181-2/+4
| | | | | | | | | | | | | | | | | | | | Use a more current logging style. Ensure that appropriate logging messages are prefixed with "i915: ". Convert printks to pr_<level>. Align arguments. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Don't do MTRR setup if PAT is enabledAdam Jackson2012-03-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | Some newer BIOSes are shipping with all MTRRs already populated. These BIOSes are all on machines with sufficiently new CPUs that the referenced errata doesn't apply anyway, so just don't try to claim the MTRR. Signed-off-by: Adam Jackson <ajax@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41648 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Pull MTRR setup to its own functionAdam Jackson2012-03-181-12/+17
| | | | | | | | | | | | | | | | No functional change here, just clarifying code flow. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: don't leak struct_mutex lock on ppgtt init failuresDaniel Vetter2012-04-031-1/+3
| | | | | | | | | | | | Reported-by: Konstantin Belousov <kostikbel@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: disable ppgtt on snb when dmar is enabledDaniel Vetter2012-04-021-1/+16
|/ | | | | | | | | | | | Totally unexpected that this regressed. Luckily it sounds like we just need to have dmar disable on the igfx, not the entire system. At least that's what a few days of testing between Tony Vroon and me indicates. Reported-by: Tony Vroon <tony@linx.net> Cc: Tony Vroon <tony@linx.net> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge remote-tracking branch 'airlied/drm-next' into for-airliedDaniel Vetter2012-02-231-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Manually resolve the conflict between the new enum drm property helpers in drm-next and the new "force-dvi" option that the "audio" output property gained in drm-intel-next. While resolving this conflict, switch the new drm_prop_enum_list to use the newly introduced enum defines instead of magic values. Conflicts: drivers/gpu/drm/i915/intel_modes.c Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: move pci bus master enable into driver.Dave Airlie2012-02-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current enabling of bus mastering in the drm midlayer allows a large race condition under kexec. When a kexec'ed kernel re-enables bus mastering for the GPU, previously setup dma blocks may cause writes to random pieces of memory. On radeon the writeback mechanism can cause these sorts of issues. This patch doesn't fix the problem, but it moves the bus master enable under the individual drivers control so they can move enabling it until later in their load cycle and close the race. Fix for radeon kms driver will be in a follow-up patch. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge tag 'drm-intel-next-2012-02-07' of ↵Dave Airlie2012-02-141-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-core-next * tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel: (29 commits) drm/i915: Handle unmappable buffers during error state capture drm/i915: rewrite shmem_pread_slow to use copy_to_user drm/i915: rewrite shmem_pwrite_slow to use copy_from_user drm/i915: fall through pwrite_gtt_slow to the shmem slow path drm/i915: add debugfs file for swizzling information drm/i915: fix swizzle detection for gen3 drm/i915: Remove the upper limit on the bo size for mapping into the CPU domain drm/i915: add per-ring fault reg to error_state drm/i915: reject GTT domain in relocations drm/i915: remove the i915_batchbuffer_info debugfs file drm/i915: capture error_state also for stuck rings drm/i915: refactor debugfs create functions drm/i915: refactor debugfs open function drm/i915: don't trash the gtt when running out of fences drm/i915: Separate fence pin counting from normal bind pin counting drm/i915/ringbuffer: kill snb blt workaround drm/i915: collect more per ring error state drm/i915: refactor ring error state capture to use arrays drm/i915: switch ring->id to be a real id drm/i915: set AUD_CONFIG N_value_index for DisplayPort ...
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-19 07:55:12 +0000