aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2018-03-14drm/amdgpu: initial validate the prime BOs into the CPU domainChristian König1-1/+3
Just set the GTT domain as mandatory, so that the BO is validated into it on first use. This allows us to setup the sg table later on. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amdgpu: drop the backing store when DMA-buf imports are evictedChristian König1-0/+6
Instead of moving this to the SYSTEM domain just drop the backing store and let the resulting allocation be freed. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/ttm: move initializing ttm->sg into ttm_tt_init_fieldsChristian König1-3/+1
Better to set this with all other fields as well. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/ttm: add bo as parameter to the ttm_tt_create callbackChristian König15-68/+61
Instead of calculating the size in bytes just to recalculate the number of pages from it pass the BO directly to the function. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/ttm: add ttm_bo_pipeline_guttingChristian König2-3/+36
Allows us to gut a BO of it's backing store when the driver says that it isn't needed any more. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amdgpu: refactoring mailbox to fix TDR handshake bugs(v2)Monk Liu2-91/+106
this patch actually refactor mailbox implmentations, and all below changes are needed together to fix all those mailbox handshake issues exposured by heavey TDR test. 1)refactor all mailbox functions based on byte accessing for mb_control reason is to avoid touching non-related bits when writing trn/rcv part of mailbox_control, this way some incorrect INTR sent to hypervisor side could be avoided, and it fixes couple handshake bug. 2)trans_msg function re-impled: put a invalid logic before transmitting message to make sure the ACK bit is in a clear status, otherwise there is chance that ACK asserted already before transmitting message and lead to fake ACK polling. (hypervisor side have some tricks to workaround ACK bit being corrupted by VF FLR which hase an side effects that may make guest side ACK bit asserted wrongly), and clear TRANS_MSG words after message transferred. 3)for mailbox_flr_work, it is also re-worked: it takes the mutex lock first if invoked, to block gpu recover's participate too early while hypervisor side is doing VF FLR. (hypervisor sends FLR_NOTIFY to guest before doing VF FLR and sentds FLR_COMPLETE after VF FLR done, and the FLR_NOTIFY will trigger interrupt to guest which lead to mailbox_flr_work being invoked) This can avoid the issue that mailbox trans msg being cleared by its VF FLR. 4)for mailbox_rcv_irq IRQ routine, it should only peek msg and schedule mailbox_flr_work, instead of ACK to hypervisor itself, because FLR_NOTIFY msg sent from hypervisor side doesn't need VF's ACK (this is because VF's ACK would lead to hypervisor clear its trans_valid/msg, and this would cause handshake bug if trans_valid/msg is cleared not due to correct VF ACK but from a wrong VF ACK like this "FLR_NOTIFY" one) This fixed handshake bug that sometimes GUEST always couldn't receive "READY_TO_ACCESS_GPU" msg from hypervisor. 5)seperate polling time limite accordingly: POLL ACK cost no more than 500ms POLL MSG cost no more than 12000ms POLL FLR finish cost no more than 500ms 6) we still need to set adev into in_gpu_reset mode after we received FLR_NOTIFY from host side, this can prevent innocent app wrongly succesed to open amdgpu dri device. FLR_NOFITY is received due to an IDLE hang detected from hypervisor side which indicating GPU is already die in this VF. v2: use MACRO as the offset of mailbox_control register don't test if NOTIFY_CMPL event in rcv_msg since it won't recieve that message anymore Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Pixel Ding <Pixel.Ding@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amdgpu: implement mmio byte access helper for MBMonk Liu2-0/+32
mailbox registers can be accessed with a byte boundry according to BIF team, so this patch prepares register byte access and will be used by following patches. Actually, for mailbox registers once the byte field is touched even not changed, the mailbox behaves, so we need the byte width accessing to those sort of regs. Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Pixel Ding <Pixel.Ding@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amdgpu: query vram type from atombiosHawking Zhang3-7/+93
The vram type for dGPU is stored in umc_info while sys mem type for APU is stored in integratedsysteminfo Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amd/amdgpu: Add missing "DDR4" labelTom St Denis1-1/+2
The commit d296278fd372003fc69588acfd0c0c5edbdf4874 added support for detecting DDR4 but omitted the label that is printed out in amdgpu_bo_init() resulting in a KASAN error. Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amdgpu: Correct the amdgpu_ucode_fini_bo place for TongaEmily Deng2-3/+3
The amdgpu_ucode_fini_bo should be called after gfx_v8_0_hw_fini, or it will have KCQ disable failed issue. For Tonga, as it firstly finishes SMC block, and the SMC hw fini will call amdgpu_ucode_fini, which will lead the amdgpu_ucode_fini_bo called before gfx_v8_0_hw_fini, this is incorrect. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amdgpu: Correct the place of amdgpu_pm_sysfs_finiEmily Deng1-1/+1
The amdgpu_pm_sysfs_fini should call before amdgpu_device_ip_fini, or the adev->pm.dpm_enabled would be set to 0, then the device files related to pp won't be removed by amdgpu_pm_sysfs_fini when unload driver. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/amdgpu: stop allocating a page array for prime shared BOsChristian König2-3/+4
We don't need the page array for prime shared BOs, stop allocating it. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/ttm: add ttm_sg_tt_initChristian König1-9/+45
This allows drivers to only allocate dma addresses, but not a page array. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/ttm: move ttm_tt defines into ttm_tt.hChristian König1-6/+0
Let's stop mangling everything in a single header and create one header per object instead. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Roger He <Hongbo.He@amd.com> Acked-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-14drm/i915/pmu: Work around compiler warnings on some kernel configsTvrtko Ursulin1-19/+13
Arnd Bergman reports: """ The conditional spinlock confuses gcc into thinking the 'flags' value might contain uninitialized data: drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read': arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code is correct, but it's easy to see how the compiler gets confused here. This avoids the problem by pulling the lock outside of the function into its only caller. """ On deeper look it seems this is caused by paravirt spinlocks implementation when CONFIG_PARAVIRT_DEBUG is set, which by being complicated, manages to convince gcc locked parameter can be changed externally (impossible). Work around it by removing the conditional locking parameters altogether. (It was never the most elegant code anyway.) Slight penalty we now pay is an additional irqsave spin lock/unlock cycle on the event enable path. But since enable is not a fast path, that is preferrable to the alternative solution which was doing MMIO under irqsave spinlock. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180314080535.17490-1-tvrtko.ursulin@linux.intel.com
2018-03-14drm/i915: Check rq->timeline before deferenceChris Wilson1-1/+3
Not only is the context suspect to disappearing, but so is it's timeline. Under a lockless inspection of the requests for debugging from intel_engine_dump(), the context may already have been freed and we have to check before chasing the dangling pointer. [28033.681755] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul crc32_pclmul snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel snd_pcm mei_me mei i915 r8169 mii prime_numbers i2c_hid [28033.681796] CPU: 3 PID: 3058 Comm: gem_exec_schedu Tainted: G U 4.16.0-rc5+ #9 [28033.681804] Hardware name: Acer Aspire E5-575G/Ironman_SK , BIOS V1.12 08/02/2016 [28033.681834] RIP: 0010:print_request+0x2b/0xb0 [i915] [28033.681840] RSP: 0018:ffffc90004afbc18 EFLAGS: 00010202 [28033.681847] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8801921b5a40 RCX: 0000000000000006 [28033.681854] RDX: ffffc90004afbc60 RSI: ffff8801921b5a40 RDI: 0000000000000004 [28033.681861] RBP: ffffc90004afbd80 R08: 0000000000000000 R09: 0000000000000001 [28033.681868] R10: ffffc90004afbbd0 R11: ffffc90004afbc73 R12: ffffc90004afbc60 [28033.681875] R13: ffffc90004afbd80 R14: ffff8801d40ec670 R15: ffff8801921b5a40 [28033.681883] FS: 00007fbba5f6c8c0(0000) GS:ffff8801e8400000(0000) knlGS:0000000000000000 [28033.681891] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [28033.681897] CR2: 00007fbba5f8f000 CR3: 00000001b2efa002 CR4: 00000000003606e0 [28033.681904] Call Trace: [28033.681932] intel_engine_print_registers+0x6a7/0x930 [i915] [28033.681962] intel_engine_dump+0x30d/0x740 [i915] [28033.681971] ? seq_printf+0x3a/0x50 [28033.681995] i915_engine_info+0xb8/0xe0 [i915] [28033.682003] ? drm_get_color_range_name+0x20/0x20 [28033.682010] seq_read+0xe1/0x440 [28033.682018] full_proxy_read+0x51/0x80 [28033.682025] __vfs_read+0x21/0x130 [28033.682031] ? do_sys_open+0x134/0x220 [28033.682037] ? kmem_cache_free+0x177/0x2b0 [28033.682043] vfs_read+0xa1/0x150 [28033.682049] SyS_read+0x40/0xa0 [28033.682055] do_syscall_64+0x6b/0x1b0 [28033.682063] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [28033.682069] RIP: 0033:0x7fbba4655d11 [28033.682074] RSP: 002b:00007ffd8c49da58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [28033.682082] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbba4655d11 [28033.682089] RDX: 000000000000003f RSI: 00005647bfbfc260 RDI: 0000000000000006 [28033.682096] RBP: 000000000000003f R08: 00000000ffffffff R09: 0000000000000000 [28033.682104] R10: 0000000000000000 R11: 0000000000000246 R12: 00005647bfbfc260 [28033.682111] R13: 0000000000000006 R14: 0000000000000000 R15: 00005647bfbfc260 [28033.682119] Code: 41 55 41 54 49 89 d4 55 53 48 89 fd 48 8b 86 c8 00 00 00 48 8b 3d d6 1e 14 e2 48 89 f3 48 2b be a8 02 00 00 48 8b 80 b0 00 00 00 <4c> 8b 68 18 e8 bc 80 02 e1 8b 8b 70 02 00 00 8b b3 28 02 00 00 [28033.682206] RIP: print_request+0x2b/0xb0 [i915] RSP: ffffc90004afbc18 Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180314101630.8933-1-chris@chris-wilson.co.uk
2018-03-14drm/vmwgfx: replace drm_*_unreference with drm_*_putHaneen Mohammed2-3/+3
This patch replace instances of drm_framebuffer_unreference with _put() suffix, because it is shorter and consistent with the kernel use of *_get/put() suffixes. This was done with the following Coccinelle script: @r@ expression e; @@ ( -drm_framebuffer_reference(e); +drm_framebuffer_get(e); | -drm_framebuffer_unreference(e); +drm_framebuffer_put(e); ) Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com> Acked-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180311233313.GA19721@Haneen
2018-03-14drm/i915/guc: Check the locking status of GuC WOPCM registersJackie Li5-5/+74
GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers which will lead to unpredictable driver behaviors if these registers were touch by other components (such as faulty BIOS code). This patch moves the GuC WOPCM registers updating code into intel_wopcm.c and adds check before and after the update to GuC WOPCM registers so that we can make sure the driver is in a known state after writing to these write-once registers. v6: - Made sure module reloading won't bug the kernel while doing locking status checking v7: - Fixed patch format issues v8: - Fixed coding style issue on register lock bit macro definition (Sagar) v9: - Avoided to use redundant !! to cast uint to bool (Chris) - Return error code instead of GEM_BUG_ON for locked with invalid register values case (Sagar) - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal) - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC WOPCM offset register based on the presence of HuC firmware (Michal) - Use bit fields instead of macros for GuC WOPCM flags (Michal) v10: - Refined variable names, removed redundant comments (Joonas) - Introduced lockable_reg to handle the write once register write and propagate the write error to caller (Joonas) - Used lockable_reg abstraction to avoid locking bit check on generic i915_reg_t (Michal) - Added log message for error paths (Michal) - Removed hw_updated flag and only relies on real hardware status v11: - Replaced lockable_reg with simplified function (Michal) - Used new macros for locking bits of WOPCM size/offset registers instead of using BIT(0) directly (Michal) - use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC WOPCM register setup instead of calling from intel_uc_init_hw() (Michal) v12: - Updated function kernel-doc to align with code changes (Michal) - Updated code to use wopcm pointer directly (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) BSpec: 10875, 10833 Signed-off-by: Jackie Li <yaodong.li@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-5-git-send-email-yaodong.li@intel.com
2018-03-14drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0Jackie Li1-2/+25
On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch adds new verification code to ensure the available GuC WOPCM size to be larger than or equal to HuC firmware size on both Gen9 and CNL A0. v6: - Extended HuC FW size check against GuC WOPCM size to all Gen9 and CNL A0 platforms v7: - Fixed patch format issues v8: - Renamed variables and functions to avoid ambiguity (Joonas) - Updated commit message and comments to be more comprehensive (Sagar) v9: - Moved code that is not related to restriction check into a separate patch and updated the commit message accordingly (Sagar/Michal) - Avoided to call uc_get_fw_size for better layer isolation (Michal) v10: - Shorten function names and reorganized size_check code to have clear isolation (Joonas) - Removed unnecessary comments (Joonas) v11: - Fixed logic error in size check (Michal) v12: - Add space between "HuC FW" and "(%uKiB)" in error message (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) BSpec: 10875 Signed-off-by: Jackie Li <yaodong.li@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: John Spotswood <john.a.spotswood@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> (v8) Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-4-git-send-email-yaodong.li@intel.com
2018-03-14drm/i915: Add support to return CNL specific reserved WOPCM sizeJackie Li1-0/+4
CNL has its specific reserved GuC WOPCM size for RC6 and other hardware contexts. This patch updates the code to return CNL specific reserved GuC WOPCM size for RC6 and other hardware contexts so that the GuC WOPCM size can be calculated correctly for CNL. v9: - Created a new patch for these changes originally made in v8 4/6 patch of this series (Sagar/Michal) v10: - Used if-else ladder to the returning of context sizes (Joonas) v11: - Removed GUC_ prefix from context size macro (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) Bspec: 12690 Signed-off-by: Jackie Li <yaodong.li@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9) Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-3-git-send-email-yaodong.li@intel.com
2018-03-14drm/i915: Implement dynamic GuC WOPCM offset and size calculationJackie Li14-41/+321
Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size will lead to GuC firmware execution failures. On the other hand, with current static GuC WOPCM offset and size values (512KB for both offset and size), the GuC WOPCM size verification will fail on Gen9 even if it can be fixed by lowering the GuC WOPCM offset by calculating its value based on HuC firmware size (which is likely less than 200KB on Gen9), so that we can have a GuC WOPCM size value which is large enough to pass the GuC WOPCM size check. This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to 24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To meet all above requirements, let's provide dynamic partitioning of the WOPCM that will be based on platform specific HuC/GuC firmware sizes. v2: - Removed intel_wopcm_init (Ville/Sagar/Joonas) - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar) - Removed unnecessary function calls (Joonas) - Init GuC WOPCM partition as soon as firmware fetching is completed v3: - Fixed indentation issues (Chris) - Removed layering violation code (Chris/Michal) - Created separat files for GuC wopcm code (Michal) - Used inline function to avoid code duplication (Michal) v4: - Preset the GuC WOPCM top during early GuC init (Chris) - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed v5: - Moved GuC DMA WOPCM register updating code into intel_wopcm.c - Took care of the locking status before writing to GuC DMA Write-Once registers. (Joonas) v6: - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned) v8: - Updated comments and fixed naming issues (Sagar/Joonas) - Updated commit message to include more description about the hardware restriction on GuC WOPCM size (Sagar) v9: - Minor changes variable names and code comments (Sagar) - Added detailed GuC WOPCM layout drawing (Sagar/Michal) - Refined macro definitions to be reader friendly (Michal) - Removed redundent check to valid flag (Michal) - Unified first parameter for exported GuC WOPCM functions (Michal) - Refined the name and parameter list of hardware restriction checking functions (Michal) v10: - Used shorter function name for internal functions (Joonas) - Moved init-ealry function into c file (Joonas) - Consolidated and removed redundant size checks (Joonas/Michal) - Removed unnecessary unlikely() from code which is only called once during boot (Joonas) - More fixes to kernel-doc format and content (Michal) - Avoided the use of PAGE_MASK for 4K pages (Michal) - Added error log messages to error paths (Michal) v11: - Replaced intel_guc_wopcm with more generic intel_wopcm and attached intel_wopcm to drm_i915_private instead intel_guc (Michal) - dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top offset from GuC WOPCM base) (Michal) - Moved WOPCM marco definitions into .c source file (Michal) - Exported WOPCM layout diagram as kernel-doc (Michal) v12: - Updated naming, function kernel-doc to align with new changes (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) - Corrected one tense error in comment (Sagar) - Corrected typos and removed spurious comments (Joonas) Bspec: 12690 Signed-off-by: Jackie Li <yaodong.li@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Spotswood <john.a.spotswood@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> (v8) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9) Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-2-git-send-email-yaodong.li@intel.com
2018-03-14drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offsetJackie Li10-25/+36
GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its GuC related. Current guc_ggtt_offset() failed to follow this code convention and this is a problem for future patches that needs to access intel_guc data to verify the GGTT offset against the GuC WOPCM top. This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates the related code to pass intel_guc pointer to this function call, so that we can have a unified coding style for GuC code and also enable the future patches to get GuC related data from intel_guc to do the offset verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from intel_guc_regs.h to intel_guc.h since it is not GuC register related definition. v8: - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar) - Updated commit message to explain to reason and motivation to add intel_guc as the first parameter of intel_guc_ggtt_offset (Chris) v9: - Fixed code alignment issue due to line break (Chris) v10: - Removed unnecessary comments, redundant code and avoided reuse variable to avoid potential issues (Joonas) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) Signed-off-by: Jackie Li <yaodong.li@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> (v8) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9) Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-1-git-send-email-yaodong.li@intel.com
2018-03-14drm/rockchip: Don't use spin_lock_irqsave in interrupt contextMarc Zyngier1-6/+4
The rockchip DRM driver is quite careful to disable interrupts when taking a lock that is also taken in interrupt context, which is a good thing. What is a bit over the top is to use spin_lock_irqsave when already in interrupt context, as you cannot take another interrupt again, and disabling interrupt is just pure overhead. Switching to the non _irqsave version in interrupt context is more logical, and less heavy handed. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-4-marc.zyngier@arm.com
2018-03-14drm/rockchip: Do not use memcpy for MMIO addressesMarc Zyngier1-4/+7
memcpy is only meant to be used for memory, and only that. MMIO accessors should be used to access MMIO regions, preferably the ones that correspond to the size of the register accessed. Let's convert the bulk register copy to writel/readl_relaxed, which is the correct API. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-3-marc.zyngier@arm.com
2018-03-14drm/rockchip: Clear all interrupts before requesting the IRQMarc Zyngier1-11/+12
Calling request_irq() followed by disable_irq() is usually a bad idea, specially if the interrupt can be pending, and you're not yet in a position to handle it. This is exactly what happens on my kevin system when rebooting in a second kernel using kexec: Some interrupt is left pending from the previous kernel, and we take it too early, before disable_irq() could do anything. Let's clear the pending interrupts as we initialize the HW, and move the interrupt request after that point. This ensures that we're in a sane state when the interrupt is requested. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> [adapted to recent rockchip-drm changes] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-2-marc.zyngier@arm.com
2018-03-14drm: mali-dp: Add YUV->RGB conversion support for video layersMihail Atanassov4-17/+90
Internally Mali DP uses an RGB pipeline so video layers that support YUV input buffers need to convert the input data to RGB. The YUV buffers can have various encodings and this patch introduces support for BT.601, BT.709 and BT.2020 encodings, both limited and full ranges. This patch adds support for specifying the color encoding of the input buffers for the planes that are backed by the video layers and programs the YUV2RGB coefficients into hardware based on the selected encoding. Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> [updated to use standard properties] Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm: mali-dp: Turn off CRTC vblank when removing module.Liviu Dudau1-0/+2
When unbinding the mali-dp driver the drm_vblank_cleanup() function warns us that the vblanks are still enabled. Fix that by calling drm_crtc_vblank_off() in the malidp_unbind() function. Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm: arm: malidp: Use drm_atomic_helper_shutdown() to disable planes on removalLaurent Pinchart2-4/+1
The plane cleanup handler currently calls drm_plane_helper_disable(), which is a legacy helper function. Replace it with a call to drm_atomic_helper_shutdown() at removal time. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm: arm: malidp: Don't destroy planes manually in error handlersLaurent Pinchart4-22/+3
The top-level error handler calls drm_mode_config_cleanup() which will destroy all planes. There's no need to destroy them manually in lower error handlers. As plane cleanup is now handled entirely by drm_mode_config_cleanup(), we must ensure that the plane .destroy() handler frees allocated memory for the plane object that was freed by malidp_de_planes_destroy(). Do so by replacing the call to devm_kfree() in the .destroy() handler by kfree(). devm_kfree() is currently a no-op as the plane memory is allocated with kzalloc(), not devm_kzalloc(). Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending.Liviu Dudau3-18/+27
Mali DP hardware has a 'go' bit (config_valid) for making the new scene parameters active at the next page flip. The problem with the current code is that the driver first sets this bit and then proceeds to wait for confirmation from the hardware that the configuration has been updated before arming the vblank event. As config_valid is actually asserted by the hardware after the vblank event, during the prefetch phase, when we get to arming the vblank event we are going to send it at the next vblank, in effect halving the vblank rate from the userspace perspective. Fix it by sending the userspace event from the IRQ handler, when we handle the config_valid interrupt, which syncs with the time when the hardware is active with the new parameters. Reported-by: Alexandru-Cosmin Gheorghe <alexandru-cosmin.gheorghe@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm/arm/malidp: Disable pixel alpha blending for colors that do not have alphaAyan Halder1-5/+22
Mali dp needs to disable pixel alpha blending (use layer alpha blending) to display color formats that do not contain alpha bits per pixel This patch depends on: "[PATCH v2 01/19] drm/fourcc: Add a alpha field to drm_format_info" Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm: mali-dp: Fix bug on scaling with rotationAyan Halder1-2/+8
In the case, when the user wants to scale and rotate a layer by 90/270 degrees, the scaling engine input dimensions' parameters ie width and height needs to be swapped with respect to the layer's input dimensions. This means scaling engine input height should be set to layer's input width and scaling engine input width should be set to layer's input height. Signed-off-by: Ayan Halder <ayan.halder@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm/mali-dp: Don't enable scaling engine for planes that only rotate.Liviu Dudau1-2/+8
Currently the scaling engine gets enabled for a plane where the input size differs from the composition size. As rotation is done natively by the plane's hardware layer, we don't need the scaling engine to be enabled. Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm: mali-dp: Uninitialized variable in malidp_se_check_scaling()Dan Carpenter1-2/+2
We use "mc" without initializing it if scaling is not necessary. Fixes: 28ce675b7474 ("drm: mali-dp: Add plane upscaling support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Mihail Atanassov <Mihail.Atanassov@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm/mali-dp: Align pitch size to be multiple of bus burst read size.Liviu Dudau1-1/+14
Mali DP hardware needs pitch line sizes aligned to the bus burst size for reads, so take that into consideration when allocating dumb buffers. If the layer is rotated then the stride size requirement is even larger for some hardware versions, so allocate for the worst case scenario. Update the ->dumb_create() hook to a driver specific function that sets the correct pitch size. Reported-by: Ayan Halder <ayan.halder@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm/mali-dp: Rotated planes need a larger pitch size.Liviu Dudau2-4/+12
Rotated planes need a pitch size that is aligned to 8 bytes for older DP500 and DP550 and at least 64 bytes for DP650. Replace the malidp_hw_pitch_valid() function with one that calculates the correct pitch alignment to take into account rotation. Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-03-14drm/bridge: analogix_dp: Only wait for panel ACK on PSR entryzain wang3-4/+7
We currently wait for the panel to mirror our intended PSR state before continuing on both PSR enter and PSR exit. This is really only important to do when we're entering PSR, since we want to be sure the last frame we pushed is being served from the panel's internal fb before shutting down the soc blocks (vop/analogix). This patch changes the behavior such that we only wait for the panel to complete the PSR transition when we're entering PSR, and to skip verification when we're exiting. Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: Sonny Rao <sonnyrao@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-7-enric.balletbo@collabora.com
2018-03-14drm/panel: rm68200: Add backlight dependencyArnd Bergmann1-0/+1
Like many other panel drivers, this one fails to build when backlight support is disabled: drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe': panel-raydium-rm68200.c:(.text+0x14a): undefined reference to `devm_of_find_backlight' This adds the appropriate dependency. Note that while include/linux/backlight.h provides a stub inline when backlight support is not enabled, this isn't enough to deal with the case where backlight support is built as a module but the panel driver is built-in, in which case linking will still fail as above. One way to avoid this is to add a dependency such as this: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n but that is rather complex and misses the point that the panel support is mostly useless without backlight support. Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> [treding@nvidia.com: clarify the need for the dependency] Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180313210015.3344380-1-arnd@arndb.de
2018-03-14drm/rockchip: add mutex vop lockzain wang1-6/+24
Add a lock to vop to avoid disabling the crtc while waiting for a line flag while enabling psr. If we disable in the middle of waiting for the line flag, we'll end up timing out or worse. Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-5-enric.balletbo@collabora.com
2018-03-14drm/bridge: analogix_dp: add fast link train for eDPzain wang2-25/+108
We would meet a short black screen when exit PSR with the full link training, In this case, we should use fast link train instead of full link training. Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> [dropped header reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-6-enric.balletbo@collabora.com
2018-03-14drm/bridge: analogix_dp: Don't change psr while bridge is disabledzain wang3-9/+10
There is a race between AUX CH bring-up and enabling bridge which will cause link training to fail. To avoid hitting it, don't change psr state while enabling the bridge. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Caesar Wang <wxt@rock-chips.com> [seanpaul fixed up the commit message a bit and renamed *_supported to *_enabled] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-4-enric.balletbo@collabora.com
2018-03-14drm/rockchip: Remove analogix psr workerSean Paul1-29/+2
Now that the spinlocks and timers are gone, we can remove the psr worker located in rockchip's analogix driver and do the enable/disable directly. This should simplify the code and remove races on disable. Cc: 征增 王 <wzz@rock-chips.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-3-enric.balletbo@collabora.com
2018-03-14drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSRYakir Yang3-10/+37
Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() function, or print the sink PSR error state if we failed to apply the requested PSR setting. Cc: 征增 王 <wzz@rock-chips.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Yakir Yang <ykk@rock-chips.com> [seanpaul changed timeout loop to a readx poll] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-2-enric.balletbo@collabora.com
2018-03-14drm/omap: fix compile error when DPI is disabledTomi Valkeinen1-1/+1
When CONFIG_OMAP2_DSS_DPI is disabled, compilation fails due to: drivers/gpu/drm/omapdrm/dss/dss.h:388:25: error: conflicting types for ‘port’ struct device_node *port, ^~~~ Fix this by renaming the first parameter correctly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-03-14drm/omap: fix compile error when debugfs is disabledTomi Valkeinen1-14/+12
When compiling with CONFIG_OMAP2_DSS_DEBUGFS disabled, build fails due to: drivers/gpu/drm/omapdrm/dss/dss.c:1474:10: error: ‘dss_debug_dump_clocks’ undeclared (first use in this function); did you mean ‘dispc_dump_clocks’? dss_debug_dump_clocks, dss); ^~~~~~~~~~~~~~~~~~~~~ dispc_dump_clocks Fix this by moving the required functions outside #if defined(CONFIG_OMAP2_DSS_DEBUGFS). In the long term, we perhaps want to try to get all the debugfs support left out if debugfs is not enabled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-03-14drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGEGiulio Benetti1-0/+25
Handle both positive and negative dclk polarity, according to bus_flags, taking care of this: On A20 and similar SoCs, the only way to achieve Positive Edge (Rising Edge), is setting dclk clock phase to 2/3(240°). By default TCON works in Negative Edge(Falling Edge), this is why phase is set to 0 in that case. Unfortunately there's no way to logically invert dclk through IO_POL register. The only acceptable way to work, triple checked with scope, is using clock phase set to 0° for Negative Edge and set to 240° for Positive Edge. On A33 and similar SoCs there would be a 90° phase option, but it divides also dclk by 2. This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers for using A33 90° phase divided by 2 and consequently increase code complexity. Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520963677-124239-1-git-send-email-giulio.benetti@micronovasrl.com
2018-03-14drm/sun4i: add lvds mode_valid functionGiulio Benetti1-0/+55
mode_valid function is missing for lvds. Add it making it pointed by encoder helper functions. Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520940019-68977-1-git-send-email-giulio.benetti@micronovasrl.com
2018-03-14drm/sun4i: move rgb mode_valid from connector to encoderGiulio Benetti1-4/+4
mode_valid function must be connected to encoder. Otherwise it could get not be called by drm in the case there's a bridge connected to encoder instead of a panel. Move mode_valid function pointer to encoder helper functions, changing its prototype according to encoder helper function pointer. Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/1520941017-81177-1-git-send-email-giulio.benetti@micronovasrl.com
2018-03-14Merge tag 'drm-intel-next-2018-03-08' of git://anongit.freedesktop.org/drm/drm-intel into drm-nextDave Airlie107-3610/+5379
UAPI Changes: - Query uAPI interface (used for GPU topology information currently) * Mesa: https://patchwork.freedesktop.org/series/38795/ Driver Changes: - Increase PSR2 size for CNL (DK) - Avoid retraining LSPCON link unnecessarily (Ville) - Decrease request signaling latency (Chris) - GuC error capture fix (Daniele) * tag 'drm-intel-next-2018-03-08' of git://anongit.freedesktop.org/drm/drm-intel: (127 commits) drm/i915: Update DRIVER_DATE to 20180308 drm/i915: add schedule out notification of preempted but completed request drm/i915: expose rcs topology through query uAPI drm/i915: add query uAPI drm/i915: add rcs topology to error state drm/i915/debugfs: add rcs topology entry drm/i915/debugfs: reuse max slice/subslices already stored in sseu drm/i915: store all subslice masks drm/i915/guc: work around gcc-4.4.4 union initializer issue drm/i915/cnl: Add Wa_2201832410 drm/i915/icl: Gen11 forcewake support drm/i915/icl: Add Indirect Context Offset for Gen11 drm/i915/icl: Enhanced execution list support drm/i915/icl: new context descriptor support drm/i915/icl: Correctly initialize the Gen11 engines drm/i915: Assert that the request is indeed complete when signaled from irq drm/i915: Handle changing enable_fbc parameter at runtime better. drm/i915: Track whether the DP link is trained or not drm/i915: Nuke intel_dp->channel_eq_status drm/i915: Move SST DP link retraining into the ->post_hotplug() hook ...
2018-03-14Merge tag 'drm-amdkfd-next-2018-03-11' of git://people.freedesktop.org/~gabbayo/linux into drm-nextDave Airlie38-357/+3749
Major points for this pull request: - Add dGPU support for amdkfd initialization code and queue handling. It's not complete support since the GPUVM part is missing (the under debate stuff). - Enable PCIe atomics for dGPU if present - Various adjustments to the amdgpu<-->amdkfd interface for dGPUs - Refactor IOMMUv2 code to allow loading amdkfd without IOMMUv2 in the system - Add HSA process eviction code in case of system memory pressure - Various fixes and small changes * tag 'drm-amdkfd-next-2018-03-11' of git://people.freedesktop.org/~gabbayo/linux: (24 commits) uapi: Fix type used in ioctl parameter structures drm/amdkfd: Implement KFD process eviction/restore drm/amdkfd: Add GPUVM virtual address space to PDD drm/amdkfd: Remove unaligned memory access drm/amdkfd: Centralize IOMMUv2 code and make it conditional drm/amdgpu: Add submit IB function for KFD drm/amdgpu: Add GPUVM memory management functions for KFD drm/amdgpu: add amdgpu_sync_clone drm/amdgpu: Update kgd2kfd_shared_resources for dGPU support drm/amdgpu: Add KFD eviction fence drm/amdgpu: Remove unused kfd2kgd interface drm/amdgpu: Fix wrong mask in get_atc_vmid_pasid_mapping_pasid drm/amdgpu: Fix header file dependencies drm/amdgpu: Replace kgd_mem with amdgpu_bo for kernel pinned gtt mem drm/amdgpu: remove useless BUG_ONs drm/amdgpu: Enable KFD initialization on dGPUs drm/amdkfd: Add dGPU device IDs and device info drm/amdkfd: Add dGPU support to kernel_queue_init drm/amdkfd: Add dGPU support to the MQD manager drm/amdkfd: Add dGPU support to the device queue manager ...
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.