summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/i915: Do not unlock upon error in i915_gem_idle()Chris Wilson2013-10-011-6/+3
| | | | | | | | | | | | | | | | We never took the lock ourselves and all callers expect the struct_mutex to be locked upon return (be it success or error), thereore dropping the lock along the error paths looks to be a vestigial error from commit db1b76ca6a79c774074ae87bee7afc0825a478f5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 9 16:51:37 2013 +0200 drm/i915: don't frob mm.suspended when not using ums Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use unsigned for overflow checks in execbufDaniel Vetter2013-10-011-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | There's actually no real risk since we already check for stricter constraints earlier (using UINT_MAX / sizeof (struct drm_i915_gem_exec_object2) as the limit). But in eb_create we use signed integers, which steals a factor of 2. Luckily struct drm_i915_gem_exec_object2 for this to not matter. Still, be consistent and use unsigned integers. Similar use unsinged integers when checking for overflows in the relocation entry processing. I've also added a new subtests to igt/gem_reloc_overflow to also test for overflowing args->buffer_count values. v2: Give the variables again tighter scope to make it clear that the computation is purely local and doesn't leak out to the 2nd block. Requested by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Ditch INTELFB_CONN_LIMITDaniel Vetter2013-10-013-3/+2
| | | | | | | | | | | | | | | And the gratious overallocation of crtcs. Seems to go back to the ums days of yonder ... We also still need it to make the fbdev emulation happy, but I don't think there's really a need. Especially since the current fbdev emulation doesn't actually support cloning. v2: Use sizeof(*pointer) pattern (Jani). Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use kcalloc moreDaniel Vetter2013-10-015-9/+10
| | | | | | | | | | | | | | | | | | No buffer overflows here, but better safe than sorry. v2: - Fixup the sizeof conversion, I've missed the pointer deref (Jani). - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani). - Use kmalloc_array for the execbuf fastpath to avoid the memset (Chris). I've opted to leave all other conversions as-is since they aren't in a fastpath and dealing with cleared memory instead of random garbage is just generally nicer. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Drop the contentious kmalloc_array hunk in execbuf.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) patternDaniel Vetter2013-10-0116-30/+30
| | | | | | | | | | | Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-next-2013-09-21-merged' of ↵Dave Airlie2013-10-0143-1117/+4422
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next drm-intel-next-2013-09-21: - clock state handling rework from Ville - l3 parity handling fixes for hsw from Ben - some more watermark improvements from Ville - ban badly behaved context from Mika - a few vlv improvements from Jesse - VGA power domain handling from Ville drm-intel-next-2013-09-06: - Basic mipi dsi support from Jani. Not yet converted over to drm_bridge since that was too fresh, but the porting is in progress already. - More vma patches from Ben, this time the code to convert the execbuffer code. Now that the shrinker recursion bug is tracked down we can move ahead here again. Yay! - Optimize hw context switching to not generate needless interrupts (Chris Wilson). Also some shuffling for the oustanding request allocation. - Opregion support for SWSCI, although not yet fully wired up (we need a bit of runtime D3 support for that apparently, due to Windows design deficiencies), from Jani Nikula. - A few smaller changes all over. [airlied: merge conflict fix in i9xx_set_pipeconf] * tag 'drm-intel-next-2013-09-21-merged' of git://people.freedesktop.org/~danvet/drm-intel: (119 commits) drm/i915: assume all GM45 Acer laptops use inverted backlight PWM drm/i915: cleanup a min_t() cast drm/i915: Pull intel_init_power_well() out of intel_modeset_init_hw() drm/i915: Add POWER_DOMAIN_VGA drm/i915: Refactor power well refcount inc/dec operations drm/i915: Add intel_display_power_{get, put} to request power for specific domains drm/i915: Change i915_request power well handling drm/i915: POSTING_READ IPS_CTL before waiting for the vblank drm/i915: don't disable ERR_INT on the IRQ handler drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYT drm/i915/vlv: honor i915_enable_rc6 boot param on VLV drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF drm/i915: Do remaps for all contexts drm/i915: Keep a list of all contexts drm/i915: Make l3 remapping use the ring drm/i915: Add second slice l3 remapping drm/i915: Fix HSW parity test drm/i915: dump crtc timings from the pipe config drm/i915: register backlight device also when backlight class is a module drm/i915: write D_COMP using the mailbox ... Conflicts: drivers/gpu/drm/i915/intel_display.c
| * Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter2013-09-247992-237941/+525418
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches: - Header cleanup in intel_drv.h, both changed in -fixes and my current -next pile. - Cursor handling cleanup for -next which depends upon the cursor handling fix merged into -rc2. All just trivial conflicts of the "changed adjacent lines" type: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: assume all GM45 Acer laptops use inverted backlight PWMJani Nikula2013-09-201-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is plenty of evidence suggesting all of the GM45 based Acer laptops (including their eMachines and Packard Bell brands) use inverted backlight PWM. Assume this is really the case, and quirk them all. The old bugs that were fixed by subsystem device specific quirks: * https://bugs.freedesktop.org/show_bug.cgi?id=59628 * https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35 * https://bugs.freedesktop.org/show_bug.cgi?id=44156 * https://bugzilla.kernel.org/show_bug.cgi?id=53881 See also this bug and the plethora of duplicates: * https://bugs.launchpad.net/ubuntu/+source/linux/+bug/765438 References: https://bugzilla.kernel.org/show_bug.cgi?id=54171 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: cleanup a min_t() castDan Carpenter2013-09-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lower layers of sysfs will not allow an "offset" of more than GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But it's a little easier to audit if we don't have to worry that the subtraction will result in negative values. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Pull intel_init_power_well() out of intel_modeset_init_hw()Ville Syrjälä2013-09-203-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The init and resume codepaths want to handel the power well in slightly different ways, so pull the power well init out from intel_modeset_init_hw() which gets called in both cases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add POWER_DOMAIN_VGAVille Syrjälä2013-09-202-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | VGA registers/memory live inside the the display power well. Add a power domain for VGA. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Refactor power well refcount inc/dec operationsVille Syrjälä2013-09-201-18/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We increase/decrease the power well refcount in several places now, and all of those places need to do the same thing, so pull that code into a few small helper functions. v2: Rename the funcs to __intel_power_well_{get,put} Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add intel_display_power_{get, put} to request power for specific ↵Ville Syrjälä2013-09-202-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | domains Add APIs to get/put power well references for specific purposes. v2: Split the i915_request change to another patch Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Change i915_request power well handlingVille Syrjälä2013-09-202-9/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reorganize the internal i915_request power well handling to use the reference count just like everyone else. This way all we need to do is check the reference count and we know whether the power well needs to be enabled of disabled. v2: Split he intel_display_power_{get,put} change to another patch. Add intel_resume_power_well() to make sure we enable the power well on resume Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: POSTING_READ IPS_CTL before waiting for the vblankPaulo Zanoni2013-09-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Make sure we write to IPS before we actually wait. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: don't disable ERR_INT on the IRQ handlerPaulo Zanoni2013-09-201-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently disable the ERR_INT interrupts while running the IRQ handler because we fear that if we do an unclaimed register access from inside the IRQ handler we'll keep triggering the IRQ handler forever. The problem is that since we always disable the ERR_INT interrupts at the IRQ handler, when we get a FIFO underrun we'll always print both messages: - "uncleared fifo underrun on pipe A" - "Pipe A FIFO underrun" Because the "was_enabled" variable from ivybridge_set_fifo_underrun_reporting will always be false (since we disable ERR int at the IRQ handler!). Instead of actually fixing ivybridge_set_fifo_underrun_reporting, let's just remove the "disable ERR_INT during the IRQ handler" code. As far as we know we shouldn't really be triggering ERR_INT interrupts from the IRQ handler, so if we ever get stuck in the endless loop of interrupts we can git-bisect and revert (and we can even bisect and revert this patch in case I'm just wrong). As a bonus, our IRQ handler is now simpler and a few nanoseconds faster. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYTJesse Barnes2013-09-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Byt doesn't have rc6p and rc6pp support and even more important the the offsets of the residency registers there's something else. So Just return a constant 0 to avoid upsetting userspace tools like powertop. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Explain a bit in the commit message what's going on.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/vlv: honor i915_enable_rc6 boot param on VLVJesse Barnes2013-09-201-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | Disabling it isn't really an option on these platforms, but having it available for power comparisons is useful. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPFBen Widawsky2013-09-195-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We'd only ever used this define to denote whether or not we have the dynamic parity feature (DPF) and never to determine whether or not L3 exists. Baytrail is a good example of where L3 exists, and not DPF. This patch provides clarify in the code for future use cases which might want to actually query whether or not L3 exists. v2: Add /* DPF == dynamic parity feature */ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Do remaps for all contextsBen Widawsky2013-09-194-27/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On both Ivybridge and Haswell, row remapping information is saved and restored with context. This means, we never actually properly supported the l3 remapping because our sysfs interface is asynchronous (and not tied to any context), and the known faulty HW would be reused by the next context to run. Not that due to the asynchronous nature of the sysfs entry, there is no point modifying the registers for the existing context. Instead we set a flag for all contexts to load the correct remapping information on the next run. Interested clients can use debugfs to determine whether or not the row has been remapped. One could propose at this point that we just do the remapping in the kernel. I guess since we have to maintain the sysfs interface anyway, I'm not sure how useful it is, and I do like keeping the policy in userspace; (it wasn't my original decision to make the interface the way it is, so I'm not attached). v2: Force a context switch when we have a remap on the next switch. (Ville) Don't let userspace use the interface with disabled contexts. v3: Don't force a context switch, just let it nop Improper context slice remap initialization, 1<<1 instead of 1<<i, but I rewrote it to avoid a second round of confusion. Error print moved to error path (All Ville) Added a comment on why the slice remap initialization happens. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Keep a list of all contextsBen Widawsky2013-09-194-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I have implemented this patch before without creating a separate list (I'm having trouble finding the links, but the messages ids are: <1364942743-6041-2-git-send-email-ben@bwidawsk.net> <1365118914-15753-9-git-send-email-ben@bwidawsk.net>) However, the code is much simpler to just use a list and it makes the code from the next patch a lot more pretty. As you'll see in the next patch, the reason for this is to be able to specify when a context needs to get L3 remapping. More details there. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make l3 remapping use the ringBen Widawsky2013-09-193-22/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using LRI for setting the remapping registers allows us to stream l3 remapping information. This is necessary to handle per context remaps as we'll see implemented in an upcoming patch. Using the ring also means we don't need to frob the DOP clock gating bits. v2: Add comment about lack of worry for concurrent register access (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Bikeshed the comment a bit by doing a s/XXX/Note - there's nothing to fix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add second slice l3 remappingBen Widawsky2013-09-197-61/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain HSW SKUs have a second bank of L3. This L3 remapping has a separate register set, and interrupt from the first "slice". A slice is simply a term to define some subset of the GPU's l3 cache. This patch implements both the interrupt handler, and ability to communicate with userspace about this second slice. v2: Remove redundant check about non-existent slice. Change warning about interrupts of unknown slices to WARN_ON_ONCE Handle the case where we get 2 slice interrupts concurrently, and switch the tracking of interrupts to be non-destructive (all Ville) Don't enable/mask the second slice parity interrupt for ivb/vlv (even though all docs I can find claim it's rsvd) (Ville + Bryan) Keep BYT excluded from L3 parity v3: Fix the slice = ffs to be decremented by one (found by Ville). When I initially did my testing on the series, I was using 1-based slice counting, so this code was correct. Not sure why my simpler tests that I've been running since then didn't pick it up sooner. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Fix HSW parity testBen Widawsky2013-09-191-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Haswell changed the log registers to be WO, so we can no longer read them to determine the programming (which sucks, see later note). For now, simply use the cached value, and hope HW doesn't screw us over. v2: Simplify the logic to avoid an extra !, remove last, and fix the buffer offset which broke along the rebase (Ville) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441 CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: dump crtc timings from the pipe configDaniel Vetter2013-09-191-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I always get royally confused how a modeline with all zeros could possible pass the paranoid pipe config checker. Until I realize again that we only check the crtc timings. So dump the crtc timings for the adjusted mode. This will be even more important for 3D support where the crtc timings are markedly different from the input modeline if we have frame-by-frame 3d output enabled. Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: register backlight device also when backlight class is a moduleJani Nikula2013-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ville and I were wondering why his laptop was missing the intel_backlight sysfs interface. Turns out we never register it when CONFIG_BACKLIGHT_CLASS_DEVICE=m. This has been broken ever since the i915 native backlight interface was added. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: write D_COMP using the mailboxPaulo Zanoni2013-09-192-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | You can't write it using the MCHBAR mirror, the write will just get dropped. This should make us BSpec-compliant, but there's no real bug I could reproduce that is fixed by this patch. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Fix spelling mistake in the comment that Damien spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: check for more ASLC interruptsPaulo Zanoni2013-09-171-32/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes I see the "non asle set request??" message on my Haswell machine, so I decided to get the spec and see if some bits are missing from the mask. We do have some bits missing from the mask, so this patch adds them, and the corresponding code to print "unsupported" messages just like we do with the other bits we don't support. But I still see the "non asle set request??" message on my machine :( Also use the proper ASLC name to indicate the registers we're talking about. v2: - Properly set the new FAILED bits - Rename the old FAILED bits - Print everything we don't support Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: only report hpd connector status change when it actually changedJani Nikula2013-09-171-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reduces dmesg noise when there's a glitch on the hpd line, or there are more than one connectors on the same hpd line and only one of them changes. While at it, switch to use the friendly status names instead of numbers. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: WARN is the DP aux read or write is too bigPaulo Zanoni2013-09-171-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we control everything and nothing exceeds the current limits, but (i) we never think about these limits when reviewing patches, (ii) not all the callers check the return values and (iii) if we ever hit any of these messages, we'll have to fix the code that added the bad message. The current limit for these messages is 20 since we only have 5 data registers on all the current gens. The checks inside intel_dp_aux_native_{write,read} are to prevent buffer overflows. The check inside intel_dp_aux_ch is to prevent writing past our 5 data registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Convert overlay double wide check over to pipe configVille Syrjälä2013-09-171-4/+1
| | | | | | | | | | | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Fix up pipe vs. double wide confusionVille Syrjälä2013-09-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Double wide mode is only available on pipe A, except on GDG where pipe B is also double wide capable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: pipe_src_w must be even in LVDS dual channel, DVO ganged, and ↵Ville Syrjälä2013-09-171-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | double wide mode Pipe horizontal source size must be even when either LVDS dual channel mode, DVO ganged mode, or pipe double wide mode is used. We must round it down since we can never increase the user specified viewport size. The actual error from an odd pipe source width looks like a diagonal shift, like you might get from a bad stride. v2: s/ganaged/ganged/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Check pixel clock limits on pre-gen4Ville Syrjälä2013-09-171-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't want to try to push the hardware beyond it's capabilities, so check the pixel clock against the display core clock limit. Do it for pre-gen4 for now since that's where we alread have the double wide pixel clock limit check. Let's assume that when double wide mode is enabled the max pixel clock limit is also doubled. FIXME: panel fitter downscaling probably affects the limit on non-pch platforms too, so we'd need another version of ilk_pipe_pixel_rate() to figure that out. FIXME: should check the limits on all platforms. Also sprites affect the max allowed pixel rate on some platforms, so we need to eventually tie all the planes and pipes into one check in the future. But we need plane state pre-compute before that can happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add double_wide readout and checkingVille Syrjälä2013-09-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Read the double wide pipe information from hardware in i9xx_get_pipe_config(), and check it in intel_pipe_config_compare() For gen4+ double_wide is always false so the comparison can be done on all platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Move double wide mode handling into pipe_configVille Syrjälä2013-09-172-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Determine the need for double wide mode already in compute_config stage as we need that information to figure out if horizontal coordinates need to be adjusted. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: garbage-collect vlv refclk functionDaniel Vetter2013-09-171-23/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Simply inline the 100MHz default we're using. Having gunk around that has leftover LVDS support on a platform that just doesn't have this isn't of any use. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Fix cursor visibility checks also for the right/bottom screen edgesVille Syrjälä2013-09-171-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First of all we should not be looking at fb->{width,height} as those do not tell us what the actual pipe size is. Second of all we need to use >= for the comparison. So fix the comparison, and make use of the new pipe_src_{w,h} to determine the real pipe source dimensions. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Fix cursor visibility check with negative coordinatesVille Syrjälä2013-09-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the cursor x coordinate is exactly -cursor_width, the cursor is invisible. And obviously the same holds for the y coordinate and cursor_height. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Document the inteded use of requested_modeVille Syrjälä2013-09-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Try to clarify the purpose of requested_mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: re-layout intel_panel.c to obey 80 char limitDaniel Vetter2013-09-171-64/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Especially intel_gmch_panel_fitting was shifting way too much over the right edge and also was way too long. So extract two helpers, one for gen4+ and one for gen2/3. Now the entire thing is again almost readable ... Spurred by checkpatch freaking out about a Ville's pipeconfig rework in intel_panel.c Otherwise just two lines that needed appropriate breaking. Not functional change in this patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add explicit pipe src size to pipe configVille Syrjälä2013-09-165-58/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. In many places where we end up using pipe source size, we should actually use the primary plane size, but we don't currently store that information explicitly. As long as we treat primaries as full screen only, we can get away with this. Eventually when we move primaries over to drm_plane, we need to fix it all up. v2: Add a comment to explain what pipe_src_{w,h} are Add a note about primary planes to commit message Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use adjusted_mode in DSI PLL calculationsVille Syrjälä2013-09-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | adjusted_mode contains our real timings, not requested_mode. Use the correct thing in DSI PLL code. Also constify adjusted_mode since we don't change it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use pipe config in sprite codeVille Syrjälä2013-09-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than dig up the pipe source size from crtc->mode, use intel_crtc->config.requested_mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make intel_crtc_active() available outside intel_pm.cVille Syrjälä2013-09-164-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move intel_crtc_active() to intel_display.c and make it available elsewhere as well. intel_edp_psr_match_conditions() already has one open coded copy, so replace that one with a call to intel_crtc_active(). v2: Copy paste a big comment from danvet's mail explaining when we can ditch the extra checks Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use adjusted_mode when checking conditions for PSRVille Syrjälä2013-09-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | intel_edp_psr_match_conditions() currently looks at crtc->mode when it really needs to look at adjusted_mode. Fix it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Check the clock from adjusted mode in intel_crtc_active()Ville Syrjälä2013-09-161-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The clock in crtc->mode doesn't necessarily mean anything. Let's look at the clock in adjusted_mode instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use adjusted_mode appropriately when computing watermarksVille Syrjälä2013-09-161-22/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently most of the watermark code looks at crtc->mode which is the user requested mode. The only piece of information there that is relevant is hdisplay, the rest must come from adjusted_mode. Convert all of the code to use requested_mode and adjusted_mode from pipe config appropriately. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use adjusted_mode in intel_update_fbc()Ville Syrjälä2013-09-161-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check the mode flags from the adjusted_mode, not user requested mode. The hdisplay/vdisplay check actually checkes the primary plane size, so those still need to come from the user requested mode. Extract both modes from pipe config instead of the drm_crtc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use adjusted_mode in HDMI 12bpc clock checkVille Syrjälä2013-09-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pixel clock should come from adjusted_mode not requested_mode. In this case the two should be the same as we don't currently overwrite the clock in the case of HDMI. But let's make the code safe against such things happening in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud