- 12 Aug, 2015 3 commits
-
-
Sinclair Yeh authored
This patch fixes two issues. One, when a surface is a proxy for a DMA buffer, it holds an extra reference that needs to be cleared. Two, when fbdev is enabled, we need to unpin the framebuffer before unloading the driver. This is done by a call to vmw_fb_off(). v2 Moved unreferencing surface to from vmw_framebuffer_surface_destroy() to vmw_kms_new_framebuffer() Added "struct vmw_framebuffer *vfb = NULL;" to silence a compiler warning. Removed error checking after calling vmw_surface/dmabuf_reference() Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Thomas Hellstrom authored
On older hardware, texture max width and height is not available, so set it to something reasonable, like 8192. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Sinclair Yeh authored
For a Screen Target capable display device, the display topology is limited by SVGA_REG_MAX_PRIMARY_BOUNDING_BOX_MEM. Two values are checked against this limit: 1. Size of the bounding box enclosing all the displays, and 2. Size of the total number of displays, e.g. framebuffers The limitations above mean we do not have exact max width and height for the topology. The best current option is to set those to the maximum texture width/height. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
-
- 05 Aug, 2015 25 commits
-
-
Thomas Hellstrom authored
Reported by Intel's kbuild robot. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
-
Thomas Hellstrom authored
When the size of dma_addr_t was 32 bits, the compiler warned about the size of the 32 bit shift being larger than the size of the data type. Reported by Intel's kbuild robot. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
-
Thomas Hellstrom authored
We're giving up all attempts to keep cpu- and device byte ordering separate. This silences sparse when compiled using make C=2 CF="-D__CHECK_ENDIAN__" Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Thomas Hellstrom authored
The preferred mode typically didn't end up first, since the function drm_mode_connector_list_update() reordered the modes. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
It somehow got lost in a rewrite. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
With screen targets the old legacy display system fbdev doesn't work satisfactory anymore. At best the resolution is severely restricted. Therefore implement fbdev on top of the kms system. With this change, fbdev will be using whatever KMS backend is chosen. There are helpers available for this, so in the future we'd probably want to implement the helper callbacks instead of calling into our KMS implementation directly. v2: Make sure we take the mode_config mutex around modesetting, Also clear the initial framebuffer using vzalloc instead of vmalloc. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
The kernel interface is needed for fbdev, and needs to be free from a file_priv member. To accomplish this, remove the fb surface mutex and list which isn't used anymore, anyway. Finally, make the pin() and unpin() pin the framebuffer for all display system backends, so that fbdev can pin its framebuffer before mapping it. v2: Address review comments: - Fix vmw_framebuffer_unpin() to handle also the surface framebuffer case. - Fix vmw_kms_new_framebuffer() to actually use the only_2d parameter. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
If the command buffer pool is out of space, the code waits until space is available. However since the condition code tries to allocate a range manager node while !TASK_RUNNING we get a kernel warning. Avoid this by pre-allocating the mm node. This will also probably be more efficient. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
Also implements the missing readback function and fixes page flip in case of no event. v2: - Adapt to the work done for screen targets for 2d, in particular Handle proxy surface updates. - Remove execbuf quirks since we now use fifo reserve / commit. - Revert the initial placement of vmw dma buffers. v3: Address review comments. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
This makes it possible to use the same function for surface dirty and present. Also fixes page flip without events. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
We need to make the dirty- and readback functions callable without a struct drm_file pointer. We also need to unify the handling of dirty- and readback cliprects that are now implemented in various places across the kms system, som add helpers to facilitate this. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
v2: Fix dma buffer validation on resource pinning. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Sinclair Yeh authored
This patch address the following underlying issues with SurfaceDMA * SurfaceDMA command does not work in a 2D VM, but we can wrap a proxy surface around the same DMA buffer and use the SurfaceCopy command which does work in a 2D VM. * Wrapping a DMA buffer with a proxy surface also gives us an added optimization path for the case when the DMA buf dimensions match the mode. In this case, the DMA buf can be pinned as the display surface, saving an extra copy. This only works in a 2D VM because we won't be doing any rendering operations directly to the display surface. v2 * Moved is_dmabuf_proxy field to vmw_framebuffer_surface * Undone coding style changes * Addressed other issues from review Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Sinclair Yeh authored
Add support for the screen target device interface. Add a getparam parameter and bump minor to signal availability. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Thomas Hellstrom authored
For certain surface copies, we don't have a user space handle for the destination surface. In such cases, we are going to trust that our caller is giving us the right surface ID. To do this case, we created a quirk flag that may be useful in the future for handling other cases. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Sinclair Yeh <syeh@vmware.com>
-
Sinclair Yeh authored
Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Sinclair Yeh authored
Refactored vmw_gb_surface_define_ioctl() and made the surface definition part a separate function. This way other parts of vmwgfx can use it to allocate kernel-visible GB surfaces. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Sinclair Yeh authored
Update device definition headers to support screen targets. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Thomas Hellstrom authored
For screen targets it appears we need to pin surfaces while they are bound as screen targets, so add a small interface to do that. v2: Always increase pin_count on pin. v3: Add missing reservation sem. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
Fix a circular locking dependency between struct vmw_overlay::mutex and struct vmw_private::reservation_sem Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
-
Thomas Hellstrom authored
Add command buffer support. Currently we don't implement preemption or fancy error handling. Tested with a couple of mesa-demos, compiz/unity and viewperf maya-03. v2: - Synchronize with pending work at command buffer manager takedown. - Add an interface to flush the current command buffer for latency-critical command batches and apply it to framebuffer dirtying. v3: - Minor fixes of definitions and typos to address reviews. - Removed new or moved branch predictor hints. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
Don't fence and free the BO if command submission fails. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-
Thomas Hellstrom authored
This commit reworks device initialization so that we always enable the FIFO at driver load, deferring SVGA enable until either first modeset or fbdev enable. This should always leave the fifo properly enabled for render- and control nodes. In addition, *) We disable the use of VRAM when SVGA is not enabled. *) We simplify PM support so that we only throw out resources on hibernate, not on suspend, since the device keeps its state on suspend. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
-
Thomas Hellstrom authored
A regression introduced when the master ttm lock was split into two. Reported-and-tested-by: Brian Paul <brianp@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
-
- 24 Jul, 2015 5 commits
-
-
Dave Airlie authored
Merge tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-next connector hotplug locking cleanup and fixes to make it save against atomic. Note that because of depencies this is based on top of the drm-intel-next pull, so that one needs to go in before this one. I've also thrown in the mode_group removal on top since it's defunct, never worked really, no one seems to care and the code can be resurrected easily. * tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel: drm: gc now dead mode_group code drm: Stop filtering according to mode_group in getresources drm: Roll out drm_for_each_{plane,crtc,encoder} drm/cma-helper: Fix locking in drm_fb_cma_debugfs_show drm: Roll out drm_for_each_connector more drm: Amend connector list locking rules drm/radeon: Take all modeset locks for DP MST hotplug drm/i915: Take all modeset locks for DP MST hotplug drm: Check locking in drm_for_each_fb drm/i915: Use drm_for_each_fb in i915_debugfs.c drm: Check locking in drm_for_each_connector drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors drm/probe-helper: Grab mode_config.mutex in poll_init/enable drm: Add modeset object iterators drm: Simplify drm_for_each_legacy_plane arguments
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
crystalcove pmic support from Shobhit. Patch series has all acks/r-bs from other mainainers so ok to pull into drm-next. But I'm cc'ing all other maintainers as fyi and in case they want to pull it into their trees too to avoid conflicts. * tag 'topic/crc-pmic-2015-07-23' of git://anongit.freedesktop.org/drm-intel: mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled drm/i915: Backlight control using CRC PMIC based PWM driver drm/i915: Use the CRC gpio for panel enable/disable pwm: crc: Add Crystalcove (CRC) PWM driver mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal gpiolib: Add support for removing registered consumer lookup table
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
- prelim hw support dropped for skl after Damien fixed an ABI issue around planes - legacy modesetting is done using atomic infrastructure now (Maarten)! - more gen9 workarounds (Arun&Nick) - MOCS programming (cache control for better performance) for skl/bxt - vlv/chv dpll improvements (Ville) - PSR fixes from Rodrigo - fbc improvements from Paulo - plumb requests into execlist submit functions (Mika) - opregion code cleanup from Jani - resource streamer support from Abdiel for mesa - final fixes for 12bpc hdmi + enabling support from Ville drm-intel-next-2015-07-03: - dsi improvements (Gaurav) - bxt ddi dpll hw state readout (Imre) - chv dvfs support and overall wm improvements for both vlv and chv (Ville) - ppgtt polish from Mika and Michel - cdclk support for bxt (Bob Pauwe) - make frontbuffer tracking more precise - OLR removal (John Harrison) - per-ctx WA batch buffer support (Arun Siluvery) - remvoe KMS Kconfig option (Chris) - more hpd handling refactoring from Jani - use atomic states throughout modeset code and integrate with atomic plane update (Maarten) drm-intel-next-2015-06-19: - refactoring hpd irq handlers (Jani) - polish skl dpll code a bit (Damien) - dynamic cdclk adjustement (Ville & Mika) - fix up 12bpc hdmi and enable it for real again (Ville) - extend hsw cmd parser to be useful for atomic configuration (Franscico Jerez) - even more atomic conversion and rolling state handling out across modeset code from Maarten & Ander - fix DRRS idleness detection (Ramalingam) - clean up dsp address alignment handling (Ville) - some fbc cleanup patches from Paulo - prevent hard-hangs when trying to reset the gpu on skl (Mika) * tag 'drm-intel-next-2015-07-17' of git://anongit.freedesktop.org/drm-intel: (386 commits) drm/i915: Update DRIVER_DATE to 20150717 drm/i915/skl: Drop the preliminary_hw_support flag drm/i915/skl: Don't expose the top most plane on gen9 display drm/i915: Fix divide by zero on watermark update drm/i915: Invert fastboot check drm/i915: Clarify logic for initial modeset drm/i915: Unconditionally check gmch pfit state drm/i915: always disable irqs in intel_pipe_update_start drm/i915: Remove use of runtime pm in atomic commit functions drm/i915: Call plane update functions directly from intel_atomic_commit. drm/i915: Use full atomic modeset. drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround drm/i915: Enable WA batch buffers for Gen9 drm/i915/gen9: Implement WaDisableKillLogic for gen 9 drm/i915: Use expcitly fixed type in compat32 structs drm/i915: Fix noatomic crtc disabling, v2. drm/i915: fill in more mode members drm/i915: Added BXT check in HAS_CORE_RING_FREQ macro ...
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Update drm-misc pull request since the first one didn't go in yet. Few atomic helper patches, rejecting some old dri1 crap for modern drivers and a few trivial things on top. * tag 'topic/drm-misc-2015-07-23' of git://anongit.freedesktop.org/drm-intel: drm/mgag200: remove unneeded variable drm/mgag200: remove unused variables drm/atomic: Only update crtc->x/y if it's part of the state, v2. drm/fb: drop panic handling drm: Fix warning with make xmldocs caused by drm_irq.c drm/gem: rip out drm vma accounting for gem mmaps drm/fourcc: Add formats R8, RG88, GR88 drm/atomic: Cleanup on error properly in the atomic ioctl. drm: Update plane->fb also for page_flip drm: remove redundant code form drm_ioc32.c drm: reset empty state in transitional helpers drm/crtc-helper: Fixup error handling in drm_helper_crtc_mode_set drm/atomic: Update old_fb after setting a property. drm: Remove useless blank line drm: Reject DRI1 hw lock ioctl functions for kms drivers drm: Convert drm_legacy_ctxbitmap_init to void return type drm: Turn off Legacy Context Functions
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
- Add Carrizo support for amdkfd, using the new amdgpu driver as the relevant kgd. The support includes interfaces with amdgpu both for gfx7 (Kaveri) and gfx8 (Carrizo). However, gfx7 interface is used for debugging purposes only, so amdkfd defaults to using radeon when Kaveri is installed. I would like to note that no new IOCTLs are being introduced, and there is no change in the current IOCTLs, as they are suited both for gfx7 and gfx8. * tag 'drm-amdkfd-next-2015-07-20' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: Set correct doorbell packet type for Carrizo drm/amdkfd: Use generic defines in new amd headers drm/amdkfd: Implement create_map_queues() for Carrizo drm/amdkfd: fix runlist length calculation drm/amdkfd: Add support for VI in DQM drm/amdkfd: add support for VI in MQD manager drm/amdkfd: add CP HWS packet headers for VI drm/amdkfd: add supported CZ devices PCI IDs to amdkfd drm/amdkfd: Add dependency of DRM_AMDGPU to Kconfig drm/amdgpu: Add amdgpu <--> amdkfd gfx8 interface drm/amdgpu: add amdgpu <--> amdkfd gfx7 interface drm/amdgpu: Add H/W agnostic amdgpu <--> amdkfd interface drm/radeon: Modify kgd_engine_type enum to match CZ
-
- 22 Jul, 2015 7 commits
-
-
Daniel Vetter authored
Two nice things here: - drm_dev_register will truly register everything in the right order if the driver doesn't have a ->load callback. Before this we had to init the primary mode_group after the device nodes where already registered. - Less things to keep track of when reworking the connector locking, yay! Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
It's been dead code since forever since mode groups haven't ever been implemented. On top of that it's also been non-functional since we only ever filtered the getresources ioctl and not any of the others nor the mode object lookup code. Given overwhelming evidence it looks like this isn't a feature we need, hence remove it. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Remaining manual work in the drm core&helpers. Nothing special here, no surprises. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
This function takes two locks, both of them the wrong ones. This wasn't an oversight from my fb locking rework since both patches landed in parallel. We really only need fb_lock when walking that list, since everything we can reach from that is refcounted properly already. v2: Drop unused dev spotted by 0day. Cc: Rob Clark <robdclark@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Now that we also grab the connection_mutex and so fixed the race with atomic modeset we can use the iterator there too. The other special case is drm_connector_unplug_all which would have a locking inversion with the sysfs store/show functions if we'd grab the mode_config.mutex around the unplug. We could just grab connection_mutex instead, but that's a bit too much a dirty trick for my taste. Also it's only used by udl, which doesn't do any other kind of connector hotplugging, so should be race-free. Hence just stick with a comment for now. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Now that dp mst hotplug takes all locks we can amend the locking rules for the iterators. This is needed before we can roll these out in the atomic code to avoid getting burried in WARNINGs. v2: Rebase onto the extracted list locking assert and add a comment to explain the rules. v3: Fixup German->English translation fail in the comment. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Similar with the i915 take all modeset locks for mst hotplug. This is needed to make sure radeon holds both mode_config.mutex and mode_config.connection_mutex when updating the connector_list, which is the new (interim) locking regime we want for that. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-