summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-03riscv: avoid the PIC offset of static percpu data in module beyond 2G limitsVincent Chen
The compiler uses the PIC-relative method to access static variables instead of GOT when the code model is PIC. Therefore, the limitation of the access range from the instruction to the symbol address is +-2GB. Under this circumstance, the kernel cannot load a kernel module if this module has static per-CPU symbols declared by DEFINE_PER_CPU(). The reason is that kernel relocates the .data..percpu section of the kernel module to the end of kernel's .data..percpu. Hence, the distance between the per-CPU symbols and the instruction will exceed the 2GB limits. To solve this problem, the kernel should place the loaded module in the memory area [&_end-2G, VMALLOC_END]. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Suggested-by: Alexandre Ghiti <alex@ghiti.fr> Suggested-by: Anup Patel <anup@brainfault.org> Tested-by: Alexandre Ghiti <alex@ghiti.fr> Tested-by: Carlos de Paula <me@carlosedp.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-03drm/i915/selftests: Fix uninitialized variableAditya Swarup
Static code analysis tool identified struct lrc_timestamp data as being uninitialized and then data.ce[] is being checked for NULL/negative value in the error path. Initializing data variable fixes the issue. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200303142347.15696-1-aditya.swarup@intel.com
2020-03-03drm/i915/gt: Drop the timeline->mutex as we wait for retirementChris Wilson
As we have pinned the timeline (using tl->active_count), we can safely drop the tl->mutex as we wait for what we believe to be the final request on that timeline. This is useful for ensuring that we do not block the engine heartbeat by hogging the kernel_context's timeline on a dead GPU. References: https://gitlab.freedesktop.org/drm/intel/issues/1364 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request") 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/20200303140009.1494819-1-chris@chris-wilson.co.uk
2020-03-03drm/i915: Drop vma is-closed assertion on insertChris Wilson
The is-closed flag may be added after we have acquired the vma under the ctx->mutex, but will not take effect until after we release the vm->mutex. i.e. the flag may be set on the vma as attempt to bind it and that will cause the vma to be unbound later after we unpin it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303093157.1153887-1-chris@chris-wilson.co.uk
2020-03-03drm/i915/gem: Check that the context wasn't closed during setupChris Wilson
As setup takes a long time, the user may close the context during the construction of the execbuf. In order to make sure we correctly track all outstanding work with non-persistent contexts, we need to serialise the submission with the context closure and mop up any leaks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-3-chris@chris-wilson.co.uk
2020-03-03drm/i915/gt: Prevent allocation on a banned contextChris Wilson
If a context is banned even before we submit our first request to it, report the failure before we attempt to allocate any resources for the context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-2-chris@chris-wilson.co.uk
2020-03-03drm/i915/gem: Consolidate ctx->engines[] releaseChris Wilson
Use the same engine_idle_release() routine for cleaning all old ctx->engine[] state, closing any potential races with concurrent execbuf submission. v2ish: Use the ce->pin_count to close the execbuf gap. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-1-chris@chris-wilson.co.uk
2020-03-03drm/i915: Polish CHV .load_luts() a bitVille Syrjälä
It irks me to use crtc_state_is_legacy_gamma() inside the guts of the CHV color management code. Let's get rid of it and instead just consult cgm_mode to figure out if we want to enable the pipe gamma or the CGM gamma. Also CHV display engine is based on i965/g4x so we should fall back to the i965 path when the CGM gamma is not used. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-3-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
2020-03-03dm: bump version of core and various targetsMike Snitzer
Changes made during the 5.6 cycle warrant bumping the version number for DM core and the targets modified by this commit. It should be noted that dm-thin, dm-crypt and dm-raid already had their target version bumped during the 5.6 merge window. Signed-off-by; Mike Snitzer <snitzer@redhat.com>
2020-03-03dm: fix congested_fn for request-based deviceHou Tao
We neither assign congested_fn for requested-based blk-mq device nor implement it correctly. So fix both. Also, remove incorrect comment from dm_init_normal_md_queue and rename it to dm_init_congested_fn. Fixes: 4aa9c692e052 ("bdi: separate out congested state into a separate struct") Cc: stable@vger.kernel.org Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-03-03fcntl: Distribute switch variables for initializationKees Cook
Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. fs/fcntl.c: In function ‘send_sigio_to_task’: fs/fcntl.c:738:20: warning: statement will never be executed [-Wswitch-unreachable] 738 | kernel_siginfo_t si; | ^~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jeff Layton <jlayton@kernel.org>
2020-03-03drm/i915/gvt: only include intel_gvt.h where neededJani Nikula
i915_drv.c is the only caller. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-3-jani.nikula@intel.com
2020-03-03drm/i915/gvt: make intel_gvt_active internal to intel_gvtJani Nikula
Nobody else uses it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-2-jani.nikula@intel.com
2020-03-03drm/i915/vgpu: improve vgpu abstractionsJani Nikula
Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to intel_vgpu_detect() to match other function naming, un-inline intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and intel_vgpu_has_huge_gtt() to reduce header interdependencies. The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-1-jani.nikula@intel.com
2020-03-03arm64: dts: socfpga: agilex: Fix gmac compatibleLey Foon Tan
Fix gmac compatible string to "altr,socfpga-stmmac-a10-s10". Gmac for Agilex should use same compatible as Stratix 10. Fixes: 4b36daf9ada3 ("arm64: dts: agilex: Add initial support for Intel's Agilex SoCFPGA") Cc: stable@vger.kernel.org Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-03-03dm integrity: use dm_bio_record and dm_bio_restoreMike Snitzer
In cases where dec_in_flight() has to requeue the integrity_bio_wait work to transfer the rest of the data, the bio's __bi_remaining might already have been decremented to 0, e.g.: if bio passed to underlying data device was split via blk_queue_split(). Use dm_bio_{record,restore} rather than effectively open-coding them in dm-integrity -- these methods now manage __bi_remaining too. Depends-on: f7f0b057a9c1 ("dm bio record: save/restore bi_end_io and bi_integrity") Reported-by: Daniel Glöckner <dg@emlix.com> Suggested-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-03-03dm bio record: save/restore bi_end_io and bi_integrityMike Snitzer
Also, save/restore __bi_remaining in case the bio was used in a BIO_CHAIN (e.g. due to blk_queue_split). Suggested-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-03-03btrfs: fix RAID direct I/O reads with alternate csumsOmar Sandoval
btrfs_lookup_and_bind_dio_csum() does pointer arithmetic which assumes 32-bit checksums. If using a larger checksum, this leads to spurious failures when a direct I/O read crosses a stripe. This is easy to reproduce: # mkfs.btrfs -f --checksum blake2 -d raid0 /dev/vdc /dev/vdd ... # mount /dev/vdc /mnt # cd /mnt # dd if=/dev/urandom of=foo bs=1M count=1 status=none # dd if=foo of=/dev/null bs=1M iflag=direct status=none dd: error reading 'foo': Input/output error # dmesg | tail -1 [ 135.821568] BTRFS warning (device vdc): csum failed root 5 ino 257 off 421888 ... Fix it by using the actual checksum size. Fixes: 1e25a2e3ca0d ("btrfs: don't assume ordered sums to be 4 bytes") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Omar Sandoval <osandov@fb.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2020-03-03ASoC: SOF: Fix snd_sof_ipc_stream_posn()Dan Carpenter
We're passing "&posn" instead of "posn" so it ends up corrupting memory instead of doing something useful. Fixes: 53e0c72d98ba ("ASoC: SOF: Add support for IPC IO between DSP and Host") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200303101858.ytehbrivocyp3cnf@kili.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-03ASoC: rt1015: modify pre-divider for sysclkJack Yu
Modify pre-divider for system clock. Signed-off-by: Jack Yu <jack.yu@realtek.com> Link: https://lore.kernel.org/r/20200303025913.24499-1-jack.yu@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-03drm/i915: Fix kbuild test robot build errorAnshuman Gupta
has_transcoder() was unused because function which was using it, intel_display_capture_error_state() defined under CONFIG_DRM_I915_CAPTURE_ERROR. Moving has_transcoder() to under CONFIG_DRM_I915_CAPTURE_ERROR. No functional change. Fixes: d54c1a513c48 ("drm/i915: Fix broken transcoder err state") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227175147.11362-1-anshuman.gupta@intel.com
2020-03-03drm/i915/hdcp: conversion to struct drm_device based logging macros.Ramalingam C
Converts remaining instances of the printk based logging macros in i915/display/intel_hdcp.c with the struct drm_device based macros manually. This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.") v2: i915_dev_priv is used instead of drm_device for reusability [JaniN] v3: Made it independent from the series. once instance of dev_priv naming is changed to i915 [Jani N] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212123007.6659-1-ramalingam.c@intel.com
2020-03-03drm/i915: move watermark structs more towards usageJani Nikula
Shrink i915_drv.h a bit by moving watermark structs where they are needed. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227170047.31089-3-jani.nikula@intel.com
2020-03-03drm/i915: Fix doclinksChris Wilson
Update locations for ./drivers/gpu/drm/i915/i915_vma.h:1: warning: 'Virtual Memory Address' not found ./drivers/gpu/drm/i915/i915_gem_gtt.c:1: warning: 'Global GTT views' not found Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302145254.520447-1-chris@chris-wilson.co.uk
2020-03-03drm/i915/dmc: Use firmware v2.06 for TGLJosé Roberto de Souza
New firmware contains minor fixes around context restore. Reviewed-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227235005.18706-1-jose.souza@intel.com
2020-03-03drm/i915: fix documentation build after renameJani Nikula
intel_csr.c was moved under display. Fixes: 06d3ff6e7451 ("drm/i915: move intel_csr.[ch] under display/") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302170218.16496-1-jani.nikula@intel.com
2020-03-03interconnect: Handle memory allocation errorsGeorgi Djakov
When we allocate memory, kasprintf() can fail and we must check its return value. Fixes: 05309830e1f8 ("interconnect: Add a name to struct icc_path") Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Link: https://lore.kernel.org/r/20200226110420.5357-2-georgi.djakov@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-03altera-stapl: altera_get_note: prevent write beyond end of 'key'Daniel Axtens
altera_get_note is called from altera_init, where key is kzalloc(33). When the allocation functions are annotated to allow the compiler to see the sizes of objects, and with FORTIFY_SOURCE, we see: In file included from drivers/misc/altera-stapl/altera.c:14:0: In function ‘strlcpy’, inlined from ‘altera_init’ at drivers/misc/altera-stapl/altera.c:2189:5: include/linux/string.h:378:4: error: call to ‘__write_overflow’ declared with attribute error: detected write beyond size of object passed as 1st parameter __write_overflow(); ^~~~~~~~~~~~~~~~~~ That refers to this code in altera_get_note: if (key != NULL) strlcpy(key, &p[note_strings + get_unaligned_be32( &p[note_table + (8 * i)])], length); The error triggers because the length of 'key' is 33, but the copy uses length supplied as the 'length' parameter, which is always 256. Split the size parameter into key_len and val_len, and use the appropriate length depending on what is being copied. Detected by compiler error, only compile-tested. Cc: "Igor M. Liplianin" <liplianin@netup.ru> Signed-off-by: Daniel Axtens <dja@axtens.net> Link: https://lore.kernel.org/r/20200120074344.504-2-dja@axtens.net Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/202002251042.D898E67AC@keescook Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-03binder: prevent UAF for binderfs devicesChristian Brauner
On binder_release(), binder_defer_work(proc, BINDER_DEFERRED_RELEASE) is called which punts the actual cleanup operation to a workqueue. At some point, binder_deferred_func() will be called which will end up calling binder_deferred_release() which will retrieve and cleanup the binder_context attach to this struct binder_proc. If we trace back where this binder_context is attached to binder_proc we see that it is set in binder_open() and is taken from the struct binder_device it is associated with. This obviously assumes that the struct binder_device that context is attached to is _never_ freed. While that might be true for devtmpfs binder devices it is most certainly wrong for binderfs binder devices. So, assume binder_open() is called on a binderfs binder devices. We now stash away the struct binder_context associated with that struct binder_devices: proc->context = &binder_dev->context; /* binderfs stashes devices in i_private */ if (is_binderfs_device(nodp)) { binder_dev = nodp->i_private; info = nodp->i_sb->s_fs_info; binder_binderfs_dir_entry_proc = info->proc_log_dir; } else { . . . proc->context = &binder_dev->context; Now let's assume that the binderfs instance for that binder devices is shutdown via umount() and/or the mount namespace associated with it goes away. As long as there is still an fd open for that binderfs binder device things are fine. But let's assume we now close the last fd for that binderfs binder device. Now binder_release() is called and punts to the workqueue. Assume that the workqueue has quite a bit of stuff to do and doesn't get to cleaning up the struct binder_proc and the associated struct binder_context with it for that binderfs binder device right away. In the meantime, the VFS is killing the super block and is ultimately calling sb->evict_inode() which means it will call binderfs_evict_inode() which does: static void binderfs_evict_inode(struct inode *inode) { struct binder_device *device = inode->i_private; struct binderfs_info *info = BINDERFS_I(inode); clear_inode(inode); if (!S_ISCHR(inode->i_mode) || !device) return; mutex_lock(&binderfs_minors_mutex); --info->device_count; ida_free(&binderfs_minors, device->miscdev.minor); mutex_unlock(&binderfs_minors_mutex); kfree(device->context.name); kfree(device); } thereby freeing the struct binder_device including struct binder_context. Now the workqueue finally has time to get around to cleaning up struct binder_proc and is now trying to access the associate struct binder_context. Since it's already freed it will OOPs. Fix this by holding an additional reference to the inode that is only released once the workqueue is done cleaning up struct binder_proc. This is an easy alternative to introducing separate refcounting on struct binder_device which we can always do later if it becomes necessary. This is an alternative fix to 51d8a7eca677 ("binder: prevent UAF read in print_binder_transaction_log_entry()"). Fixes: 3ad20fe393b3 ("binder: implement binderfs") Fixes: 03e2e07e3814 ("binder: Make transaction_log available in binderfs") Related : 51d8a7eca677 ("binder: prevent UAF read in print_binder_transaction_log_entry()") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Todd Kjos <tkjos@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-02Revert "bcache: ignore pending signals when creating gc and allocator thread"Jens Axboe
This reverts commit 0b96da639a4874311e9b5156405f69ef9fc3bef8. We can't just go flushing random signals, under the assumption that the OOM killer will just do something else. It's not safe from the OOM perspective, and it could also cause other signals to get randomly lost. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-02drm/i915/huc: update TGL HuC to v7.0.12Daniele Ceraolo Spurio
Update to the latest available TGL HuC, which includes changes required by the media team. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Tony Ye <tony.ye@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200229012042.27487-1-daniele.ceraolospurio@intel.com
2020-03-02dt-bindings: arm: fsl: fix APF6Dev compatibleSébastien Szymanski
APF6 Dev compatible is armadeus,imx6dl-apf6dev and not armadeus,imx6dl-apf6dldev. Fixes: 3d735471d066 ("dt-bindings: arm: Document Armadeus SoM and Dev boards devicetree binding") Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-02drm/i915/execlists: Check the sentinel is alone in the ELSPChris Wilson
We only use sentinel requests for "preempt-to-idle" passes, so assert that they are the only request in a new submission. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-12-chris@chris-wilson.co.uk
2020-03-02io-wq: remove io_wq_flush and IO_WQ_WORK_INTERNALPavel Begunkov
io_wq_flush() is buggy, during cancelation of a flush, the associated work may be passed to the caller's (i.e. io_uring) @match callback. That callback is expecting it to be embedded in struct io_kiocb. Cancelation of internal work probably doesn't make a lot of sense to begin with. As the flush helper is no longer used, just delete it and the associated work flag. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-02drm/i915/perf: Reintroduce wait on OA configuration completionChris Wilson
We still need to wait for the initial OA configuration to happen before we enable OA report writes to the OA buffer. Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1356 Testcase: igt/perf/stream-open-close Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-7-chris@chris-wilson.co.uk
2020-03-02drm/i915/tgl: Add Wa number to WaAllowPMDepthAndInvocationCountAccessFromUMDJosé Roberto de Souza
Just to make easier to check that the Wa was implemetend when comparing to the number in BSpec. BSpec: 52890 Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-10-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add note about Wa_1409142259José Roberto de Souza
Different issues with the same fix, so justing adding Wa_1409142259, Wa_1409252684, Wa_1409217633, Wa_1409207793, Wa_1409178076 and 1408979724 to the comment so other devs can check if this Was were implemetend with a simple grep. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-8-jose.souza@intel.com
2020-03-02drm/i915/tgl: Fix the Wa number of a fixJosé Roberto de Souza
The Wa number for this fix is Wa_1607087056 the BSpec bug id is 1607087056, just updating to match BSpec. BSpec: 52890 Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-7-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add note about Wa_1607063988José Roberto de Souza
This issue workaround in Wa_1607063988 has the same fix as Wa_1607138336, so just adding a note in the code. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-6-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add note to Wa_1607297627José Roberto de Souza
Add note about the confliting information in BSpec about this WA. BSpec: 52890 Acked-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-5-jose.souza@intel.com
2020-03-02drm/i915/tgl: Extend Wa_1606931601 for all steppingsAnusha Srivatsa
According to BSpec. Wa_1606931601 applies for all TGL steppings. This patch moves the WA implementation out of A0 only block of rcs_engine_wa_init(). The WA is has also been referred to by an alternate name Wa_1607090982. Bspec: 46045, 52890 Fixes: 3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-4-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add Wa_1409085225, Wa_14010229206Matt Atwood
Disable Push Constant buffer addition for TGL. v2: typos, add additional Wa reference v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit message. Bspec: 52890 Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-3-jose.souza@intel.com
2020-03-02drm/i915/tgl: Implement Wa_1806527549José Roberto de Souza
This will whitelist the HIZ_CHICKEN register so mesa can disable the optimizations and avoid hang when using D16_UNORM. v2: moved to the right place and used the right function() (Chris) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-2-jose.souza@intel.com
2020-03-02drm/i915/tgl: Implement Wa_1409804808José Roberto de Souza
This workaround the CS not done issue on PIPE_CONTROL. v2: - replaced BIT() by REG_BIT() in all GEN7_ROW_CHICKEN2() bits - shortened the name of the new bit BSpec: 52890 BSpec: 46218 Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-1-jose.souza@intel.com
2020-03-02Merge tag 'arm-soc/for-5.6/defconfig-fixes' of ↵Olof Johansson
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs defconfig file(s) fixes for v5.6, please pull the following: - Stefan restores CONFIG_DEBUG_FS from the bcm2835_defconfig which was accidentally removed * tag 'arm-soc/for-5.6/defconfig-fixes' of https://github.com/Broadcom/stblinux: ARM: bcm2835_defconfig: Explicitly restore CONFIG_DEBUG_FS Link: https://lore.kernel.org/r/20200302195043.14513-1-f.fainelli@gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2020-03-02Merge tag 'amlogic-fixes' of ↵Olof Johansson
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/fixes Amlogic fixes for v5.6-rc * tag 'amlogic-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: arm64: dts: meson: fix gxm-khadas-vim2 wifi arm64: dts: meson-sm1-sei610: add missing interrupt-names ARM: meson: Drop unneeded select of COMMON_CLK Link: https://lore.kernel.org/r/7hr1yc9cc1.fsf@baylibre.com Signed-off-by: Olof Johansson <olof@lixom.net>
2020-03-02drm/i915: Unify the DPLL ref clock frequency trackingImre Deak
All platforms using the shared DPLL framework use 3 reference clocks for their DPLLs: SSC, non-SSC and DSI. For a more unified way across platforms store the frequency of these ref clocks as part of the DPLL global state. This also allows us to keep the HW access reading out the ref clock value separate from the DPLL frequency calculation that depends on the ref clock. For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code has its own logic for calculating DPLL parameters instead of the shared DPLL framework. v2: - Apply the ICL combo PHY PLL ref_clock/2 adjustment during the frequency->PLL param conversion direction as well. (CI shards) - s/kHZ/kHz/ (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228153328.17842-1-imre.deak@intel.com
2020-03-02drm/i915/hsw: Use the read-out WRPLL/SPLL state instead of reading out againImre Deak
Instead of reading out the WRPLL/SPLL control values from HW, we can use the DPLL state that was already read out, or swapped-to. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-13-imre.deak@intel.com
2020-03-02drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculationImre Deak
Split out the PLL parameter->frequency conversion logic for each type of PLL for symmetry with their corresponding inverse conversion functions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-12-imre.deak@intel.com
2020-03-02drm/i915/hsw: Split out the WRPLL, LCPLL, SPLL frequency calculationImre Deak
Split out the PLL parameter->frequency conversion logic for each type of PLL for symmetry with their corresponding inverse conversion functions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-11-imre.deak@intel.com
generated by cgit (git 2.34.1) at 2025-09-16 18:25:52 +0000