summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-09-20Merge remote-tracking branch 'danvet/drm-intel-fixes' into drm-intel-testingHEADdrm-intel-testingDaniel Vetter561-2604/+4725
Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_sdvo.c
2012-09-20drm/i915: Fix !CONFIG_PM sysfs for real this timedrm-intel-next-2012-09-20drm-intel-nextBen Widawsky1-0/+2
Somehow this hunk got dropped from my last patch. We do not have the rc6_attrs when there is no CONFIG_PM so this causes a compilation error. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Assert that the exec object lookup table is a power-of-twoChris Wilson1-0/+1
As we make the simplification of using a power-of-two size for the execbuffer handle-to-object TLB, we should validate that this is actually true and so clarify that premise. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionallyWang Xingchao1-4/+1
Clear Audio Enable bit to trigger unsolicated event to notify Audio Driver part the HDMI hot plug change. The patch fixed the bug when remove HDMI cable the bit was not cleared correctly. In intel_enable_hdmi(), if intel_hdmi->has_audio been true, the "Audio enable bit" will be set to trigger unsolicated event to notify Alsa driver the change. intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after remove the hdmi cable, here's debug log: [ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2 [ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0 so when comes back to intel_disable_hdmi(), the "Audio enable bit" will not be cleared. And this cause the eld infomation and pin presence doesnot update accordingly in alsa driver side. This patch will also trigger unsolicated event to alsa driver to notify the hot plug event: [ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1 [ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Convert the dmabuf object to use the new i915_gem_object_opsChris Wilson4-22/+37
By providing a callback for when we need to bind the pages, and then release them again later, we can shorten the amount of time we hold the foreign pages mapped and pinned, and importantly the dmabuf objects then behave as any other normal object with respect to the shrinker and memory management. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: update dpms property in set_modeDaniel Vetter1-0/+6
Hopefully this makes userspace slightly less confused about us frobbing the dpms state behind its back. Yeah, it would be better to be more careful with not changing the dpms state, but that is quite more invasive. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: don't call dpms funcs after set_modeDaniel Vetter1-10/+0
... because our current set_mode implementation doesn't bother to adjust for the dpms state, we just forcefully update it. So stop pretending that we're better than we are and rip out this extranous call. Note that this totally confuses userspace, because the exposed connector property isn't actually updated ... Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: don't disable fdi links harder in ilk_crtc_enableDaniel Vetter1-3/+5
Because they should have been disabled when shutting down the display pipe previously. To ensure that this is the case, add a few assserts instead of unconditionally disabling the fdi link. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: rip out intel_disable_pch_portsDaniel Vetter1-60/+0
Even with the old crtc helper code we should have disabled all encoders on that pipe by now, and with the new code this would definitely paper over a bug. We already have the necessary checks in place in intel_disable_transcoder, so if we accidentally leave a pch port on, this will be caught. Hence just rip this all out. Note that up to the patch in this giant modeset series that removes the LVDS special case to avoid disabling LVDS in the encoder->prepare callback ("drm/i915/lvds: ditch ->prepare special case"), this was not the case for all outputs. Also note that in commit 1b3c7a47f993bf9ab6c4c7cc3bbf5588052b58f4 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Wed Nov 25 13:09:38 2009 +0800 drm/i915: Fix LVDS stability issue on Ironlake this was already discovered independently and worked around. How I bloody hate this entire mess of cludges piled on top of other cludges. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20agp/intel: Use a write-combining map for updating PTEsChris Wilson1-3/+8
Rewriting the PTE entries using an WC mapping is roughly an order of magnitude faster than through the uncached mapping. This makes an observable difference on workloads that cycle through large numbers of buffers, for example Chromium using ShmPixmaps where virtually all the CPU time is currently spent rebinding the userptr. v2: Limit the WC mapping to older generations as we have observed that the TLB invalidation on SandyBridge+ is unreliable with WC updates. See i-g-t/tests/gem_gtt_cpu_tlb Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Limit the ioremap of the PCI bar to the registersChris Wilson1-2/+14
In the future we may like to experiment with using a WC map of the GTT portion. However, that will conflict with i915.ko mapping the entire bar as UC in order to access the GPU registers. Instead we can shrink the register ioremap to only map the register block. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by (IVB): Ben Widawsky <ben@bwidawsk.net> Acked-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Squashed-in follow-up fix for gen2/3 registers file size from Chris Wilson.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Show render P state thresholds in sysfsBen Widawsky1-0/+36
This is useful for userspace utilities which wish to use the previous interface, specifically for micromanaging the increase/decrease steps by setting min == max. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Add setters for min/max frequencyBen Widawsky1-2/+81
Provide a standardized sysfs interface for setting min, and max frequencies. The code which reads the limits were lifted from the debugfs files. As a brief explanation, the limits are similar to the CPU p-states. We have 3 states: RP0 - ie. max frequency RP1 - ie. "preferred min" frequency RPn - seriously lowest frequency Initially Daniel asked me to clamp the writes to supported values, but in conforming to the way the cpufreq drivers seem to work, instead return -EINVAL (noticed by Jesse in discussion). The values can be used by userspace wishing to control the limits of the GPU (see the CC list for people who care). v4: Make exceeding the soft limits return -EINVAL as well (Daniel) v3: bug fix (Ben) - was passing the MHz value to gen6_set_rps instead of the step value. To fix, deal only with step values by doing the divide at the top. v2: add the dropped mutex_unlock in error cases (Chris) EINVAL on both too min, or too max (Daniel) v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: rip out edp special case from dp_link_downDaniel Vetter1-7/+0
This has been tons of fun to figure out with git blame. The first notion of this code block goes back to the original cpu edp enabling for ilk in commit 32f9d658aee5be09ebdd28fc730630e61d0b46db Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Fri Jul 24 01:00:32 2009 +0800 drm/i915: Add eDP support on IGDNG mobile chip Two things are notable in this commit wrt to the this edp special case: - The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports. - The cpu edp port is disabled at the top of the dp_link_down function. My theory is that these hacks was added to work around the completely different modeset sequence for cpu edp ports compared to pch edp ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up, this shouldn't be required any more. The really interesting question is how this special cases survived this long in the code. The first step is declaring the pch port D as eDP if it's used for an internal panel: commit b329530ca7cdf6bf014f2124efd983e01265d623 Author: Adam Jackson <ajax@redhat.com> Date: Fri Jul 16 14:46:28 2010 -0400 drm/i915/dp: Correctly report eDP in the core connector type This commit unfortunately failed to notice that not all edp ports are created equal. Then follow a flurry of refactorings, culminating in a patch from Keith Packard which resulted in the current logic (by making it "correct" for all platforms that have edp): commit 417e822deee1d2bcd8a8a60660c40a0903713f2b Author: Keith Packard <keithp@keithp.com> Date: Tue Nov 1 19:54:11 2011 -0700 drm/i915: Treat PCH eDP like DP in most places None of these cleanups or refactorings supply any reason why we need this code, they've simply carried it on as-is. Hence presume it might be harmful with the current code and rip it out. We do rewrite the link training bits completely anyway when re-training the link. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Drop the misleading cast to the wrong user pointer typeChris Wilson1-6/+3
The exec_list is of type drm_i915_gem_exec_object2 and so casting it to a drm_i915_gem_relocation_entry is very confusing! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20i915: initialize CADL in opregionLekensteyn1-1/+22
This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop. The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is empty, the ACPI methods that are called on pressing brightness / display switching hotkeys will not trigger a notification. As a result, it appears as no hotkey has been pressed. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452 Tested-by: Peter Wu <lekensteyn@gmail.com> Signed-off-by: Peter Wu <lekensteyn@gmail.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: disable the cpu edp port after the cpu pipeDaniel Vetter1-2/+7
See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This applies to all platforms where we currently support eDP on, i.e. ilk, snb & ivb. Without this change we fail to light up the eDP port on previously unused crtcs (likely because something is stuck on the old pipe), and we also fail to properly disable the old pipe (i.e. bit 30 in the PIPECONF register is stuck as set until the next reboot). v2: Rebased on top of the edp panel off sequence changes in 3.6-rc2. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44001 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: rip out dp port enabling cludges^WchecksDaniel Vetter1-8/+8
These have been added because dp links are fiddle things and don't like it when we try to re-train an enabled output (or disable a disabled output harder). And because the crtc helper code is ridiculously bad add tracking the modeset state. But with the new code in place it is simply a bug to disable a disabled encoder or to enable an enabled encoder again. Hence convert these to WARNs (and bail out for safety), but flatten all conditionals in the code itself. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: robustify edp_pll_on/offDaniel Vetter1-11/+18
With the previous patch to clean up where exactly these two functions are getting called, this patch can tackle the enable/disable code itself: - WARN if the port enable bit is in the wrong state or if the edp pll bit is in the wrong state, just for paranoia's sake. - Don't disable the edp pll harder in the modeset functions just for fun. - Don't set the edp pll enable flag in intel_dp->DP in modeset, do that while changing the actual hw state. We do the same with the actual port enable bit, so this is a bit more consistent. - Track the current DP register value when setting things up and add some comments how intel_dp->DP is used in the disable code. v2: Be more careful with resetting intel_dp->DP - otherwise dpms off->on will fail spectacularly, becuase we enable the eDP port when we should only enable the eDP pll. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: clean up the cpu edp pll special caseDaniel Vetter1-47/+27
By using the new pre_enable/post_disable functions. To ensure that we only frob the cpu edp pll while the pipe is off add the relevant asserts. Thanks to the new output state staging, this is now really easy. With this fixed we can now finally rip out the special-case handling in the dp dpms code and replace it by the common intel_connector_dpms. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: add encoder->pre_enable/post_disableDaniel Vetter2-0/+10
The cpu eDP encoder has some horrible hacks to set up the DP pll at the right time. To be able to move them to the right place, add some more encoder callbacks so that this can happen at the right time. LVDS has some similar funky hacks, but that would require more work (we need to move around the pll setup a bit). Hence for now only wire these new callbacks up for ilk+ - we only have cpu eDP on these platforms. v2: Bikeshed the vtable ordering, requested by Chris Wilson. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: rip out early dp port write for gm45/ilkDaniel Vetter1-13/+0
It's bogus. If I've followed the history of this piece of code correctly, i.e. the initial register write with the following vblank wait, this goes all the way back to the original enabling of DP support in commit a4fc5ed69817c73e32571ad7837bb707f9890009 Author: Keith Packard <keithp@keithp.com> Date: Tue Apr 7 16:16:42 2009 -0700 drm/i915: Add Display Port support Unfortunately it seems to be nothing more than glorified duct-tape and sometimes actively harmful. Adam Jackson noticed this for CPT platforms with commit e85194641bec56179dcf5e1704ce5c6bf30340c6 Author: Adam Jackson <ajax@redhat.com> Date: Thu Jul 21 17:48:38 2011 -0400 drm/i915/dp: Don't turn CPT DP ports on too early Unfortunately this kept the code around for ilk and gm45. The specific failure case I'm seeing here is that after a dpms off/on cycle we have the bits from the last link training (hopefully successful link training) set in intel_dp->DP. This is requiered so that complete_link_train can enable the port with the right tuning values. Unfortunately writing these again to the disabled port at dpms on time kills the port somehow until it's disabled - dp link training fails in an endless loop without this patch on my mobile ilk and gm45. Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51493 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Error checks in gen6_set_rpsBen Widawsky2-1/+9
With the new "standardized" sysfs interfaces we need to be a bit more careful about setting the RPS values. Because the sysfs code and the rps workqueue can run at the same time, if the sysfs setter wins the race to the mutex, the workqueue can come in and set a value which is out of range (ie. we're no longer protecting by RPINTLIM). I was not able to actually make this error occur in testing. 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>
2012-09-20drm/i915: POSTING_READ the new rps valueBen Widawsky1-0/+2
In order to keep our cached values in sync with the hardware, we need a posting read here. CC: Chris Wilson <chris@chris-wilson.co.uk> 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>
2012-09-20drm/i915: Add current/max/min GPU freq to sysfsBen Widawsky1-0/+70
Userspace applications such as PowerTOP are interesting in being able to read the current GPU frequency. The patch itself sets up a generic array for gen6 attributes so we can easily add other items in the future (and it also happens to be just about the cleanest way to do this). The patch is a nice addition to commit 1ac02185dff3afac146d745ba220dc6672d1d162 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 30 13:26:48 2012 +0200 drm/i915: add a tracepoint for gpu frequency changes Reading the GPU frequncy can be done by reading a file like: /sys/class/drm/card0/render_frequency_mhz Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: #define gpu freq multiplerBen Widawsky2-11/+13
Magic numbers are bad mmmkay. In this case in particular the value is especially weird because the docs say multiple things. We'll need this value for sysfs, so extracting it is useful for that as well. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: variable renamesBen Widawsky1-8/+8
Name variables a bit better for copy-pasters. This got turned up as part of review for upcoming sysfs patches. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: extract compute_clocks from ironlake_crtc_mode_setPaulo Zanoni1-30/+66
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: resolved conflicts due to missing some earlier patches.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_setPaulo Zanoni1-5/+3
Because declaring a variable in the beginning of the function, then initializing it 100 lines later, then using it 100 lines later does not make our code look good IMHO. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_setPaulo Zanoni1-36/+52
Because ironlake_crtc_mode_set is a giant function that used to have 404 lines. Let's try to make it less complex/confusing. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Replace the array of pages with a scatterlistChris Wilson12-220/+239
Rather than have multiple data structures for describing our page layout in conjunction with the array of pages, we can migrate all users over to a scatterlist. One major advantage, other than unifying the page tracking structures, this offers is that we replace the vmalloc'ed array (which can be up to a megabyte in size) with a chain of individual pages which helps reduce memory pressure. The disadvantage is that we then do not have a simple array to iterate, or to access randomly. The common case for this is in the relocation processing, which will typically fit within a single scatterlist page and so be almost the same cost as the simple array. For iterating over the array, the extra function call could be optimised away, but in reality is an insignificant cost of either binding the pages, or performing the pwrite/pread. v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the trivial compile error from rebasing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Pin backing pages for preadChris Wilson1-23/+13
By using the recently introduced pinning of pages, we can safely drop the mutex in the knowledge that the pages are not going to disappear beneath us, and so we can simplify the code for iterating over the pages. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Pin backing pages for pwriteChris Wilson1-24/+13
By using the recently introduced pinning of pages, we can safely drop the mutex in the knowledge that the pages are not going to disappear jeneath us, and so we can simplify the code for iterating over the pages. Note: The old code had such complicated page refcounting since it used obj->pages as a micro-optimization if it's there, but that could (before this patch) disappear when we drop the dev->struct_mutex. Hence some manual page refcounting was required for the slow path, complicated by the fact that pages returned by shmem_read_mapping_page already have a pageref, which needs to be dropped again. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Added note to explain the question Ben raised in review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Pin backing pages whilst exporting through a dmabuf vmapChris Wilson3-4/+27
We need to refcount our pages in order to prevent reaping them at inopportune times, such as when they currently vmapped or exported to another driver. However, we also wish to keep the lazy deallocation of our pages so we need to take a pin/unpinned approach rather than a simple refcount. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: Introduce drm_i915_gem_object_opsChris Wilson3-27/+80
In order to specialise functions depending upon the type of object, we can attach vfuncs to each object via a new ->ops pointer. For instance, this will be used in future patches to only bind pages from a dma-buf for the duration that the object is used by the GPU - and so prevent them from pinning those pages for the entire of the object. v2: Bonus comments. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-20drm/i915: placeholder getparamBen Widawsky1-0/+1
There are internal patches for a feature which require a parameter to query whether support exists . These patches cannot be made external yet. In order to keep existing tests and userspace happy and free from conflicts, reserve a number for it. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-19Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie27-642/+2257
into drm-next Daniel writes: "The big ticket item here is the new i915 modeset infrastructure. Shockingly it didn't not blow up all over the place (i.e. I've managed to fix the ugly issues before merging). 1-2 smaller corner cases broke, but we have patches. Also, there's tons of patches on top of this that clean out cruft and fix a few bugs that couldn't be fixed with the crtc helper based stuff. So more stuff to come ;-) Also a few other things: - Tiny fix in the fb helper to go through the official dpms interface instead of calling the crtc helper code. - forcewake code frobbery from Ben, code should be more in-line with what Windows does now. - fixes for the render ring flush on hsw (Paulo) - gpu frequency tracepoint - vlv forcewake changes to better align it with our understanding of the forcewake magic. - a few smaller cleanups" + 2 fixes. * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (78 commits) drm/i915: fix OOPS in lid_notify drm/i915: correctly update crtc->x/y in set_base drm/fb helper: don't call drm_helper_connector_dpms directly drm/i915: improve modeset state checking after dpms calls drm/i915: add tons of modeset state checks drm/i915: no longer call drm_helper_resume_force_mode drm/i915: disable all crtcs at suspend time drm/i915: push commit_output_state past the crtc/encoder preparing drm/i915: switch the load detect code to the staged modeset config drm/i915: WARN if the pipe won't turn off drm/i915: s/intel_encoder_disable/intel_encoder_noop drm/i915: push commit_output_state past crtc disabling drm/i915: implement new set_mode code flow drm/i915: compute masks of crtcs affected in set_mode drm/i915: use staged outuput config in lvds->mode_fixup drm/i915: use staged outuput config in tv->mode_fixup drm/i915: extract adjusted mode computation drm/i915: move output commit and crtc disabling into set_mode drm/i915: remove crtc disabling special case drm/i915: push crtc->fb update into pipe_set_base ...
2012-09-19drm: micro optimise cache flushingDave Airlie1-1/+2
We hit this a lot with i915 and although we'd like to engineer things to hit it a lot less, this commit at least makes it consume a few less cycles. from something containing movzwl 0x0(%rip),%r10d to add %r8,%rdx I only noticed it while using perf to profile something else. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-09-19Merge branch 'drm-lcdc' of git://linuxtv.org/pinchartl/fbdev into drm-nextDave Airlie25-11/+3031
Laurent writes: The SH Mobile DRM driver is now (in my opinion) ready for mainline. It requires GEM and KMS/FB helpers that have been reviewed on the list and tested. Sascha is waiting for them to reach your tree to send a pull request for another new driver. * 'drm-lcdc' of git://linuxtv.org/pinchartl/fbdev: drm: Renesas SH Mobile DRM driver drm: Add NV24 and NV42 pixel formats DRM: Add DRM KMS/FB CMA helper DRM: Add DRM GEM CMA helper drm/edid: limit printk when facing bad edid
2012-09-18drm: Renesas SH Mobile DRM driverLaurent Pinchart16-0/+2258
The SH Mobile LCD controller (LCDC) DRM driver supports the main graphics plane in RGB and YUV formats, as well as the overlay planes (in alpha-blending mode only). Only flat panel outputs using the parallel interface are supported. Support for SYS panels, HDMI and DSI is currently not implemented. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
2012-09-18drm: Add NV24 and NV42 pixel formatsLaurent Pinchart2-0/+8
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2012-09-18DRM: Add DRM KMS/FB CMA helperLars-Peter Clausen4-0/+443
This patchset introduces a set of helper function for implementing the KMS framebuffer layer for drivers which use the DRM GEM CMA helper function. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> [Make DRM_KMS_CMA_HELPER a boolean Kconfig option] Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2012-09-18DRM: Add DRM GEM CMA helperSascha Hauer4-0/+302
Many embedded drm devices do not have a IOMMU and no dedicated memory for graphics. These devices use CMA (Contiguous Memory Allocator) backed graphics memory. This patch provides helper functions to be able to share the code. The code technically does not depend on CMA as the backend allocator, the name has been chosen because CMA makes for a nice, short but still descriptive function prefix. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Lars-Peter Clausen <lars@metafoo.de> [Make DRM_GEM_CMA_HELPER a boolean Kconfig option] Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2012-09-18drm/i915: fix OOPS in lid_notifyfor-airliedDaniel Vetter1-1/+1
This goes back to commit c1c7af60892070e4b82ad63bbfb95ae745056de0 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 10 15:28:03 2009 -0700 drm/i915: force mode set at lid open time It was used to fix an issue on a i915GM based Thinkpad X41, which somehow clobbered the modeset state at lid close time. Since then massive amounts of things changed: Tons of fixes to the modeset sequence, OpRegion support, better integration with the acpi code. Especially OpRegion /should/ allow us to control the display hw cooperatively with the firmware, without the firmware clobbering the hw state behind our backs. So it's dubious whether we still need this. The second issue is that it's unclear who's responsibility it actually is to restore the mode - Chris Wilson suggests to just emit a hotplug event and let userspace figure things out. The real reason I've stumbled over this is that the new modeset code breaks drm_helper_resume_force_mode - it OOPSes derefing a NULL vfunc pointer. The reason this wasn't caught in testing earlier is that in commit c9354c85c1c7bac788ce57d3c17f2016c1c45b1d Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon Nov 2 09:29:55 2009 -0800 i915: fix intel graphics suspend breakage due to resume/lid event confusion logic was added to _not_ restore the modeset state after a resume. And since most machines are configured to auto-suspend on lid-close, this neatly papered over the issue. Summarizing, this shouldn't be required on any platform supporting OpRegion. And none of the really old machines I have here seem to require it either. Hence I'm inclined to just rip it out. But in case that there are really firmwares out there that clobber the hw state, replace it with a call to intel_modset_check_state. This will ensure that we catch any issues as soon as they happen. Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-18drm/i915: correctly update crtc->x/y in set_baseDaniel Vetter1-4/+6
While reworking the modeset sequence, this got lost in commit 25c5b2665fe4cc5a93edd29b62e7c05c15dddd26 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 8 22:08:04 2012 +0200 drm/i915: implement new set_mode code flow I've noticed this because some Xorg versions seem to set up a new mode with every crtc at (0,0) and then pan to the right multi-monitor setup. And since some hacks of mine added more calls to mode_set using the stored crtc->x/y my multi-screen setup blew up. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-17drm/i915: HDMI - Clear Audio Enable bit for Hot PlugWang Xingchao1-1/+1
Clear Audio Enable bit to trigger unsolicated event to notify Audio Driver part the HDMI hot plug change. The patch fixed the bug when remove HDMI cable the bit was not cleared correctly. In intel_hdmi_dpms(), if intel_hdmi->has_audio been true, the "Audio enable bit" will be set to trigger unsolicated event to notify Alsa driver the change. intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after remove the hdmi cable, here's debug log: [ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2 [ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0 so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this cause the eld infomation and pin presence doesnot update accordingly in alsa driver side. This patch will also trigger unsolicated event to alsa driver to notify the hot plug event: [ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1 [ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-17drm/i915: Reduce a pin-leak BUG into a WARNChris Wilson1-1/+2
Pin-leaks persist and we get the perennial bug reports of machine lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that the object cannot be pinned at that time it should prevent the driver from locking up, and hopefully restore a semblance of working whilst still leaving us a OOPS to debug. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-17drm/i915: enable lvds pin pairs before dpll on gen2Daniel Vetter1-6/+6
Otherwise things migt not work too well. Breakage introduced in commit eb1cbe4848b01f9f073064377875bc7d71eb401b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 28 23:12:16 2012 +0200 drm/i915: split PLL update code out of i9xx_crtc_mode_set Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org (for 3.5 only) Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-17drm/edid: limit printk when facing bad edidJerome Glisse3-11/+20
Limit printing bad edid information at one time per connector. Connector that are connected to a bad monitor/kvm will likely stay connected to the same bad monitor/kvm and it makes no sense to keep printing the bad edid message. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-09-16Linux 3.6-rc6Linus Torvalds1-1/+1
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-15 04:40:46 +0000