this cycle has been fairly calm in etnaviv land with most of the action
happening on the userspace side.
Notable changes:
- Improvements to CONFIG option handling to make it harder for users to
shoot themselves in the foot due to kernel misconfiguration.
- Tweaked GEM object population, so that userspace can take considerate
action when memory allocation fails, rather than waking the raging OOM
killer beast.
* 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux:
drm/etnaviv: switch GEM allocations to __GFP_RETRY_MAYFAIL
drm/etnaviv: don't fail GPU bind when CONFIG_THERMAL isn't enabled
drm/etnaviv: switch to drm_*{get,put} helpers
drm/etnaviv: select CMA and DMA_CMA if available
drm/etnaviv: populate GEM objects on cpu_prep
drm/etnaviv: reduce allocation failure message severity
drm/etnaviv: don't trigger OOM killer when page allocation fails
This is the amdkfd pull request for 4.14 merge window.
AMD has started cleaning the pipe and sending patches from their internal
development to the upstream community.
The plan as I understand it is to first get all the non-dGPU patches to
upstream and then move to upstream dGPU support.
The patches here are relevant only for Kaveri and Carrizo.
The following is a summary of the changes:
- Add new IOCTL to set a Scratch memory VA
- Update PM4 headers for new firmware that support scratch memory
- Support image tiling mode
- Remove all uses of BUG_ON
- Various Bug fixes and coding style fixes
* tag 'drm-amdkfd-next-2017-08-18' of git://people.freedesktop.org/~gabbayo/linux: (24 commits)
drm/amdkfd: Implement image tiling mode support v2
drm/amdgpu: Add kgd kfd interface get_tile_config() v2
drm/amdkfd: Adding new IOCTL for scratch memory v2
drm/amdgpu: Add kgd/kfd interface to support scratch memory v2
drm/amdgpu: Program SH_STATIC_MEM_CONFIG globally, not per-VMID
drm/amd: Update MEC HQD loading code for KFD
drm/amdgpu: Disable GFX PG on CZ
drm/amdkfd: Update PM4 packet headers
drm/amdkfd: Clamp EOP queue size correctly on Gfx8
drm/amdkfd: Add more error printing to help bringup v2
drm/amdkfd: Handle remaining BUG_ONs more gracefully v2
drm/amdkfd: Allocate gtt_sa_bitmap in long units
drm/amdkfd: Fix doorbell initialization and finalization
drm/amdkfd: Remove BUG_ONs for NULL pointer arguments
drm/amdkfd: Remove usage of alloc(sizeof(struct...
drm/amdkfd: Fix goto usage v2
drm/amdkfd: Change x==NULL/false references to !x
drm/amdkfd: Consolidate and clean up log commands
drm/amdkfd: Clean up KFD style errors and warnings v2
drm/amdgpu: Remove hard-coded assumptions about compute pipes
...
Allwinner DRM changes for 4.14
A few changes, but most notably improving the HDMI support merged in 4.13,
by reporting the DDC adapter as an i2c bus, and by adding CEC support
through the CEC framework.
* tag 'sunxi-drm-for-4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
sun4i_hdmi: add CEC support
dt-bindings: display: sunxi: Improve endpoint ID scheme readability
drm/sun4i: tcon: remove unused function
drm/sun4i: Remove useless atomic_check
drm/sun4i: Add if statement instead of depends on
drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus
drm/sun4i: constify drm_plane_helper_funcs
More changes for 4.14. Highlights:
- command submission overhead improvements
- Huge page support for vega10
- physical mode support for mjpeg for asics that don't support UVD vm
- improve ttm_mem_type_manager_func debug
- misc ttm fixes, cleanups
- misc gpuvm cleanups
* 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux: (26 commits)
drm/ttm: use reservation_object_trylock in ttm_bo_individualize_resv v2
drm/amdgpu: fix vega10 graphic hang issue in S3 test
drm/amdgpu: bump version for support of UVD MJPEG decode
drm/amdgpu: add MJPEG check for UVD physical mode msg buffer
drm/ttm: Fix accounting error when fail to get pages for pool
drm/amd/amdgpu: expose fragment size as module parameter (v2)
drm/amd/amdgpu: store fragment_size in vm_manager
drm/amdgpu: rename VM invalidated to moved
drm/amdgpu: separate bo_va structure
drm/amdgpu: drop the extra VM huge page flag v2
drm/amdgpu: remove superflous amdgpu_bo_kmap in the VM
drm/amdgpu: cleanup static CSA handling
drm/amdgpu: SHADOW and VRAM_CONTIGUOUS flags shouldn't be used by userspace
drm/amdgpu: save list length when fence is signaled
drm/amdgpu: move vram usage tracking into the vram manager v2
drm/amdgpu: move gtt usage tracking into the gtt manager v2
drm/amdgpu: move debug print into the MM managers
drm/amdgpu: fix incorrect use of the lru_lock
drm/radeon: fix incorrect use of the lru_lock
drm/ttm: make ttm_mem_type_manager_func debug more useful
...
This bit enables hardware that will change the approximation used for distances
calculations for AA wide lines so that they are rendered more accurately.
The default value for this bit leaves the legacy behavior. There is no good
reason to not enable the new approximation except if comparing to previous GEN
rendered images.
v2: Rebase
v3: Fix author.
Rebased by Rodrigo who also added a comment as suggested by Oscar.
Since it is surrounded by Workarounds let's just add a comment to
make clear it is not an Wa.
Cc: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170815231651.975-4-rodrigo.vivi@intel.com
Let's inherit workarounds from previous platforms that
according to wa_database and BSpec are still valid for
Cannonlake.
v2: Add missed workarounds.
v3: Rebase
v4: Remove bad chunk that was added to rc6 disable. (Ander)
Also remove A0 W/a that are not needed anymore.
v5: Rebase on top of CFL.
v6: Remove empty gen9_init_perctx_bb and gen9_init_indirectctx_bb
since they don't carry any gen10 related W/a. (by Oscar).
Also Remove A0 exclusive workaround.
v7: Remove more A0 exclusive workarounds. As pointed out by Oscar
many workarounds were changed to be A0 only so let's remove
them.
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170815231651.975-1-rodrigo.vivi@intel.com
Fixes a false positive from might_sleep(). The reservation object is freshly
initialized, so nobody else can hold the mutex but the function is
called from atomic context.
v2: Correctly invert the check as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Archit requested this backmerge to facilitate merging some patches
depending on changes between -rc2 & -rc5
Signed-off-by: Sean Paul <seanpaul@chromium.org>
The commit 213e08ad60
("drm/i915/bxt: add bxt dsi gpio element support")
enables GPIO support for Broxton based platforms.
While using that API we might get into troubles in the future, because
we can't rely on label name in the driver since vendor firmware might
provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in
which case the request will fail).
To avoid inconsistency and potential issues we have two options:
a) generate GPIO ACPI mapping table and supply it via
acpi_dev_add_driver_gpios(), or
b) just pass NULL as connection ID.
The b) approach is much simpler and would work since the driver relies
on GPIO indices only. Moreover, the _CRS fallback mechanism, when
requesting GPIO, has been made stricter, and supplying non-NULL
connection ID when neither _DSD, nor GPIO ACPI mapping is present, is
making request fail.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921
Fixes: f10e4bf663 ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817105541.63914-1-andriy.shevchenko@linux.intel.com
In a synchronous setup, we may retire the last request before we
complete allocating the next request. As the last request is retired, we
queue a timer to mark the device as idle, and promptly have to execute
ad cancel that timer once we complete allocating the request and need to
keep the device awake. If we rearrange the mark_busy() to occur before
we retire the previous request, we can skip this ping-pong.
v2: Joonas pointed out that unreserve_seqno() was now doing more than
doing seqno handling and should be renamed to reflect its wider purpose.
That also highlighted the new asymmetry with reserve_seqno(), so fixup
that and rename both to [un]reserve_engine().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817144719.10968-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
This was the competing idea long ago, but it was only with the rewrite
of the idr as an radixtree and using the radixtree directly ourselves,
along with the realisation that we can store the vma directly in the
radixtree and only need a list for the reverse mapping, that made the
patch performant enough to displace using a hashtable. Though the vma ht
is fast and doesn't require any extra allocation (as we can embed the node
inside the vma), it does require a thread for resizing and serialization
and will have the occasional slow lookup. That is hairy enough to
investigate alternatives and favour them if equivalent in peak performance.
One advantage of allocating an indirection entry is that we can support a
single shared bo between many clients, something that was done on a
first-come first-serve basis for shared GGTT vma previously. To offset
the extra allocations, we create yet another kmem_cache for them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-5-chris@chris-wilson.co.uk
When userspace is doing most of the work, avoiding relocs (using
NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we
still spend a lot of time processing the arrays in execbuf, even though
we now should have nothing to do most of the time. One issue that
becomes readily apparent in profiling anv is that iterating over the
large execobj[] is unfriendly to the loop prefetchers of the CPU and it
much prefers iterating over a pair of arrays rather than one big array.
v2: Clear vma[] on construction to handle errors during vma lookup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-3-chris@chris-wilson.co.uk
Forcewake is not affected by the engine reset on gen6+. Indeed the
reason why we added intel_uncore_forcewake_reset() to
gen6_reset_engines() was to keep the bookkeeping intact because the
reset did not touch the forcewake bit (yet we cancelled the forcewake
consumers)! This was done in commit 521198a2e7:
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Fri Aug 23 16:52:30 2013 +0300
drm/i915: sanitize forcewake registers on reset
In reset we try to restore the forcewake state to
pre reset state, using forcewake_count. The reset
doesn't seem to clear the forcewake bits so we
get warn on forcewake ack register not clearing.
That futzing of the forcewake bookkeeping was dropped in commit
0294ae7b44 ("drm/i915: Consolidate forcewake resetting to a single
function"), but it did not make the realisation that the remaining
intel_uncore_forcewake_reset() was redundant.
The new danger with using intel_uncore_forcewake_reset() with per-engine
resets is that the driver and hw are still in an active state as we
perform the reset. We may be using the forcewake to read protected
registers elsewhere and those results may be clobbered by the concurrent
dropping of forcewake.
Reported-by: Michel Thierry <michel.thierry@intel.com>
Fixes: 142bc7d99b ("drm/i915: Modify error handler for per engine hang recovery")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817173229.20324-1-chris@chris-wilson.co.uk
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
