summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2014-11-20drm/atomic: Ensure that drm_connector_index is stableDaniel Vetter
I've totally forgotten that with DP MST connectors can now be hotplugged. And failed to adapt Rob's drm_atomic_state code (which predates connector hotplugging) to the new realities. The first step is to make sure that the connector indices used to access the arrays of pointers are stable. The connection mutex gives us enough guarantees for that, which means we won't unecessarily block on concurrent modesets or background probing. So add a locking WARN_ON and shuffle the code slightly to make sure we always hold the right lock. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/irq: BUG_ON() -> WARN_ON()Rob Clark
Let's make things a bit easier to debug when things go bad (potentially under console_lock). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/ttm: Avoid memory allocation from shrinker functions.Tetsuo Handa
Andrew Morton wrote: > On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > > Andrew Morton wrote: > > > Poor ttm guys - this is a bit of a trap we set for them. > > > > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.") > > changed to use sc->gfp_mask rather than GFP_KERNEL. > > > > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), > > - GFP_KERNEL); > > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp); > > > > But this bug is caused by sc->gfp_mask containing some flags which are not > > in GFP_KERNEL, right? Then, I think > > > > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp); > > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL); > > > > would hide this bug. > > > > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag) > > Well no - ttm_page_pool_free() should stop calling kmalloc altogether. > Just do > > struct page *pages_to_free[16]; > > and rework the code to free 16 pages at a time. Easy. Well, ttm code wants to process 512 pages at a time for performance. Memory footprint increased by 512 * sizeof(struct page *) buffer is only 4096 bytes. What about using static buffer like below? ---------- >From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Thu, 13 Nov 2014 22:21:54 +0900 Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions. Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags which are not in GFP_KERNEL. https://bugzilla.kernel.org/show_bug.cgi?id=87891 Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would avoid the BUG_ON(), but avoiding memory allocation from shrinker function is better and reliable fix. Shrinker function is already serialized by global lock, and clean up function is called after shrinker function is unregistered. Thus, we can use static buffer when called from shrinker function and clean up function. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> [2.6.35+] Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm: remove unnecessary sizeof(u8)Fabian Frederick
sizeof(u8) is always 1. Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm: omapdrm: remove unused variableBoris BREZILLON
Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change drm_flip_work_init prototype" changed the drm_flip_work_init prototype to a void function, which makes 'ret' an unused variable. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: add page_flipGerd Hoffmann
Implement crtc page_flip callback for bochsdrm. The qemu stdvga has no vblank signaling, so we have to fake it. We do so by instantly calling drm_send_vblank_event. Tested with kmscon. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: fix bochsdrmfb mmapGerd Hoffmann
Remove the mapping offset from the bo backing the fbdev framebuffer. Wire up fbdev mmap function to map the backing bo using ttm_fbdev_mmap. With that patch in place mmap(/dev/fb0) works as expected. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: add endian switching supportGerd Hoffmann
Recently (qemu 2.2+) the qemu stdvga got a register to switch the vga framebuffer endianness. This patch adds code to explicitly set the endianness of the framebuffer. In most cases this has no effect as the default is guest architecture endianness. It is needed though in case a architecture supports both big and little endian, i.e. for ppc64le. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: little cleanupGerd Hoffmann
Drop some leftover, commented code. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-19drm/i915: No-Op enter/leave vt gem ioctlDaniel Vetter
We've killed ums support by now, it's time to reap the benefits. This one here is getting in the way of doing some ring init cleanup. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19drm/i915: Drop checks for initializationDaniel Vetter
KMS always intializes, this was only a valid check when userspace was still in control of the kernel driver. v2: Comment that we outright reject all dri1/ums params. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: Replace dri1 functions with drm_noopDaniel Vetter
Whether we'll reject them or no-op doesn't really matter ... Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: Remove DRI1 ring accessors and APIChris Wilson
With the deprecation of UMS, and by association DRI1, we have a tough choice when updating the ring access routines. We either rewrite the DRI1 routines blindly without testing (so likely to be broken) or take the liberty of declaring them no longer supported and remove them entirely. This takes the latter approach. v2: Also remove the DRI1 sarea updates Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fix rebase conflicts.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demandThomas Daniel
Same as with the context, pinning to GGTT regardless is harmful (it badly fragments the GGTT and can even exhaust it). Unfortunately, this case is also more complex than the previous one because we need to map and access the ringbuffer in several places along the execbuffer path (and we cannot make do by leaving the default ringbuffer pinned, as before). Also, the context object itself contains a pointer to the ringbuffer address that we have to keep updated if we are going to allow the ringbuffer to move around. v2: Same as with the context pinning, we cannot really do it during an interrupt. Also, pin the default ringbuffers objects regardless (makes error capture a lot easier). v3: Rebased. Take a pin reference of the ringbuffer for each item in the execlist request queue because the hardware may still be using the ringbuffer after the MI_USER_INTERRUPT to notify the seqno update is executed. The ringbuffer must remain pinned until the context save is complete. No longer pin and unpin ringbuffer in populate_lr_context() - this transient address is meaningless and the pinning can cause a sleep while atomic. v4: Moved ringbuffer pin and unpin into the lr_context_pin functions. Downgraded pinning check BUG_ONs to WARN_ONs. v5: Reinstated WARN_ONs for unexpected execlist states. Removed unused variable. Issue: VIZ-4277 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915/bdw: Pin the context backing objects to GGTT on-demandOscar Mateo
Up until now, we have pinned every logical ring context backing object during creation, and left it pinned until destruction. This made my life easier, but it's a harmful thing to do, because we cause fragmentation of the GGTT (and, eventually, we would run out of space). This patch makes the pinning on-demand: the backing objects of the two contexts that are written to the ELSP are pinned right before submission and unpinned once the hardware is done with them. The only context that is still pinned regardless is the global default one, so that the HWS can still be accessed in the same way (ring->status_page). v2: In the early version of this patch, we were pinning the context as we put it into the ELSP: on the one hand, this is very efficient because only a maximum two contexts are pinned at any given time, but on the other hand, we cannot really pin in interrupt time :( v3: Use a mutex rather than atomic_t to protect pin count to avoid races. Do not unpin default context in free_request. v4: Break out pin and unpin into functions. Fix style problems reported by checkpatch v5: Remove unpin_lock as all pinning and unpinning is done with the struct mutex already locked. Add WARN_ONs to make sure this is the case in future. Issue: VIZ-4277 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915/bdw: Clean up execlist queue items in retire_workThomas Daniel
No longer create a work item to clean each execlist queue item. Instead, move retired execlist requests to a queue and clean up the items during retire_requests. v2: Fix legacy ring path broken during overzealous cleanup v3: Update idle detection to take execlists queue into account v4: Grab execlist lock when checking queue state v5: Fix leaking requests by freeing in execlists_retire_requests. Issue: VIZ-4274 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19assorted conversions to %p[dD]Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-11-19Merge tag 'drm-intel-fixes-2014-11-19' into drm-intel-next-queuedDaniel Vetter
So with all the code movement and extraction in intel_pm.c in -next git is hopelessly confused with commit 2208d655a91f9879bd9a39ff9df05dd668b3512c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 14 09:25:29 2014 +0100 drm/i915: drop WaSetupGtModeTdRowDispatch:snb from -fixes. Worse even small changes in -next move around the conflict context so rerere is equally useless. Let's just backmerge and be done with it. Conflicts: drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_pm.c Except for git getting lost no tricky conflicts really. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19drm/i915: disable rps irqs earlier during suspend/unloadImre Deak
After the previous patch RPS disabling doesn't depend any more on the first level interrupts being disabled, so we can move it everywhere earlier. Doing so let's us think about the uninitialization steps afterwards independently of any asynchronous RPS events that can happen atm. It also makes the system/runtime suspend time RPS disabling more uniform. Finally this gets rid of the WARN in intel_suspend_gt_powersave(), which we can hit if a final RPS work runs after we disabled the first level interrupts. Testcase: igt/pm_rpm Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: sanitize rps irq disablingImre Deak
When disabling the RPS interrupts there is a tricky dependency between the thread disabling the interrupts, the RPS interrupt handler and the corresponding RPS work. The RPS work can reenable the interrupts, so there is no straightforward order in the disabling thread to (1) make sure that any RPS work is flushed and to (2) disable all RPS interrupts. Currently this is solved by masking the interrupts using two separate mask registers (first level display IMR and PM IMR) and doing the disabling when all first level interrupts are disabled. This works, but the requirement to run with all first level interrupts disabled is unnecessary making the suspend / unload time ordering of RPS disabling wrt. other unitialization steps difficult and error prone. Removing this restriction allows us to disable RPS early during suspend / unload and forget about it for the rest of the sequence. By adding a more explicit method for avoiding the above race, it also becomes easier to prove its correctness. Finally currently we can hit the WARN in snb_update_pm_irq(), when a final RPS work runs with the first level interrupts already disabled. This won't lead to any problem (due to the separate interrupt masks), but with the change in this and the next patch we can get rid of the WARN, while leaving it in place for other scenarios. To address the above points, add a new RPS interrupts_enabled flag and use this during RPS disabling to avoid requeuing the RPS work and reenabling of the RPS interrupts. Since the interrupt disabling happens now in intel_suspend_gt_powersave(), we will disable RPS interrupts explicitly during suspend (and not just through the first level mask), but there is no problem doing so, it's also more consistent and allows us to unify more of the RPS disabling during suspend and unload time in the next patch. v2/v3: - rebase on patch "drm/i915: move rps irq disable one level up" in the patchset Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: sanitize rps irq enablingImre Deak
Atm we first enable the RPS interrupts then we clear any pending ones. By this we could lose an interrupt arriving after we unmasked it. This may not be a problem as the caller should handle such a race, but logic still calls for the opposite order. Also we can delay enabling the interrupts until after all the RPS initialization is ready with the following order: 1. disable left-over RPS (earlier via intel_uncore_sanitize) 2. clear any pending RPS interrupts 3. initialize RPS 4. enable RPS interrupts This also allows us to do the 2. and 4. step the same way for all platforms, so let's follow this order to simplifying things. Also make sure any queued interrupts are also cleared. v2: - rebase on the GEN9 patches where we don't support RPS yet, so we musn't enable RPS interrupts on it (Paulo) v3: - avoid enabling RPS interrupts on GEN>9 too (Paulo) - clarify the RPS init sequence in the log message (Chris) - add POSTING_READ to gen6_reset_rps_interrupts() (Paulo) - WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts() (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: move rps irq disable one level upImre Deak
We disable the RPS interrupts for all platforms at the same spot, so move it one level up in the callstack to simplify things. No functional change. v2: - rebase on the GEN9 patches where RPS isn't supported yet, so we don't need to disable RPS interrupts on it (Paulo) v3: - avoid disabling the interrupts on GEN>9 too (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: WARN if we receive any rps interrupts on gen>9Imre Deak
This extends commit 132f3f1767dbabfb01f3c9bd63098c65d91eeac9 Author: Imre Deak <imre.deak@intel.com> Date: Mon Nov 10 15:34:33 2014 +0200 drm/i915: WARN if we receive any gen9 rps interrupts to GEN>9 platforms as suggested by Paulo. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: Don't store panning coordinates as 16.16 fixed pointMatt Roper
When using the universal plane interface, the source rectangle coordinates define the panning offset for the primary plane, which needs to be stored in crtc->{x,y}. The original universal plane code negelected to set these panning offset fields, which was partially remedied in: commit ccc759dc2a0214fd8b65ed4ebe78050874a67f94 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 24 14:20:22 2014 -0300 drm/i915: Merge of visible and !visible paths for primary planes However the plane source coordinates are provided in 16.16 fixed point format and the above commit forgot to convert back to integer coordinates before saving the values. When we replace intel_pipe_set_base() with plane->funcs->update_plane() in a future patch, this bug becomes visible via the set_config entrypoint as well as update_plane. Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Testcase: igt/kms_plane Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915/ddi: set has_infoframe flag on DDI too v2Jesse Barnes
Just like we do in the HDMI code, set the infoframe flag if we detect that infoframes are enabled. v2: check for actual infoframe status as in hdmi code (Daniel) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: Extend pcode mailbox interfaceTom O'Rourke
In sandybridge_pcode_read and sandybridge_pcode_write, extend the mbox parameter from u8 to u32. On Haswell and Sandybridge, bits 7:0 encode the mailbox command and bits 28:8 are used for address control for specific commands. Based on suggestion from Ville Syrjälä. Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: Tune down sink crc timeout dmesg outputDaniel Vetter
For whatever reasons this can happen. For real testcases the test will notice the -EIO and fall over, but we also have some testcases that just read all debugfs files. And that shouldn't cause dmesg spam. So tune it down a bit so that we still have the information for debugging. And change the errno so that real testcases can easily differentiate. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84890 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19drm/i915: Don't continually defer the hangcheckChris Wilson
With multiple rings, we may continue to render on the blitter whilst executing an infinite shader on the render ring. As we currently, rearm the timer with each execbuf, in this scenario the hangcheck will never fire and we will never detect the lockup on the render ring. Instead, only arm the timer once per hangcheck, so that hangcheck runs more frequently. v2: Rearrange code to avoid triggering a BUG_ON in add_timer from softirq context. Testcase: igt/gem_reset_stats/defer-hangcheck* Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86225 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-18drm/i915: Don't print header in error state for non-existing CSDaniel Vetter
This goes back to commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Thu Jan 30 00:19:38 2014 -0800 drm/i915: Move per ring error state to ring_error Spotted while reading error states. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-18amdkfd: init aperture once per processAlexey Skidanov
Since the user space may call open() more that once from the same process, the aperture initialization should be moved from kfd_open() Signed-off-by: Alexey Skidanov <Alexey.Skidanov@amd.com> Reviewed-by: Oded Gabbay <oded.gabbay@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-18drm/i915/audio: fix monitor presence indication after disableJani Nikula
Indicate the monitor has been disconnected on disable. The regression has been introduced in commit 5fad84a7530f8e7664cdc6f490cb90653fed1266 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Nov 4 10:30:23 2014 +0200 drm/i915: rewrite hsw/bdw audio codec enable/disable sequences Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86424 Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-18drm/i915/ddi: add break in DDI mode select switchJesse Barnes
The lack of a break here wasn't for falling through to some other important code, so made me do a double take. Add a break just to make things a little less confusing. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-18drm/i915: Drop return value from lrc_setup_hardware_status_pageDaniel Vetter
kmap never fails. Spotted-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-17drm/i915: Propagate invalid setcrtc cloning errors back to userspaceMatt Roper
When invalid cloning configurations were detected during modeset, we never copied the error code into the return value variable, leading us to return 0 (success) to userspace. This regression has been introduced in commit 50f5275698df4490046cc5b4ed2018abb642a803 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 7 13:11:00 2014 -0800 drm/i915: use compute_config in set_config v4 Testcase: igt/kms_setmode Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86226 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915/skl: Use the pipe config DPLL tracking to query the link clockDamien Lespiau
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915/skl: Set the eDP link rate on DPLL0Damien Lespiau
On SKL DPLL0 is used to derive CDCLK but can also be used to drive an eDP port (as long as we don't want SSC). DPLL0 is special enough to not be handled by the shared DPLL framework (drives CDCLK, not supposed to enable the HDMI mode), So we need to compute the configuration separately from the other DPLLs. Note that we don't need to reprogram DPLL0 (which would mean bringing down CDCLK) to support the various eDP 1.3 link rates as they all share the same VCO (8100). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Add PSR docbookRodrigo Vivi
Let's document PSR a bit. No functional changes. v2: Add actual DocBook entry and accept Daniel's improvements. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Introduce intel_psr.cRodrigo Vivi
No functional changes. Just cleaning and reorganizing it. v2: Rebase it puting it to begin of psr rework. This helps to blame easily at least latest changes. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Make dp aux pack/unpack public outside intel_dp.cRodrigo Vivi
No functional change. Just making it public for use outside intel_dp.c Allowing split psr functions. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Drop WaRsForcewakeWaitTC0:vlvVille Syrjälä
GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give 0x0 no matter what the state of the render and media wells. There was also some hint in the Gunit HAS that thread status not being needed on VLV, and hence dropped when bringing stuff over from the IVB design. Not really a definite comment about the specific register itself though. Also the w/a itself is no longer listed for VLV in the database. It was there some time ago in the past, but I guess someone figured out the mistake and dropped it. So let's just drop it from the code as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Drop the HSW special case from __gen6_gt_wait_for_thread_c0()Ville Syrjälä
Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same meaning since SNB. So treating them as something special for HSW doesn't make sense to me. Also the bits *seem* to work exactly the same way on IVB, HSW GT2 and HSW GT3. At least intel_reg_read gives the identical results on all platforms with and without forcewake. Also the HSW PM guide rev 0.99 (ww05 2013) doesn't say anything about those bits. It just says to poll for bits [2:0]. As does the more recent BDW PM guide. So just drop the HSW special case and treat all platforms the same way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915/skl: Remove spurious warn in get_ddi_pll()Damien Lespiau
When reading out a DDI config that uses a PLL that is not part of the shared_dpll scheme (DPLL0), it's totally normal to end up in the default: case of that switch. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Change CHV SKU400 GPU freq divider to 10Ville Syrjälä
According to "Cherryview_GFXclocks_y14w36d1.xlsx" the GPU frequency divider should be 10 in when the CZ clock is 400 MHz. Change the code to agree so that we report the correct frequencies. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Add missing newline to 'DDR speed' debug messagesVille Syrjälä
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Refactor vlv/chv GPU frequency divider setupVille Syrjälä
The divider used in the GPU frequency calculations is compatible between vlv and chv. vlv just wants doubled values compared to chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Improve PCBR debug informationVille Syrjälä
Always print the final PCBR register value on both vlv and chv, and also tell us whether the BIOS was a good citizen or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Warn if GPLL isn't used on vlv/chvVille Syrjälä
Our freq<->opcode conversions assume that GPLL is always used. Apparently that should be the case always, but let's scream if we ever encounter something different. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Add a name for the Punit GPLLENABLE bitVille Syrjälä
Remove the magic number for the GPLLENABLE bit by adding a name for it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Silence valleyview_set_rps()Ville Syrjälä
Even with the rps debug messages signficantly recuced by commit 67956867aa07c59d6d83628bbc9ee4bd9799a1e1 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Sep 2 15:12:17 2014 +0300 drm/i915: Don't spam dmesg with rps messages on vlv/chv we still get an inordinate amount of spam from this. Just kill the debug print. If someone wants to observe it they can just use the tracepoint. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Kick fbdev before vgaconDaniel Vetter
It's magic, but it seems to work. This fixes a regression introduced in commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 8 10:02:43 2014 +0200 drm/i915: Only unbind vgacon, not other console drivers My best guess is that the vga fbdev driver falls over if we rip out parts of vgacon. Hooray. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439 Cc: stable@vger.kernel.org (v3.16+) Reported-and-tested-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit (git 2.34.1) at 2025-09-13 20:04:26 +0000