Dave Airlie [Thu, 29 Nov 2018 00:21:23 +0000 (10:21 +1000)]
Merge tag 'drm-misc-next-2018-11-28' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v4.21:
Core Changes:
- Merge drm_info.c into drm_debugfs.c
- Complete the fake drm_crtc_commit's hw_done/flip_done sooner.
- Remove deprecated drm_obj_ref/unref functions. All drivers use get/put now.
- Decrease stack use of drm_gem_prime_mmap.
- Improve documentation for dumb callbacks.
Driver Changes:
- Add edid support to virtio.
- Wait on implicit fence in meson and sun4i.
- Add support for BGRX8888 to sun4i.
- Preparation patches for sun4i driver to start supporting linear and tiled YUV formats.
- Add support for HDMI 1.4 4k modes to meson, and support for VIC alternate timings.
- Drop custom dumb_map in vkms.
- Small fixes and cleanups to v3d.
Eric Anholt [Mon, 26 Nov 2018 21:59:28 +0000 (13:59 -0800)]
drm/vkms: Drop custom vkms_dumb_map().
This is the same as the default drm_gem_dumb_map_offset()
implementation, except that this one missed the ban on userspace
mapping an imported dmabuf (which seems like intended common behavior
for drivers).
Neil Armstrong [Tue, 6 Nov 2018 10:54:35 +0000 (11:54 +0100)]
drm/meson: Add support for VIC alternate timings
This change is an attempt to handle the alternate clock for the CEA mode.
60Hz vs. 59.94Hz, 30Hz vs 29.97Hz or 24Hz vs 23.97Hz on the Amlogic Meson SoC
DRM Driver pixel clock generation.
The actual clock generation will be moved to the Common Clock framework once
all the video clock are handled by the Amlogic Meson SoC clock driver,
then these alternate timings will be handled in the same time in a cleaner
fashion.
Neil Armstrong [Tue, 6 Nov 2018 09:35:09 +0000 (10:35 +0100)]
drm/meson: Add HDMI 1.4 4k modes
Add the timings for the HDMI 1.4 4K modes support :
- 3840x2160@30
- 3840x2160@25
- 3840x2160@24
Since the 297000Hz pixel clock is already managed and the modes are
compatible with the HDMI 1.4 current HDMI PHY+Controller support, only
the missing timings values needs to be added.
Daniel Vetter [Tue, 27 Nov 2018 09:19:21 +0000 (10:19 +0100)]
drm: Improve dumb callback docs
Noticed while reviewing a patch from Eric. Also add a todo for the
dumb_map_offset callbacks (it should be simple to do, but piles of
work). Plus fix up vbox, because vbox.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nicholas Mc Guire <der.herr@hofr.at> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Fabio Rafael da Rosa <fdr@pid42.net> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181127091921.8325-1-daniel.vetter@ffwll.ch
drm/sun4i: Make pitch even for GEM dumb alloc as per hardware constraint
Our hardware requires the pitch to be an even number when using YUV
formats with the frontend. Implement a driver-specific callback for GEM
dumb allocation that sets the pitch accordingly.
Since only the bpp is passed (and not the format), we cannot really
distinguish if this alignment is really required. Since it doesn't hurt
to align the pitch anyway, always do it.
drm/sun4i: frontend: Apply format sub-sampling to CH1 dimensions
The frontend comes with two "channels", that can be configured
independently. When used in YUV mode, the first channel (CH0) represents
the luminance component while the second channel (CH1) represents the
chrominance. In RGB mode, both have to be configured the same way.
Use variables (with the YUV terminology) for each channel's
dimensions, calculating the chroma dimensions from the luma dimensions
and the sub-sampling factors from the format description.
Since the configured size only has pixel precision, the fractional
fixed-point part of the source size is dropped for both components to
ensure that the scaling factors are accurate.
drm/sun4i: backend: Detail the YUV to RGB values coding explanation
The values in the BT601 YUV to RGB colorspace translation are not
simply coded as multiples, but rather as fixed-point signed fractional
values on a given number of bits. Add an explanation about that.
drm/sun4i: frontend: Add support for the BGRX8888 input format
This introduces support for the BGRX8888 input format for the frontend,
with its associated pixel sequence value definition. Other fields are
already configured correctly as they no longer depend on the format's
fourcc directly.
drm/sun4i: frontend: Determine input mode based on the number of planes
Use the number of planes associated with the DRM format to determine the
input mode configuration instead of the format iteself. This way, the
helper can be used for all packed formats without future changes.
drm/sun4i: frontend: Add proper definitions for format registers
This introduces proper definitions for the input and output format
configuration registers instead of a macro and raw values in the code,
with the intent to increase code readability and reduce indirections.
drm/sun4i: frontend: Add helpers for input data mode and pixel sequence
This introduces new helpers for retrieving the input data mode and pixel
sequence register field values based on the DRM format instead of
hardcoding these. This makes it easier to add support for more formats.
drm/sun4i: frontend: Move CSC bypass setup to format update routine
In order to support YUV to RGB conversion with the frontend (which is
generally used for connecting with the backend), the CSC block must not
be bypassed.
As a result, the bit to enable CSC bypass is moved from the runtime
resume routine to the format update routine, so that it can disabled
when introducing support for YUV formats later.
drm/sun4i: Rename sun4i_backend_layer_formats to sun4i_layer_formats
Since more formats can be supported by the frontend, rename the
variable listing the layer formats to avoid suggesting that the backend
itself supports all the listed formats.
drm/sun4i: backend: Avoid counting YUV planes that use the frontend
Our hardware has a limited number of YUV planes (usually 1) that can be
supported using the backend only. However, YUV planes can also be
supported by the frontend and must then not be counted when checking for
that limitation.
Only count the YUV plane when the frontend is not used.
drm/sun4i: backend: Use a specific function to check if a plane is supported
Before this patch, it is assumed that a plane is supported either
through the frontend or through the backend alone. However, the DRM
interface does not allow finely reporting our hardware capabilities
and there are cases where neither are support.
In particular, some plane formats are supported by the backend and not
the frontend, so they can only be supported without scaling.
drm/sun4i: backend: Refine the logic behind using the frontend
Checking that scaling is in use is not sufficient as a condition to
decide to use the frontend.
Since not all layer formats are supported by the frontend, we need to
check for that support first. Then, the frontend must only be enabled
if the backend doesn't support the format or that scaling is required.
drm/sun4i: frontend: Add a helper and a list for supported formats
In order to check whether the frontend supports a specific format, an
explicit list and a related helper are introduced.
Just like in the backend, the prototype of the helper is added to the
frontend header so that it can be used later on. The helper is also
exported because it will be used outside of the frontend module.
drm/sun4i: Add TODO comment about supporting scaling with the backend
The backend allows integer-only scaling but can handle alpha components,
unlike the frontend. It could be useful to add support for this
eventually, so add a short TODO comment describing the situation.
drm/sun4i: frontend: Replace ARGB with XRGB as supported format
The frontend documentation (for the A33) mentions that ARGB is supported
as output, but with the alpha component always set to 0xff. In practice,
this means that the alpha component cannot be preserved when going
through the frontend. Since the information is lost, ARGB is not
properly supported.
As a result, expose the matching format supported by the frontend (both
for input and output) as XRGB instead of ARGB.
Since ARGB was the selected format for connecting the frontend to the
backend, change it to XRGB to reflect this as well.
The A31 and A80 SoCs apparently have a bit to enable proper alpha,
but this is not supported at this point (see the comment already in the
code).
drm/sun4i: Cleanup video/YUV source before enabling a layer
This adds a dedicated function for cleaning the video and YUV source
channel layer enable bits. This function is called first on layer atomic
update to make sure that there are no leftover bits from previous
plane configuration that were not cleaned until now.
It fixes issues when alternating between video and YUV planes, where
both bits would be set eventually, leading to broken plane display.
Ville Syrjälä [Thu, 22 Nov 2018 14:34:12 +0000 (16:34 +0200)]
drm/atomic-helper: WARN if fake_commit->hw_done is not completed as expected
For real commits we WARN if ->hw_done hasn't been completed by the time
drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for
the fake commit.
Consider the following scenario:
1. nonblocking enable crtc
2. wait for the event
3. nonblocking disable crtc
On i915 this can lead to a spurious -EBUSY from step 3 on
account of non-enabled planes getting the fake_commit in step 1
and we don't complete the fake_commit-> flip_done until
drm_atomic_helper_commit_hw_done() which can happen a long
time after the flip event was sent out.
This will become somewhat easy to hit on SKL+ once we start
to add all the planes for the crtc to every modeset commit
for the purposes of forcing a watermark register programming
[1].
To make the race a little less pronounced let's complete
fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done().
For the single crtc case this should make the race quite
theoretical, assuming drm_atomic_helper_wait_for_flip_done()
actually has to wait for the real commit flip_done. In case
the real commit flip_done gets completed singificantly before
drm_atomic_helper_wait_for_flip_done(), or we are dealing with
multiple crtcs whose vblanks don't line up nicely the race still
exists.
Laurent Pinchart [Sun, 11 Nov 2018 02:15:08 +0000 (04:15 +0200)]
drm: rcar-du: Reject modes that fail CRTC timing requirements
The hardware requires the HDSR and VDSR registers to be set to 1 or
higher. This translates to a minimum combined horizontal sync and back
porch of 20 pixels and a minimum vertical back porch of 3 lines. Reject
modes that fail those requirements.
The rcar-du driver supports probe deferral for external clocks, but
implements it badly by checking the wrong pointer due to a bad copy and
paste. Fix it.
While at it, reject invalid clocks outright for DU channels that have a
display PLL, as the external clock is mandatory in that case. This
avoids a WARN_ON() at runtime.
Laurent Pinchart [Wed, 17 Oct 2018 23:57:39 +0000 (02:57 +0300)]
drm: rcar-du: lvds: Add R8A77965 support
Add support for the R-Car M3-N (R8A77965) SoC to the LVDS encoder
driver. The encoder appears identical to the M3-W version, we can thus
simply point to the generic Gen3 data.
drm/shmobile: Replace drm_dev_unref with drm_dev_put
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
drm/rcar-du: Replace drm_dev_unref with drm_dev_put
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Noralf Trønnes [Wed, 21 Nov 2018 18:02:15 +0000 (19:02 +0100)]
drm/prime: Fix drm_gem_prime_mmap() stack use
drivers/gpu/drm/drm_prime.c: In function 'drm_gem_prime_mmap':
>> drivers/gpu/drm/drm_prime.c:688:1: warning: the frame size of 1592 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Fix by allocating on the heap.
Fixes: 7698799f9554 ("drm/prime: Add drm_gem_prime_mmap()") Reported-by: kbuild test robot <lkp@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181121180215.13881-1-noralf@tronnes.org
Qiang Yu [Thu, 22 Nov 2018 01:44:17 +0000 (09:44 +0800)]
drm/sun4i: wait on implicit fence before display
Render like lima will attach a fence to the framebuffer
dma_buf, display like sun4i should wait it finish before
show the framebuffer. Otherwise tearing will be observed.
Dave Airlie [Thu, 22 Nov 2018 02:54:33 +0000 (12:54 +1000)]
Merge tag 'drm-misc-next-2018-11-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v4.21, part 2:
UAPI Changes:
- Remove syncobj timeline support from drm.
Cross-subsystem Changes:
- Document canvas provider node in the DT bindings.
- Improve documentation for TPO TPG110 DT bindings.
Core Changes:
- Use explicit state in drm atomic functions.
- Add panel quirk for new GPD Win2 firmware.
- Add DRM_FORMAT_XYUV8888.
- Set the default import/export function in prime to drm_gem_prime_import/export.
- Add a separate drm_gem_object_funcs, to stop relying on dev->driver->*gem* functions.
- Make sure that tinydrm sets the virtual address also on imported buffers.
Driver Changes:
- Support active-low data enable signal in sun4i.
- Fix scaling in vc4.
- Use canvas provider node in meson.
- Remove unused variables in sti and qxl and cirrus.
- Add overlay plane support and primary plane scaling to meson.
- i2c fixes in drm/bridge/sii902x
- Fix mailbox read size in rockchip.
- Spelling fix in panel/s6d16d0.
- Remove unnecessary null check from qxl_bo_unref.
- Remove unused arguments from qxl_bo_pin.
- Fix qxl cursor pinning.
Chris Wilson [Wed, 21 Nov 2018 15:16:53 +0000 (15:16 +0000)]
drm/i915: Show waiter's status on engine dump
When showing the list of waiters, include the task's status so that we
can tell if they have been woken up and are waiting for the CPU, or if
they are still waiting to be woken.
Ville Syrjälä [Tue, 20 Nov 2018 13:54:50 +0000 (15:54 +0200)]
drm/i915: Add rotation readout for plane initial config
If we need to force a full plane update before userspace/fbdev
have given us a proper plane state we should try to maintain the
current plane state as much as possible (apart from the parts
of the state we're trying to fix up with the plane update).
To that end add basic readout for the plane rotation and
maintain it during the initial fb takeover.
Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120135450.3634-2-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Tue, 20 Nov 2018 13:54:49 +0000 (15:54 +0200)]
drm/i915: Force a LUT update in intel_initial_commit()
If we force a plane update to fix up our half populated plane state
we'll also force on the pipe gamma for the plane (since we always
enable pipe gamma currently). If the BIOS hasn't programmed a sensible
LUT into the hardware this will cause the image to become corrupted.
Typical symptoms are a purple/yellow/etc. flash when the driver loads.
To avoid this let's program something sensible into the LUT when
we do the plane update. In the future I plan to add proper plane
gamma enable readout so this is just a temporary measure.
Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120135450.3634-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Imre Deak [Mon, 19 Nov 2018 18:00:21 +0000 (20:00 +0200)]
drm/i915: Make CHICKEN_TRANS reg not depend on enum value
Depending on the transcoder enum values to translate from transcoder to
the corresponding CHICKEN_TRANS register can easily break if we add a
new transcoder. Add an explicit mapping instead, by using helpers to
look up the register instance either by transcoder or port (since
unconveniently the registers have both port and transcoder specific
bits).
While at it also check for the correctness of GEN, port, transcoder. I
wasn't sure if psr2_enabled can only be set for GEN9+, but that seems to
be the case indeed (see setting of sink_psr2_support in
intel_psr_init_dpcd()).
v2 (Ville):
- Make gen9_chicken_trans_reg() internal to intel_psr.c.
- s/trans/cpu_transcoder/
Imre Deak [Tue, 20 Nov 2018 09:23:25 +0000 (11:23 +0200)]
drm/i915: Add code comment on assumption of pipe==transcoder
Add a comment to the pipe and transcoder enum definitions about our
assumption in the code about enum values for pipes and transcoders
with a 1:1 transcoder -> pipe mapping.
v2:
- Clarify more what are the assumptions about the enum values. (Ville)
v3: (Lucas)
- s/->/ -> / so it looks less like pointer dereferencing.
- Use pipe enums as initializers in the transcoder enum definition.
Imre Deak [Tue, 20 Nov 2018 09:23:24 +0000 (11:23 +0200)]
drm/i915: Make EDP PSR flags not depend on enum values
Depending on the transcoder enum values to translate from transcoder
to EDP PSR flags can easily break if we add a new transcoder. So remove
the dependency by using an explicit mapping.
While at it also add a WARN for unexpected trancoders.
v2:
- Simplify things by defining flag shift values instead of indices.
- s/trans/cpu_transcoder/ (Ville)
v3:
- Define flags to look like separate bits instead of the values of
the same bitfield. (Ville)
Imre Deak [Tue, 20 Nov 2018 09:23:23 +0000 (11:23 +0200)]
drm/i915: Make pipe/transcoder offsets not depend on enum values
Depending on the transcoder enum values to translate from transcoder
to pipe/transcoder register addresses can easily break if we add a new
transcoder. So remove the dependency by using named initializers.
Gerd Hoffmann [Tue, 30 Oct 2018 06:32:05 +0000 (07:32 +0100)]
virtio-gpu: add VIRTIO_GPU_F_EDID feature
The feature allows the guest request an EDID blob (describing monitor
capabilities) for a given scanout (aka virtual monitor connector).
It brings a new command message, which has just a scanout field (beside
the standard virtio-gpu header) and a response message which carries the
EDID data.
QEMU keeps a vram reference to the last QXLCursorCmd it received.
This QXLCursorCmd command points to a QXLCursor instance (stored in vram
too). However, while the QXLCursorCmd memory is pinned, the QXLCursor
memory is not.
When booting a recent Fedora to its login screen while monitoring the
QXLCursorCmd QEMU holds, it's possible to see the QXLCursor memory
becoming invalid shortly after boot. Pinning that memory ensures that
that QXLCursor memory is not going to be moved by the guest kernel.
Moving the pin/unpin to qxl_release_list_add()/qxl_release_free_list()
would be a more generic fix. However, doing this quickly exhausts QXL
video memory, so more fixing would be needed before this is workable.
YueHaibing [Thu, 15 Nov 2018 12:10:36 +0000 (12:10 +0000)]
drm/cirrus: Remove set but not used variable 'bo'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/cirrus/cirrus_fbdev.c: In function 'cirrusfb_create':
drivers/gpu/drm/cirrus/cirrus_fbdev.c:172:20: warning:
variable 'bo' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit f9aa76a85248 ("drm/kms: driver for virtual cirrus under qemu")
Lucas De Marchi [Sat, 17 Nov 2018 00:42:34 +0000 (16:42 -0800)]
drm/i915: Downgrade unknown CSR firmware warnings
Like it was done in commit 9e180d9991dc ("drm/i915: Downgrade unknown
firmware warnings") for huc and guc: downgrade CSR firmware warnings. If
we have released no firmware yet for a platform, stop scaring the
consumer and merely note its expected absence.
By simply removing the warning and early return we hit the condition
with the appropriate message.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181117004234.23437-2-lucas.demarchi@intel.com
Lucas De Marchi [Sat, 17 Nov 2018 00:42:33 +0000 (16:42 -0800)]
drm/i915: allow to load DMC firmware on next gen
Before commit d8a5b7d79fb7 ("drm/i915/csr: keep max firmware size together
with firmare name and version") it was possible to load the firmware for
testing purposes via parameter. Let's use the size of the last known
platform to recover that behavior.
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
v7: Added is_yuv field initialization according to latest
drm_fourcc format structure initialization changes.
v8: Edited commit message to be more clear about skl+, renamed
PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
doesn't support per-pixel alpha. Fixed minor code issues.
v9: Moved DRM format check to proper place in intel_framebuffer_init.
v10: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV8888
v11: Fixed rebase conflict, caused by added new formats to drm-tip
meanwhile.
Noralf Trønnes [Sat, 10 Nov 2018 14:56:46 +0000 (15:56 +0100)]
drm/cma-helper: Add DRM_GEM_CMA_VMAP_DRIVER_OPS
This adds functionality to the CMA helper which ensures that the kernel
virtual address is set on the CMA GEM object also for imported buffers.
The drivers have been audited to ensure that none set ->vaddr on imported
buffers, making the conditional dma_buf_vunmap() call in
drm_gem_cma_free_object() safe.
Noralf Trønnes [Sat, 10 Nov 2018 14:56:45 +0000 (15:56 +0100)]
drm/gem: Add drm_gem_object_funcs
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself, it is
easier to have core helpers for the the various buffer types. The driver
only has to make the decision about buffer type on GEM object creation
and all other callbacks can be handled by the chosen helper.
drm_driver->gem_prime_res_obj has not been added since there's a todo to
put a reservation_object into drm_gem_object.
v3: Add todo entry
v2: Drop drm_gem_object_funcs->prime_mmap in favour of
drm_gem_prime_mmap() (Daniel Vetter)
v1:
- drm_gem_object_funcs.map -> .prime_map let it only do PRIME mmap like
the function it superseeds (Daniel Vetter)
- Flip around the if ladders and make obj->funcs the first choice
highlighting the fact that this the new default way of doing it
(Daniel Vetter)
Jani Nikula [Fri, 16 Nov 2018 12:07:29 +0000 (14:07 +0200)]
drm/i915/fixed: cosmetic cleanup
Clean up fixed point temp variable initialization, use the more
conventional tmp name for temp variables, add empty lines before
return. No functional changes.
Chris Wilson [Mon, 19 Nov 2018 15:41:53 +0000 (15:41 +0000)]
drm/i915: Write GPU relocs harder with gen3
Under moderate amounts of GPU stress, we can observe on Bearlake and
Pineview (later gen3 models) that we execute the following batch buffer
before the write into the batch is coherent. Adding extra (tested with
upto 32x) MI_FLUSH to either the invalidation, flush or both phases does
not solve the incoherency issue with the relocations, but emitting the
MI_STORE_DWORD_IMM twice does. So be it.
Quite obviously the driver depends on I2C_MUX, but adding a "depends on"
introduces a recursive dependency, therefore this patch selects I2C_MUX
instead.
Chris Wilson [Fri, 2 Nov 2018 16:12:12 +0000 (16:12 +0000)]
drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture
Since capturing the error state requires fiddling around with the GGTT
to read arbitrary buffers and is itself run under stop_machine(), it
deadlocks the machine (effectively a hard hang) when run in conjunction
with Broxton's VTd workaround to serialize GGTT access.
v2: Store the ERR_PTR in first_error so that the error can be reported
to the user via sysfs.
v3: Mention the quirk in dmesg (using info as per usual)
Fixes: 0ef34ad6222a ("drm/i915: Serialize GTT/Aperture accesses on BXT") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: John Harrison <john.C.Harrison@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181102161232.17742-5-chris@chris-wilson.co.uk
Damian Kos [Tue, 6 Nov 2018 15:37:05 +0000 (15:37 +0000)]
drm/rockchip: fix for mailbox read size
Some of the functions (like cdn_dp_dpcd_read, cdn_dp_get_edid_block)
allow to read 64KiB, but the cdn_dp_mailbox_read_receive, that is
used by them, can read only up to 255 bytes at once. Normally, it's
not a big issue as DPCD or EDID reads won't (hopefully) exceed that
value.
The real issue here is the revocation list read during the HDCP
authentication process. (problematic use case:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/cdn-dp-reg.c#1152)
The list can reach 127*5+4 bytes (num devs * 5 bytes per ID/Bksv +
4 bytes of an additional info).
In other words - CTSes with HDCP Repeater won't pass without this
fix. Oh, and the driver will most likely stop working (best case
scenario).
Dave Airlie [Mon, 19 Nov 2018 01:07:52 +0000 (11:07 +1000)]
Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux into drm-next
New features for 4.21:
amdgpu:
- Support for SDMA paging queue on vega
- Put compute EOP buffers into vram for better performance
- Share more code with amdkfd
- Support for scanout with DCC on gfx9
- Initial kerneldoc for DC
- Updated SMU firmware support for gfx8 chips
- Rework CSA handling for eventual support for preemption
- XGMI PSP support
- Clean up RLC handling
- Enable GPU reset by default on VI, SOC15 dGPUs
- Ring and IB test cleanups
amdkfd:
- Share more code with amdgpu
ttm:
- Move global init out of the drivers
scheduler:
- Track if schedulers are ready for work
- Timeout/fault handling changes to facilitate GPU recovery
projects / linux.git / log