summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-08-19gpu: ipu-v3: image-convert: only sample into the next tile if necessaryPhilipp Zabel1-2/+2
The first pixel of the next tile is only sampled by the hardware if the fractional input position corresponding to the last written output pixel is not an integer position. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: image-convert: move tile burst alignment out of loopPhilipp Zabel1-39/+45
Burst aligned input and output width can be calculated once per column, instead of repeatedly for each tile in the column. The same goes for input and output height per row. Also don't round up the same values repeatedly. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: image-convert: bail on invalid tile sizesPhilipp Zabel1-3/+24
If we managed to create tiles sized 0x0 because of a bug in the seam calculation, return with an error message instead of letting the driver run into a division by zero later. Also check for tile sizes that are larger than supported by the hardware. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: image-convert: fix image downsize coefficients and tiling ↵Philipp Zabel1-18/+31
calculation This patch effectively reverts commit 912bbf7e9ca4 ("gpu: ipu-v3: image-convert: Fix image downsize coefficients") and replaces it with a different solution based on the preceding patches. The previous fix tried to solve the problem of intermediate tile size between IC downsizing and main processing sections not being limited to 1024 pixels by downsizing the input image to a smaller intermediate size in the downsizing box filter. This causes unnecessary blurring, especially for scaling factors close to 1. Now that the seam position calculation makes sure that the 1024 pixel intermediate tile size limit is not exceeded, calculate the number of tiles from the maximum of intermediate size and output size and avoid unnecessary downsizing. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: image-convert: limit input seam position to hardware requirementsPhilipp Zabel1-6/+24
Limit the input seam position to an interval that guarantees the tile size does not exceed 1024 pixels after the IC downsizing section and that space is left for the next tile. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: image-convert: fix output seam valid intervalPhilipp Zabel1-2/+2
This fixes a failure to determine any seam if the output size is exactly 1024 multiplied by the number of tiles in a given direction. In that case an empty interval out_start == out_end is being passed to find_best_seam, which looks for a seam out_start <= x < out_end. Also reduce the interval for all but the left column / top row, to avoid returning position 0 as best fit. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: image-convert: move output seam valid interval calculation into ↵Philipp Zabel1-22/+12
find_best_seam This reduces code duplication and allows to apply the following modifications in a single place. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: image-convert: enable V4L2_PIX_FMT_BGRX32 and _RGBX32Philipp Zabel1-0/+6
Enable image converter support for V4L2_PIX_FMT_BGRX32 and V4L2_PIX_FMT_RGBX32 pixel formats. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-08-19gpu: ipu-v3: enable remaining 32-bit RGB V4L2 pixel formatsPhilipp Zabel2-7/+35
Support is already implemented for the corresponding DRM formats, just hook up the remaining V4L2 pixel formats. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
2019-08-19udlfb: Make dlfb_ops constantNishka Dasgupta1-1/+1
Static structure dlfb_ops, of type fb_ops, is not used except to be copied into another variable. Hence make dlfb_ops constant to protect it from unintended modification. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Cc: Bernie Thompson <bernie@plugable.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819075236.1051-1-nishkadg.linux@gmail.com
2019-08-19video: fbdev/mmp/core: Use struct_size() in kzalloc()Gustavo A. R. Silva1-4/+2
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct mmp_path { ... struct mmp_overlay overlays[0]; }; size = sizeof(struct mmp_path) + count * sizeof(struct mmp_overlay); instance = kzalloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, overlays, count), GFP_KERNEL) Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807161312.GA26835@embeddedor
2019-08-19video: fbdev: viafb: Remove dead codeSouptick Joarder1-43/+0
This is dead code since 3.15. If there is no plan to use it further, this can be removed forever. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> [b.zolnierkie: fix patch summary] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1564515200-5020-1-git-send-email-jrdr.linux@gmail.com
2019-08-19video: fbdev: aty[128]fb: Remove dead codeSouptick Joarder2-47/+0
This is dead code since 3.15. If there is no plan to use it further, this can be removed forever. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: David S. Miller <davem@davemloft.net> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: "Ville Syrjälä" <syrjala@sci.fi> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [b.zolnierkie: fix patch summary] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1564514053-4571-1-git-send-email-jrdr.linux@gmail.com
2019-08-19video: fbdev: sh_mobile_lcdcfb: Mark expected switch fall-throughAnders Roxell1-0/+2
Now that -Wimplicit-fallthrough is passed to GCC by default, the following warnings shows up: ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_channel_fb_init’: ../drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=] info->fix.ypanstep = 2; ~~~~~~~~~~~~~~~~~~~^~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c:2087:2: note: here case V4L2_PIX_FMT_NV16: ^~~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_overlay_fb_init’: ../drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=] info->fix.ypanstep = 2; ~~~~~~~~~~~~~~~~~~~^~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c:1597:2: note: here case V4L2_PIX_FMT_NV16: ^~~~ Rework to address a warnings due to the enablement of -Wimplicit-fallthrough. Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com> [b.zolnierkie: fix patch summary] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730152530.3055-1-anders.roxell@linaro.org
2019-08-19video: fbdev: radeonfb: Use dev_get_drvdataChuhong Yuan1-4/+2
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [b.zolnierkie: fix patch summary and intendation] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190724131900.2039-1-hslester96@gmail.com
2019-08-19video: fbdev: sm712fb: Use dev_get_drvdataChuhong Yuan1-6/+2
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com> [b.zolnierkie: fix patch summary] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190724131744.1709-1-hslester96@gmail.com
2019-08-19video: fbdev: pvr2fb: remove unnecessary comparison of unsigned integer with < 0Gustavo A. R. Silva1-4/+2
There is no need to compare *var->xoffset* or *var->yoffset* with < 0 because such variables are of type unsigned, making it impossible to hold a negative value. Fix this by removing such comparisons. Addresses-Coverity-ID: 1451964 ("Unsigned compared against 0") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722203358.GA29111@embeddedor
2019-08-19efifb: BGRT: Improve efifb_bgrt_sanity_checkHans de Goede1-21/+6
For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable. Extensive testing has shown that when the info is correct, the BGRT image is always exactly centered horizontally (the yoffset variable is more variable and not always predictable). This commit simplifies / improves the bgrt_sanity_check to simply check that the BGRT image is exactly centered horizontally and skips (re)drawing it when it is not. This fixes the BGRT image sometimes being drawn in the wrong place. Cc: stable@vger.kernel.org Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native resolutions") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: Peter Jones <pjones@redhat.com>, Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190721131918.10115-1-hdegoede@redhat.com
2019-08-19drm/i915: Only emit the 'send bug report' once for a GPU hangChris Wilson1-2/+1
Use a locked xchg to ensure that the global log message giving instructions on how to send a bug report is emitted precisely once. 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/20190819075835.20065-5-chris@chris-wilson.co.uk
2019-08-19drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafeChris Wilson1-0/+18
We use a fake timeline->mutex lock to reassure lockdep that the timeline is always locked when emitting requests. However, the use inside __engine_park() may be inside hardirq and so lockdep now complains about the mixed irq-state of the nested locked. Disable irqs around the lockdep tracking to keep it happy. Fixes: 6c69a45445af ("drm/i915/gt: Mark context->active_count as protected by timeline->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819075835.20065-3-chris@chris-wilson.co.uk
2019-08-19drm/i915: Always wrap the ring offset before resettingChris Wilson1-2/+1
We were passing in an unwrapped offset into intel_ring_reset() on unpinning. Sooner or later that had to land on ring->size. <3> [314.872147] intel_ring_reset:1237 GEM_BUG_ON(!intel_ring_offset_valid(ring, tail)) <4> [314.872272] ------------[ cut here ]------------ <2> [314.872276] kernel BUG at drivers/gpu/drm/i915/gt/intel_ringbuffer.c:1237! <4> [314.872320] invalid opcode: 0000 [#1] PREEMPT SMP PTI <4> [314.872331] CPU: 1 PID: 3466 Comm: i915_selftest Tainted: G U 5.3.0-rc4-CI-Patchwork_14061+ #1 <4> [314.872346] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT PC/3647h, BIOS 786G7 v01.02 10/22/2009 <4> [314.872477] RIP: 0010:intel_ring_reset+0x51/0x70 [i915] <4> [314.872487] Code: 9e db 51 e0 48 8b 35 b6 c7 22 00 49 c7 c0 f8 d9 d6 a0 b9 d5 04 00 00 48 c7 c2 70 5b d4 a0 48 c7 c7 6c fc c0 a0 e8 cf be 58 e0 <0f> 0b 89 77 20 89 77 1c 89 77 24 e9 4f ed ff ff 0f 1f 44 00 00 66 <4> [314.872512] RSP: 0018:ffffc9000034fa98 EFLAGS: 00010282 <4> [314.872523] RAX: 0000000000000010 RBX: ffff8881019412c8 RCX: 0000000000000000 <4> [314.872534] RDX: 0000000000000001 RSI: 0000000000000008 RDI: 0000000000000f20 <4> [314.872545] RBP: ffff888104e0f740 R08: 0000000000000000 R09: 0000000000000f20 <4> [314.872557] R10: 0000000000000000 R11: ffff888117094518 R12: ffffffffa0d3d2c0 <4> [314.872569] R13: ffffffffa0e2a250 R14: ffffffffa0e2a1e0 R15: ffffc9000034fe88 <4> [314.872581] FS: 00007fe6d49f6e40(0000) GS:ffff888117a80000(0000) knlGS:0000000000000000 <4> [314.872595] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [314.872605] CR2: 000055e3283e9cc8 CR3: 0000000108842000 CR4: 00000000000406e0 <4> [314.872616] Call Trace: <4> [314.872701] intel_ring_unpin+0x1a/0x220 [i915] <4> [314.872787] ring_destroy+0x48/0xc0 [i915] <4> [314.872870] intel_engines_cleanup+0x24/0x40 [i915] <4> [314.872964] i915_gem_driver_release+0x1b/0xf0 [i915] <4> [314.872984] i915_driver_release+0x1c/0x80 [i915] 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/20190819075835.20065-2-chris@chris-wilson.co.uk
2019-08-19drm/xen-front: Make structure fb_funcs constantNishka Dasgupta1-1/+1
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only when it is passed to drm_gem_fb_create_with_funcs() as its last argument. drm_gem_fb_create_with_funcs does not modify its lst argument (fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs constant to protect it from further modification. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190813062712.24993-1-nishkadg.linux@gmail.com
2019-08-18drm/i915: Propagate fence errorsChris Wilson4-5/+34
Errors spread like wildfire, and must eventually be returned to the user. They need to be captured and passed along the flow of fences, infecting each in turn with the existing error, until finally they fall out of a user visible result. 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/20190817232511.11391-1-chris@chris-wilson.co.uk
2019-08-18drm/i915/uc: Never fail on HuC firmware errorsMichal Wajdeczko2-12/+5
There is no need to mark whole GPU as wedged just because of the custom HuC fw failure as users can always verify actual HuC firmware status using existing HUC_STATUS ioctl. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190818095204.31568-4-michal.wajdeczko@intel.com
2019-08-18drm/i915/uc: Don't always fail on unavailable GuC firmwareMichal Wajdeczko1-2/+25
If we failed to fetch default GuC firmware and we didn't plan to use it for the submission and we never have used GuC before then we may continue normal driver load, no need to declare GPU wedged (we can use execlist for submission) and it is safe to run without the HuC (users will check HuC status anyway). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190818095204.31568-3-michal.wajdeczko@intel.com
2019-08-18drm/i915/guc: Don't open log relay if GuC is not runningMichal Wajdeczko2-8/+13
As we plan to continue driver load after GuC initialization failure, we can't assume that GuC log data will be available just because GuC was initially enabled. We must check that GuC is still running instead. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190818095204.31568-2-michal.wajdeczko@intel.com
2019-08-18drm/vboxvideo: Make structure vbox_fb_helper_funcs constantNishka Dasgupta1-1/+1
The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs, is used only when it is passed as the third argument to drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it constant to protect it from unintended modifications. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190813062548.24770-1-nishkadg.linux@gmail.com
2019-08-17dma-fence: Store the timestamp in the same union as the cb_listChris Wilson4-18/+38
The timestamp and the cb_list are mutually exclusive, the cb_list can only be added to prior to being signaled (and once signaled we drain), while the timestamp is only valid upon being signaled. Both the timestamp and the cb_list are only valid while the fence is alive, and as soon as no references are held can be replaced by the rcu_head. By reusing the union for the timestamp, we squeeze the base dma_fence struct to 64 bytes on x86-64. v2: Sort the union chronologically Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Acked-by: Christian König <christian.koenig@amd.com>. Link: https://patchwork.freedesktop.org/patch/msgid/20190817153022.5749-1-chris@chris-wilson.co.uk
2019-08-17dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signalChris Wilson1-32/+12
Currently dma_fence_signal() tries to avoid the spinlock and only takes it if absolutely required to walk the callback list. However, to allow for some users to surreptitiously insert lazy signal callbacks that do not depend on enabling the signaling mechanism around every fence, we always need to notify the callbacks on signaling. As such, we will always need to take the spinlock and dma_fence_signal() effectively becomes a clone of dma_fence_signal_locked(). v2: Update the test_and_set_bit() before entering the spinlock. v3: Drop the test_[and_set]_bit() before the spinlock, it's a caller error so expected to be very unlikely. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817152300.5370-1-chris@chris-wilson.co.uk
2019-08-17dma-fence: Avoid list_del during fence->cb_list iterationChris Wilson1-3/+6
Before we notify the fence signal callback, we remove the cb from the list. However, since we are processing the entire list from underneath the spinlock, we do not need to individual delete each element, but can simply reset the link and the entire list. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817144736.7826-4-chris@chris-wilson.co.uk
2019-08-17dma-fence: Shrink size of struct dma_fenceChris Wilson1-3/+3
Rearrange the couple of 32-bit atomics hidden amongst the field of pointers that unnecessarily caused the compiler to insert some padding, shrinks the size of the base struct dma_fence from 80 to 72 bytes on x86-64. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817144736.7826-3-chris@chris-wilson.co.uk
2019-08-17drm/panel: tpo-td043mtea1: remove redundant assignmentColin Ian King1-1/+1
Variable val is initialized to a value in a for-loop that is never read and hence it is redundant. Remove it. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190817122124.29650-1-colin.king@canonical.com
2019-08-17drm/i915/uc: Never fail on uC preparation stepMichal Wajdeczko5-17/+16
Let's wait with decision about importance of uC failure to hardware initialization step. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190817131144.26884-4-michal.wajdeczko@intel.com
2019-08-17drm/i915/uc: Cleanup fw fetch on every GuC/HuC init failureMichal Wajdeczko5-9/+11
Be consistent and always perform fw fetch cleanup in GuC/HuC specific init functions on every failure. Also while converting firmware status to error, stop treating SELECTED as non-error, as long term we should not see it. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190817131144.26884-3-michal.wajdeczko@intel.com
2019-08-17drm/i915/uc: Cleanup fw fetch only if it was successfulMichal Wajdeczko1-5/+3
We can rely on firmware status AVAILABLE to determine if any firmware cleanup is required. Also don't unconditionally reset fw status to SELECTED as we will loose MISSING/ERROR codes. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190817131144.26884-2-michal.wajdeczko@intel.com
2019-08-17drm/i915/selftests: Check the context sizeChris Wilson2-0/+175
Add a redzone to our context image and check the HW does not write into after a context save, to verify that we have the correct context size. (This does vary with feature bits, so test with a live setup that should match how we run userspace.) v2: Check the redzone on every context unpin v3: Use a kernel context to prevent loading garbage for ringbuffer submission Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817073711.5897-1-chris@chris-wilson.co.uk
2019-08-17drm/i915/gtt: Fold gen8 insertions into oneMika Kuoppala1-46/+46
As we give page directory pointer (lvl 3) structure for pte insertion, we can fold both versions into one function by teaching it to get pdp regardless of top level. v2: naming and asserts (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190816094754.26492-1-mika.kuoppala@linux.intel.com
2019-08-17drm/i915/uc: Add explicit DISABLED state for firmwareMichal Wajdeczko8-31/+91
We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will have to take special steps even if GuC firmware is now disabled but hardware exists and could have been previously used. v2: fix logic (Chris/CI) v3: use proper check to avoid probe failure (CI) v4: explain status transitions (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816205658.15020-1-michal.wajdeczko@intel.com
2019-08-17drm/i915: Wrappers for display register waitsDaniele Ceraolo Spurio17-233/+127
To reduce the number of explicit dev_priv->uncore calls in the display code ahead of the introduction of dev_priv->de_uncore, this patch introduces a wrapper for one of the main usages of it, the register waits. When we transition to the new uncore, we can just update the wrapper to point to the appropriate structure. Since the vast majority of waits are on a set or clear of a bit or mask, add set & clear flavours of the wrapper to simplify the code. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20190816012343.36433-7-daniele.ceraolospurio@intel.com
2019-08-16drm/i915: Move gmbus definitions out of i915_reg.hDaniele Ceraolo Spurio3-21/+24
They're not related to registers, so move them to the more appropriate intel_gmbus.h Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-4-daniele.ceraolospurio@intel.com
2019-08-16drm/i915: Move engine IDs out of i915_reg.hDaniele Ceraolo Spurio3-24/+24
To remove the dependency between the GT headers and i915_reg.h, move the definition of the engine IDs/classes to intel_engine_types.h Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-3-daniele.ceraolospurio@intel.com
2019-08-16drm/i915: Move i915_power_well_id out of i915_reg.hDaniele Ceraolo Spurio4-21/+23
It has nothing to do with registers, so move it to the more appropriate intel_display_power.h Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-2-daniele.ceraolospurio@intel.com
2019-08-16drm/i915/execlists: Lift process_csb() out of the irq-off spinlockChris Wilson5-64/+108
If we only call process_csb() from the tasklet, though we lose the ability to bypass ksoftirqd interrupt processing on direct submission paths, we can push it out of the irq-off spinlock. The penalty is that we then allow schedule_out to be called concurrently with schedule_in requiring us to handle the usage count (baked into the pointer itself) atomically. As we do kick the tasklets (via local_bh_enable()) after our submission, there is a possibility there to see if we can pull the local softirq processing back from the ksoftirqd. v2: Store the 'switch_priority_hint' on submission, so that we can safely check during process_csb(). 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/20190816171608.11760-1-chris@chris-wilson.co.uk
2019-08-16drm/omap: displays: Remove unused panel driversLaurent Pinchart9-2493/+0
drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01, NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the omapdrm-specific drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-3-laurent.pinchart@ideasonboard.com
2019-08-16video: omapfb2: Make standard and custom panel drivers mutually exclusiveLaurent Pinchart1-0/+5
Standard DRM panel drivers for several panels used by omapfb2 are now available. Their module name clashes with the modules from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver is disabled, and the DRM panel drivers are useless in that case, make the omapfb2 panels depend on the standard DRM panels being disabled to fix the name clash. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: dc2e1e5b279966 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel") Fixes: 415b8dd0871188 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel") Fixes: 1c8fc3f0c5d280 ("drm/panel: Add driver for the Sony ACX565AKM panel") Fixes: c9cf4c2a3bd35f ("drm/panel: Add driver for the Sharp LS037V7DW01 panel") Fixes: df439abe650177 ("drm/panel: Add driver for the NEC NL8048HL11 panel") Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [added tags] Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-2-laurent.pinchart@ideasonboard.com
2019-08-16drm/i915: Markup expected timeline locks for i915_activeChris Wilson13-27/+58
As every i915_active_request should be serialised by a dedicated lock, i915_active consists of a tree of locks; one for each node. Markup up the i915_active_request with what lock is supposed to be guarding it so that we can verify that the serialised updated are indeed serialised. 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/20190816121000.8507-2-chris@chris-wilson.co.uk
2019-08-16drm/i915/gt: Mark context->active_count as protected by timeline->mutexChris Wilson5-2/+24
We use timeline->mutex to protect modifications to context->active_count, and the associated enable/disable callbacks. Due to complications with engine-pm barrier there is a path where we used a "superlock" to provide serialised protect and so could not unconditionally assert with lockdep that it was always held. However, we can mark the mutex as taken (noting that we may be nested underneath ourselves) which means we can be reassured the right timeline->mutex is always treated as held and let lockdep roam free. 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/20190816121000.8507-1-chris@chris-wilson.co.uk
2019-08-16drm/i915/wopcm: Fix SPDX tag locationMichal Wajdeczko1-3/+2
Move SPDX tag to first line, and update year to 2019. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816105501.31020-6-michal.wajdeczko@intel.com
2019-08-16drm/i915/wopcm: Update error messagesMichal Wajdeczko1-20/+24
All WOPCM error messages are device specific, so use device specific error functions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816105501.31020-5-michal.wajdeczko@intel.com
2019-08-16drm/i915/wopcm: Try to use already locked WOPCM layoutMichal Wajdeczko1-2/+27
If WOPCM layout is already locked in HW we shouldn't continue with our own partitioning as it could be likely different and we will be unable to enforce it and fail. Instead we should try to reuse what is already programmed, maybe there will be a fit. This should enable us to reload driver with slightly different HuC firmware (or even without HuC) without need to reboot. v2: reordered/rebased Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-4-michal.wajdeczko@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-30 05:29:10 +0300