aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* drm: add drm_dev_alloc() helperDavid Herrmann2013-10-09
| | | | | | | | | | | | | Instead of managing device allocation+initialization in each bus-driver, we should do that in a central place. drm_fill_in_dev() already does most of it, but also requires the global drm lock for partial AGP device registration. Split both apart so we have a clean device initialization/allocation phase, and a registration phase. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: kill ->gem_init_object() and friendsDavid Herrmann2013-10-09
| | | | | | | | | | | | | | | | | | | | | All drivers embed gem-objects into their own buffer objects. There is no reason to keep drm_gem_object_alloc(), gem->driver_private and ->gem_init_object() anymore. New drivers are highly encouraged to do the same. There is no benefit in allocating gem-objects separately. Cc: Dave Airlie <airlied@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Ben Skeggs <skeggsb@gmail.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau: embed gem object in nouveau_boDavid Herrmann2013-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no reason to keep the gem object separately allocated. nouveau is the last user of gem_obj->driver_private, so if we embed it, we can get rid of 8bytes per gem-object. The implementation follows the radeon driver. bo->gem is only valid, iff the bo was created via the gem helpers _and_ iff the user holds a valid gem reference. That is, as the gem object holds a reference to the nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not guaranteed to also hold a gem reference. The gem object might get destroyed after the last user drops the gem-ref via drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a gem-reference. For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is valid. However, this shouldn't be used for real functionality to avoid gem-internal dependencies. Note that the implementation follows the previous style. However, we no longer can check for bo->gem != NULL to test for a valid gem object. This wasn't done before, so we should be safe now. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Remove unused variables in drm_fb_helper_hotplug_event()Lespiau, Damien2013-10-01
| | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Remove unused variable in drm_pick_crtcs()Lespiau, Damien2013-10-01
| | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Remove unused variable in drm_fb_helper_pan_display()Lespiau, Damien2013-10-01
| | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Remove unused variable in drm_prime_sg_to_page_addr_arrays()Lespiau, Damien2013-10-01
| | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Remove unused variable in drm_global_item_ref()Lespiau, Damien2013-10-01
| | | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocationAlex Deucher2013-10-01
| | | | | | | | Return -ENOMEM if the allocation fails. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/dp: constify DP DPCD helpersJani Nikula2013-10-01
| | | | | | | | | None of the DP DPCD helpers need to modify the DPCD. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/exynos: use drm_edid_duplicateJani Nikula2013-10-01
| | | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: add drm_edid_duplicateJani Nikula2013-09-30
| | | | | | | We have some code duplication related to EDID duplication. Add a helper. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915/dp: downstream port capabilities are not present in DPCD 1.0Jani Nikula2013-09-30
| | | | | | | | | | | We haven't read the downstream port caps for DPCD 1.0, so don't use them. v2: use defines for DPCD 1.0 downstream port types Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/dp: add defines for downstream port typesJani Nikula2013-09-30
| | | | | | | | | | | | Detailed cap info at address 80h is not available with DPCD ver 1.0. Whether such devices exist in the wild I don't know, but there should be no harm done in having the defines for downstream port 0 in address 05h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'drm-intel-next-2013-09-21-merged' of ↵Dave Airlie2013-09-30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-24
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20
| | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | 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-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-04 12:59:47 -0500