- Jun 04, 2015
-
-
Alex Deucher authored
These are register headers for the SMU (System Management Unit) block on the GPU. Acked-by:
Christian König <christian.koenig@amd.com> Acked-by:
Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
These are register headers for the OSS (OS Services) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the OSS (OS Services) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the OSS (OS Services) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the OSS (OS Services) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the GMC (Graphics Memory Controller) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the GMC (Graphics Memory Controller) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the GMC (Graphics Memory Controller) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the GMC (Graphics Memory Controller) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the GCA (Graphics and Compute Array) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the GCA (Graphics and Compute Array) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the GCA (Graphics and Compute Array) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the DCE (Display and Composition Engine) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the DCE (Display and Composition Engine) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the DCE (Display and Composition Engine) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the BIF (Bus InterFace) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the BIF (Bus InterFace) block on the GPU. Acked-by:
-
Alex Deucher authored
These are register headers for the BIF (Bus InterFace) block on the GPU. Acked-by:
-
git://git.kraxel.org/linuxDave Airlie authored
Yay, thanks to Gerd for pull this together. * 'virtio-gpu-drm-next' of git://git.kraxel.org/linux: Add MAINTAINERS entry for virtio-gpu. Add virtio gpu driver. drm_vblank_get: don't WARN_ON in case vblanks are not initialized break kconfig dependency loop
-
https://github.com/jsarha/linuxDave Airlie authored
Please pull the contents of "Use DRM component API in tilcdc to connect to tda998x" patch series. * 'linux-4.1.0-rc5-tilcdc-refactor' of https://github.com/jsarha/linux: drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support drm/tilcdc: use pm_runtime_irq_safe() drm/tilcdc: Add support for external tda998x encoder drm/tilcdc: Remove tilcdc slave support for tda998x driver drm/tilcdc: Fix module unloading
-
Dave Airlie authored
Linux 4.1-rc6 backmerge 4.1-rc6 as some of the later pull reqs are based on newer bases and I'd prefer to do the fixup myself.
-
Maarten Lankhorst authored
This fixes some regressions in i915 when converting to atomic. set_config failed with -EINVAL, and I received the following warning in dmesg: [drm:drm_atomic_crtc_check] [CRTC:20] active without enabled Solve this by clearing active when a crtc is disabled. Because crtc_state->enable implies that connectors are active the change from disabled->enabled can only happen for the crtc that's being set_config'd, and checking for !crtc_state->enable is sufficient here. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
One more round of drm-misc, again mostly atomic. Big thing is the userspace blob code from Daniel Stone, with support for the mode_id blob now added to the atomic ioctl. Finally we can do atomic modesets! Note that the atomic ioctl is still behind the module knob since the weston patches aren't quite ready yet imo - they lack TEST_ONLY support, which is a fairly crucial bit of the atomic api. But besides that I think it's all good to go. That's also why we didn't bother to hide the new blob ioctls behind the knob, that part won't need to change. And if weston patches get in shape in time we could throw the "atomic by default patch" on top for 4.2. * tag 'topic/drm-misc-2015-05-27' of git://anongit.freedesktop.org/drm-intel: drm: Fix off-by-one in vblank hardware counter wraparound handling drm/atomic: fix out of bounds read in for_each_*_in_state helpers drm/atomic: Add MODE_ID property drm/atomic: Add current-mode blob to CRTC state drm: Add drm_atomic_set_mode_for_crtc drm: check for garbage in unused addfb2 fields drm: Retain reference to blob properties in lookup drm/mode: Add user blob-creation ioctl drm: Return error value from blob creation drm: Allow creating blob properties without copy drm/mode: Unstatic kernel-userspace mode conversion drm/mode: Validate modes inside drm_crtc_convert_umode drm/crtc_helper: Replace open-coded CRTC state helpers drm: kerneldoc fixes for blob properties drm/DocBook: Add more drm_bridge documentation drm: bridge: Allow daisy chaining of bridges drm/atomic: add all affected planes in drm_atomic_helper_check_modeset drm/atomic: add drm_atomic_add_affected_planes drm/atomic: add commit_planes_on_crtc helper
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
drm-amdkfd-next-2015-06-03: - Add the H/W debugger support module, including new IOCTLs to: - register/unregister a process as a debugged process - Set address watch-point in the debugged process's GPU kernel - Do a wave control operation in the debugged process's waves See the commit messages for more details on the available operations. The debugged process can only perform debug operation on itself. It is blocked by the amdkfd+H/W from performing operations on other processes's waves or GPU kernels. The blocking is done by setting the VMID and PASID of the debugged process in the packets that are sent to the CP with the debug instructions. - Add support for static user-mode queues. These queues are regular queues, but because they belong to the debugged process, we need to make sure the CP doesn't preempt them during a debug operation. Therefore, we mark them as static for the CP ignore them during preemption. - Support killing all the waves when a process is terminated. This is needed in case a process is terminated but we can't UNMAP its queues (can occur due to several reasons). In that case, the CP could be stuck unless we kill all its waves. This function is *very* important as it provides the kernel a high level of control over the GPU. The reason we didn't upstream this function so far, is because it is implemented using the H/W debugger module functions, so we had to wait until we can upstream the H/W debugger module. - Replace declaration of bitmap from unsigned long to standard DECLARE_BITMAP * tag 'drm-amdkfd-next-2015-06-03' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: Enforce kill all waves on process termination drm/radeon: Add ATC VMID<-->PASID functions to kfd->kgd drm/amdkfd: Implement address watch debugger IOCTL drm/amdkfd: Implement wave control debugger IOCTL drm/amdkfd: Implement (un)register debugger IOCTLs drm/amdkfd: Add address watch operation to debugger drm/amdkfd: Add wave control operation to debugger drm/amdkfd: Add skeleton H/W debugger module support drm/amdkfd: Add static user-mode queues support drm/amdkfd: add H/W debugger IOCTL set definitions drm/radeon: Add H/W debugger kfd->kgd functions drm/amdkfd: Use DECLARE_BITMAP
-
- Jun 03, 2015
-
-
Gerd Hoffmann authored
Signed-off-by:Gerd Hoffmann <kraxel@redhat.com>
-
Dave Airlie authored
This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga framebuffer, the later is a pure virtio device. The only concern for this driver is that in the virtio-vga case we have to kick out the firmware framebuffer. Initial revision has only 2d support, 3d (virgl) support requires some more work on the qemu side and will be added later. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
Ben Goz authored
This commit makes sure that on process termination, after we're destroying all the active queues, we're killing all the existing wave front of the current process. By doing this we're making sure that if any of the CUs were blocked by infinite loop we're enforcing it to end the shader explicitly. Signed-off-by:
Ben Goz <ben.goz@amd.com> Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com>
-
Alexey Skidanov authored
This patch adds three new interfaces to kfd2kgd interface file of radeon. The interfaces are: - Check if a specific VMID has a valid PASID mapping - Retrieve the PASID which is mapped to a specific VMID - Issue a VMID invalidation request to the ATC Signed-off-by:
Alexey Skidanov <Alexey.Skidanov@amd.com> Signed-off-by:
-
Yair Shachar authored
v2: - rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it - change void* to uint64_t inside ioctl arguments - use kmalloc instead of kzalloc because we use copy_from_user immediately after it Signed-off-by:
Yair Shachar <yair.shachar@amd.com> Signed-off-by:
-
Yair Shachar authored
v2: - rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it - change void* to uint64_t inside ioctl arguments - use kmalloc instead of kzalloc because we use copy_from_user immediately after it Signed-off-by:
-
Yair Shachar authored
v2: rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it Signed-off-by:
-
Yair Shachar authored
The address watch operation gives the ability to specify watch points which will generate a shader breakpoint, based on a specified single address or range of addresses. There is support for read/write/any access modes. Signed-off-by:
-
Yair Shachar authored
The wave control operation supports several command types executed upon existing wave fronts that belong to the currently debugged process. The available commands are: HALT - Freeze wave front(s) execution RESUME - Resume freezed wave front(s) execution KILL - Kill existing wave front(s) Signed-off-by:
-
Yair Shachar authored
This patch adds the skeleton H/W debugger module support. This code enables registration and unregistration of a single HSA process at a time. The module saves the process's pasid and use it to verify that only the registered process is allowed to execute debugger operations through the kernel driver. v2: rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it Signed-off-by:
-
Yair Shachar authored
This patch adds support for static user-mode queues in QCM. Queues which are designated as static can NOT be preempted by the CP microcode when it is executing its scheduling algorithm. This is needed for supporting the debugger feature, because we can't allow the CP to preempt queues which are currently being debugged. The number of queues that can be designated as static is limited by the number of HQDs (Hardware Queue Descriptors). Signed-off-by:
-
Yair Shachar authored
This patch adds four new IOCTLs to amdkfd. These IOCTLs expose a H/W debugger functionality to the userspace. The IOCTLs are: - AMDKFD_IOC_DBG_REGISTER: The purpose of this IOCTL is to notify amdkfd that a process wants to use GPU debugging facilities on itself only. It is expected that this IOCTL would be called before any other H/W debugger requests are sent to amdkfd and for each GPU where the H/W debugging needs to be enabled. The use of this IOCTL ensures that only one instance of a debugger is active in the system. - AMDKFD_IOC_DBG_UNREGISTER: This IOCTL detaches the debugger/debugged process from the H/W Debug which was established by the AMDKFD_IOC_DBG_REGISTER IOCTL. - AMDKFD_IOC_DBG_ADDRESS_WATCH: This IOCTL allows to set different watchpoints with various conditions as indicated by the IOCTL's arguments. The available number of watchpoints is retrieved from topology. This operation is confined to the current debugged process, which was registered through AMDKFD_IOC_DBG_REGISTER. - AMDKFD_IOC_DBG_WAVE_CONTROL: This IOCTL allows to control a wavefront as indicated by the IOCTL's arguments. For example, you can halt/resume or kill either a single wavefront or a set of wavefronts. This operation is confined to the current debugged process, which was registered through AMDKFD_IOC_DBG_REGISTER. Because the arguments for the address watch IOCTL and wave control IOCTL are dynamic, meaning that they could vary in size, the userspace passes a pointer to a structure (in userspace) that contains the value of the arguments. The kernel driver is responsible to parse this structure and validate its contents. v2: change void* to uint64_t inside ioctl arguments Signed-off-by:
-
Yair Shachar authored
This patch adds new interface functions to the kfd2kgd interface file. The new functions allow to perform H/W debugger operations by writing to GPU registers. Signed-off-by:
-
Joe Perches authored
Use the generic mechanism to declare a bitmap instead of unsigned long. It seems that "struct kfd_process.allocated_queue_bitmap" is unused. Maybe it could be deleted instead. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
- Jun 02, 2015
-
-
Gerd Hoffmann authored
Signed-off-by:
-
Gerd Hoffmann authored
After adding virtio-gpu I get this funky kconfig dependency loop. scripts/kconfig/conf --oldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by OMAP_REMOTEPROC drivers/remoteproc/Kconfig:12: symbol OMAP_REMOTEPROC depends on OMAP_IOMMU drivers/iommu/Kconfig:141: symbol OMAP_IOMMU is selected by VIDEO_OMAP3 drivers/media/platform/Kconfig:96: symbol VIDEO_OMAP3 depends on VIDEO_V4L2 drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362: symbol FB_CYBER2000 depends on FB Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the loop, which looks like the best way to handle it to me. Updated OMAP_IOMMU help text accordingly. Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
