Re: [PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs

Hi Am 14.01.20 um 16:31 schrieb Yannick FERTRE: > Thanks for the patch. > > Tested-by: Yannick Fertré Thanks for testing all these patches. Best regards Thomas > > BR > Yannick Fertré > > > On 1/10/20 10:21 AM, Thomas Zimmermann wrote: >> The new callback get_scanout_position() reads the

nouveau-next 5.6

Hey Dave, It's a little late in the -next cycle, but final firmware images from NVIDIA appear to be ready now, so I've spent the last few days testing/tidying up this code to get it ready to upstream - finally. Brief overview (more info in commit messages): - Rewrite of the ACR (formerly

Re: [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

On Tue, Jan 14, 2020 at 04:11:40PM +0200, Jani Nikula wrote: > On Mon, 06 Jan 2020, Kai-Heng Feng wrote: > > Hi Jani, > > > >> On Dec 24, 2019, at 16:42, Kai-Heng Feng > >> wrote: > >> > >> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port > >> becomes useless and never

Re: [PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: The new callback get_scanout_position() reads the current location of the scanout process. The operation is currentyl located in struct drm_driver,

Re: [PATCH 09/23] drm: Remove struct drm_driver.get_scanout_position()

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: All users of struct drm_driver.get_scanout_position() have been covnerted to the respective CRTC helper function. Remove the callback from struct

Re: [PATCH 08/23] drm/stm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm over.

Re: [PATCH 23/23] drm: Cleanup VBLANK callbacks in struct drm_driver

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: All non-legacy users of VBLANK functions in struct drm_driver have been converted to use the respective interfaces in struct drm_crtc_funcs. The

Re: [PATCH 19/23] drm/stm: Convert to CRTC VBLANK callbacks

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert stm over. Signed-off-by: Thomas

Re: [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

On Tue, 14 Jan 2020, Jani Nikula wrote: > On Tue, 14 Jan 2020, Wambui Karuga wrote: >> Converts the printk based logging macros in i915/display/intel_audio.c >> to the struct drm_device based logging macros. > > Couple of comments inline. PS. This is Reviewed-by: Jani Nikula and I'm fine

Re: [PATCH v2] drm/syncobj: Add documentation for timeline syncobj

Am 14.01.20 um 13:19 schrieb Lionel Landwerlin: We've added a set of new APIs to manipulate syncobjs holding timelines of dma_fence. This adds a bit of documentation about how this works. v2: Small language nits (Lionel) Signed-off-by: Lionel Landwerlin Cc: Christian Koenig Cc: Jason

Re: [PATCH] drm/msm: Fix error about comments within a comment block

On Mon, Jan 13, 2020 at 02:04:46PM -0800, Douglas Anderson wrote: > My compiler yells: > .../drivers/gpu/drm/msm/adreno/adreno_gpu.c:69:27: > error: '/*' within block comment [-Werror,-Wcomment] > > Let's fix. grumble something about the road being paved with good intentions

Re: [PATCH 23/23] drm: Cleanup VBLANK callbacks in struct drm_driver

Hi Am 12.01.20 um 23:53 schrieb Daniel Vetter: > On Fri, Jan 10, 2020 at 10:21:27AM +0100, Thomas Zimmermann wrote: >> All non-legacy users of VBLANK functions in struct drm_driver have been >> converted to use the respective interfaces in struct drm_crtc_funcs. The >> remaining users of VBLANK

Re: [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

On Mon, 06 Jan 2020, Kai-Heng Feng wrote: > Hi Jani, > >> On Dec 24, 2019, at 16:42, Kai-Heng Feng wrote: >> >> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port >> becomes useless and never responds to cable hotplugging: >> [3.031904] [drm:lspcon_init [i915]] *ERROR*

Re: [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

On Tue, 14 Jan 2020, Wambui Karuga wrote: > Converts the printk based logging macros in i915/display/intel_audio.c > to the struct drm_device based logging macros. Couple of comments inline. BR, Jani. > This transformation was achieved using the following coccinelle script > that matches the

Re: [PATCH v3 4/7] drm/panfrost: Add support for multiple regulators

On Tue, Jan 14, 2020 at 03:15:59PM +0800, Nicolas Boichat wrote: > - I couldn't find a way to detect the number of regulators in the >device tree, if we wanted to refuse to probe the device if there >are too many regulators, which might be required for safety, see >the thread on v2

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote: > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse wrote: > > > > On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote: > > > This > > > > > > 1) Enables core DRM syncobj support. > > > 2) Adds options to the submission

[pull] drm/msm: msm-next for 5.6

Hi Dave, This time around: + sc7180 display + DSI support + a618 (sc7180) support + more UBWC (bandwidth compression) support + various cleanups to handle devices that use vs don't use zap fw, etc + usual random cleanups and fixes The following changes since commit

[PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

From: Sean Paul This patch uses a ring_buffer to keep a "flight recorder" (name credit Weston) of DRM logs for a specified set of debug categories. The user writes a bitmask of debug categories to the "trace_mask" node and can read log messages from the "trace" node. These nodes currently exist

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

On Tue, Jan 14, 2020 at 08:52:43AM -0800, Rob Clark wrote: > On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse wrote: > > > > On Mon, Jan 13, 2020 at 10:36:05AM -0500, Brian Ho wrote: > > > + > > > + vaddr = base_vaddr + args->offset; > > > + > > > + /* Assumes WC mapping */ > > > + ret =

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

On Tue, 14 Jan 2020 12:21:43 -0500 Sean Paul wrote: > From: Sean Paul > > This patch uses a ring_buffer to keep a "flight recorder" (name credit Weston) > of DRM logs for a specified set of debug categories. The user writes a > bitmask of debug categories to the "trace_mask" node and can read

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

On Tue, Jan 14, 2020 at 09:30:00AM -0800, Kristian Kristensen wrote: > On Tue, Jan 14, 2020 at 9:23 AM Jordan Crouse wrote: > > > > On Tue, Jan 14, 2020 at 08:52:43AM -0800, Rob Clark wrote: > > > On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse > > > wrote: > > > > > > > > On Mon, Jan 13, 2020 at

Re: [PATCH v2] drm/dp_mst: clear time slots for ports invalid

Pushed, thanks! On Mon, 2020-01-06 at 18:21 +0800, Wayne Lin wrote: > [Why] > When change the connection status in a MST topology, mst device > which detect the event will send out CONNECTION_STATUS_NOTIFY messgae. > > e.g. src-mst-mst-sst => src-mst (unplug) mst-sst > > Currently, under the

[Bug 206141] VCE UVD ring test failed -110

https://bugzilla.kernel.org/show_bug.cgi?id=206141 Thong Thai (thong.t...@amd.com) changed: What|Removed |Added CC||thong.t...@amd.com ---

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

On Tue, Jan 14, 2020 at 08:41:05AM -0800, Rob Clark wrote: > On Tue, Jan 14, 2020 at 7:58 AM Jordan Crouse wrote: > > > > On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote: > > > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse > > > wrote: > > > > > > > > On Mon, Jan 13, 2020 at

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

On Tue, Jan 14, 2020 at 8:41 AM Rob Clark wrote: > > On Tue, Jan 14, 2020 at 7:58 AM Jordan Crouse wrote: > > > > On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote: > > > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse > > > wrote: > > > > > > > > On Mon, Jan 13, 2020 at

Re: [PATCH 2/2] drm/dp_mst: Handle SST-only branch device case

On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote: > [Why] > While handling LINK_ADDRESS reply, current code expects a peer device > can handle sideband message once the peer device type is reported as > DP_PEER_DEVICE_MST_BRANCHING. However, when the connected device is > a SST branch case, it

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

Dave, Alex, there's an odd bugreport on bugzilla, where Artem is seeing an odd early-boot failure. That one almost certainly has nothing to do with you guys, but see the later odd (and apparently unrelated) report about some AMD graphics firmware issue and a black screen.

[Bug 206141] VCE UVD ring test failed -110

https://bugzilla.kernel.org/show_bug.cgi?id=206141 --- Comment #6 from Janpieter Sollie (janpieter.sol...@dommel.be) --- Created attachment 286813 --> https://bugzilla.kernel.org/attachment.cgi?id=286813=edit Kernel. Config Hi Thong, I use efibootmgr, so no kernel arguments on bootloader, but

Re: [PATCH 1/2] drm/dp_mst: Add a function to determine the mst end device

This patch series looks awesome so far, thank you for the great work! This patch looks great, I think we should just squash it into the next patch though since we don't use this function until then. On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote: > [Why] > For later usage convenience, add the

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

On 1/9/20 2:07 PM, John Hubbard wrote: > On 1/7/20 2:45 PM, John Hubbard wrote: >> Hi, >> >> The "track FOLL_PIN pages" would have been the very next patch, but it is >> not included here because I'm still debugging a bug report from Leon. >> Let's get all of the prerequisite work (it's been

[RFC PATCH 0/2] Security mitigation for Intel Gen7 and Gen7.5

Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via

[RFC PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

From: Prathap Kumar Valsan On gen7 and gen7.5 devices, there could be leftover data residuals in EU/L3 from the retiring context. This patch introduces workaround to clear that residual contexts, by submitting a batch buffer with dedicated HW context to the GPU with ring allocation for each

[RFC PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission

From: Mika Kuoppala This patch adds framework to submit an arbitrary batchbuffer on each context switch to clear residual state for render engine on Gen7/7.5 devices. Signed-off-by: Mika Kuoppala Signed-off-by: Akeem G Abodunrin Cc: Kumar Valsan Prathap Cc: Chris Wilson Cc: Balestrieri

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

On Tue, Jan 14, 2020 at 4:41 PM Linus Torvalds wrote: > > Dave, Alex, > there's an odd bugreport on bugzilla, where Artem is seeing an odd > early-boot failure. > > That one almost certainly has nothing to do with you guys, but see the > later odd (and apparently unrelated) report about some AMD

Re: [RFC PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

Quoting Akeem G Abodunrin (2020-01-14 14:51:36) > From: Prathap Kumar Valsan > > On gen7 and gen7.5 devices, there could be leftover data residuals in > EU/L3 from the retiring context. This patch introduces workaround to clear > that residual contexts, by submitting a batch buffer with

Re: [PATCH 09/10] drm/vkms: plane_state->fb iff plane_state->crtc

On 12/13, Daniel Vetter wrote: > Checking both is one too much, so wrap a WARN_ON around it to stope > the copypasta. > > Signed-off-by: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Haneen Mohammed > Cc: Daniel Vetter > --- > drivers/gpu/drm/vkms/vkms_plane.c | 2 +- > 1 file changed, 1

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

On Tue, Jan 14, 2020 at 08:31:22AM -0500, Harry Wentland wrote: > Fixing Nick's email. > > On 2020-01-10 5:43 p.m., Manasi Navare wrote: > > On Thu, Jan 09, 2020 at 05:24:30PM +0200, Jani Nikula wrote: > >> On Tue, 07 Jan 2020, Manasi Navare wrote: > >>> Adaptive Sync is a VESA feature so add a

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

On Tue, 14 Jan 2020 12:15:08 -0800 John Hubbard wrote: > > > > Hi Andrew and all, > > > > To clarify: I'm hoping that this series can go into 5.6. > > > > Meanwhile, I'm working on tracking down and solving the problem that Leon > > reported, in the "track FOLL_PIN pages" patch, and that

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

On Tue, Jan 14, 2020 at 03:07:56PM +0200, Ville Syrjälä wrote: > On Mon, Jan 13, 2020 at 04:39:00PM -0800, Manasi Navare wrote: > > Hi Ville, > > > > So the two major changes you would like to see here are: > > > > use version_greate(edid) function > > and make use of : > >

[RFC PATCH v2 1/2] drm/i915: Add mechanism to submit a context WA on ring submission

From: Mika Kuoppala This patch adds framework to submit an arbitrary batchbuffer on each context switch to clear residual state for render engine on Gen7/7.5 devices. Signed-off-by: Mika Kuoppala Signed-off-by: Akeem G Abodunrin Cc: Kumar Valsan Prathap Cc: Chris Wilson Cc: Balestrieri

[RFC PATCH v2 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

From: Prathap Kumar Valsan On gen7 and gen7.5 devices, there could be leftover data residuals in EU/L3 from the retiring context. This patch introduces workaround to clear that residual contexts, by submitting a batch buffer with dedicated HW context to the GPU with ring allocation for each

[RFC PATCH v2 0/2] Security mitigation for Intel Gen7 HWs

Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via

Re: [PATCH 09/10] drm/vkms: plane_state->fb iff plane_state->crtc

Hi Rodrigo. On Tue, Jan 14, 2020 at 06:50:13PM -0500, Rodrigo Siqueira wrote: > On 12/13, Daniel Vetter wrote: > > Checking both is one too much, so wrap a WARN_ON around it to stope > > the copypasta. > > > > Signed-off-by: Daniel Vetter > > Cc: Rodrigo Siqueira > > Cc: Haneen Mohammed > >

RE: [PATCH 1/2] drm/dp_mst: Add a function to determine the mst end device

[AMD Public Use] > -Original Message- > From: Lyude Paul > Sent: Wednesday, January 15, 2020 5:16 AM > To: Lin, Wayne ; dri-devel@lists.freedesktop.org; > amd-...@lists.freedesktop.org > Cc: Kazlauskas, Nicholas ; Wentland, Harry > ; Zuo, Jerry > Subject: Re: [PATCH 1/2] drm/dp_mst:

RE: [PATCH 2/2] drm/dp_mst: Handle SST-only branch device case

[AMD Public Use] > -Original Message- > From: Lyude Paul > Sent: Wednesday, January 15, 2020 5:19 AM > To: Lin, Wayne ; dri-devel@lists.freedesktop.org; > amd-...@lists.freedesktop.org > Cc: Kazlauskas, Nicholas ; Wentland, Harry > ; Zuo, Jerry ; Ville Syrjälä > ; Wentland, Harry >

[[Intel-gfx] [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915

Device specific dev_WARN and dev_WARN_ONCE macros available in kernel include device information in the backtrace, so we know what device the warnings originate from. Similar to this, add new struct drm_device based drm_WARN* macros. These macros include device information in the backtrace, so we

[[Intel-gfx] [PATCH v2 01/10] drm/print: introduce new struct drm_device based WARN* macros

Add new struct drm_device based WARN* macros. These are modeled after the core kernel device based WARN* macros. These would be preferred over the regular WARN* macros, where possible. These macros include device information in the backtrace, so we know what device the warnings originate from.

[[Intel-gfx] [PATCH v2 01/10] drm/print: introduce new struct drm_device based WARN* macros

Add new struct drm_device based WARN* macros. These are modeled after the core kernel device based WARN* macros. These would be preferred over the regular WARN* macros, where possible. These macros include device information in the backtrace, so we know what device the warnings originate from.

[[Intel-gfx] [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915

Device specific dev_WARN and dev_WARN_ONCE macros available in kernel include device information in the backtrace, so we know what device the warnings originate from. Similar to this, add new struct drm_device based drm_WARN* macros. These macros include device information in the backtrace, so we

[[Intel-gfx] [PATCH v2 02/10] drm/i915/display: Make WARN* drm specific where drm_device ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device struct pointer is readily available. The conversion was done

[[Intel-gfx] [PATCH v2 02/10] drm/i915/display: Make WARN* drm specific where drm_device ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device struct pointer is readily available. The conversion was done

[[Intel-gfx] [PATCH v2 03/10] drm/i915/display: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[[Intel-gfx] [PATCH v2 05/10] drm/i915/gem: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[[Intel-gfx] [PATCH v2 04/10] drm/i915/display: Make WARN* drm specific where encoder ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_encoder struct pointer is available. The conversion was done automatically

[[Intel-gfx] [PATCH v2 06/10] drm/i915/gt: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[[Intel-gfx] [PATCH v2 09/10] drm/i915: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[[Intel-gfx] [PATCH v2 10/10] drm/i915: Make WARN* drm specific where uncore or stream ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_uncore/i915_perf_stream struct pointer is readily available. The conversion

[[Intel-gfx] [PATCH v2 07/10] drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available

drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done

[[Intel-gfx] [PATCH v2 08/10] drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available

Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device struct pointer is readily available. The conversion was done

[PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

Implements an ioctl to wait until a value at a given iova is greater than or equal to a supplied value. This will initially be used by turnip (open-source Vulkan driver for QC in mesa) for occlusion queries where the userspace driver can block on a query becoming available before continuing via

Re: [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote: > On Mon, Jan 13, 2020 at 8:25 AM Rob Clark wrote: > > > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho wrote: > > > > > > Implements an ioctl to wait until a value at a given iova is greater > > > than or equal to a supplied value.

[PATCH] drm/i915: convert to new logging macros based on struct intel_engine_cs.

This patch extracts the struct drm_i915_private device from struct intel_engine_cs and converts the printk based logging macros to the struct drm_based logging macros using the extracted struct. This transformation was achieved using the following coccinelle script: @rule1@ identifier fn, T, E; @@

Re: [PATCH v2 4/4] arm64: dts: sdm845: move gpu zap nodes to per-device dts

On Sun 12 Jan 11:54 PST 2020, Rob Clark wrote: > From: Rob Clark > > We want to specify per-device firmware-name, so move the zap node into > the .dts file for individual boards/devices. This lets us get rid of > the /delete-node/ for cheza, which does not use zap. > Reviewed-by: Bjorn

Re: [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

On Mon, Jan 13, 2020 at 7:37 AM Brian Ho wrote: > > Implements an ioctl to wait until a value at a given iova is greater > than or equal to a supplied value. > > This will initially be used by turnip (open-source Vulkan driver for > QC in mesa) for occlusion queries where the userspace driver can

[PATCH] drm/i915: Fix multiple definition of 'i915_vma_capture_finish'

If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there are some errors like: drivers/gpu/drm/i915/i915_irq.o: In function `i915_vma_capture_finish': ./drivers/gpu/drm/i915/i915_gpu_error.h:312: multiple definition of `i915_vma_capture_finish' drivers/gpu/drm/i915/i915_drv.o:

[PATCH v3 2/3] dt-bindings: panel-simple: Add compatible for Frida FRD350H54004 LCD

Add bindings documentation for the Frida 3.5" (320x240 pixels) 24-bit TFT LCD panel. v2: Switch documentation from plain text to YAML v3: Simply add new compatible to panel-simple.yaml file instead of adding new file Signed-off-by: Paul Cercueil ---

[PATCH 1/2] drm/msm: Add a GPU-wide wait queue

This wait queue is signaled on all IRQs for a given GPU and will be used as part of the new MSM_WAIT_IOVA ioctl so userspace can sleep until the value at a given iova reaches a certain condition. Signed-off-by: Brian Ho --- drivers/gpu/drm/msm/msm_gpu.c | 4 drivers/gpu/drm/msm/msm_gpu.h |

[PATCH] drm/i915/dsi: Fix implicit declaration of function 'acpi_dev*' in 'mipi_exec_i2c'

If no 'CONFIG_ACPI' configured, shouldn't call 'acpi_device_handle', 'acpi_dev_get_resources' and 'acpi_dev_free_resource_list' in function 'mipi_exec_i2c'. Fixes: 8cbf89db2941("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Reported-by: Hulk Robot Signed-off-by:

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse wrote: > > On Mon, Jan 13, 2020 at 10:36:05AM -0500, Brian Ho wrote: > > Implements an ioctl to wait until a value at a given iova is greater > > than or equal to a supplied value. > > > > This will initially be used by turnip (open-source Vulkan

[PATCH v3 3/3] drm/panel: simple: Add support for the Frida FRD350H54004 panel

The FRD350H54004 is a simple 3.5" 320x240 24-bit TFT panel, found for instance inside the Anbernic RG-350 handheld gaming console. v2: Order alphabetically v3: Add connector_type, and update timings according to the constraints listed in the datasheet Signed-off-by: Paul Cercueil ---

Re: [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

On Mon, Jan 13, 2020 at 2:55 PM Brian Ho wrote: > > On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote: > > On Mon, Jan 13, 2020 at 8:25 AM Rob Clark wrote: > > > > > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho wrote: > > > > > > > > Implements an ioctl to wait until a value at a

Re: [Freedreno] [PATCH 1/2] drm/msm: Add a GPU-wide wait queue

On Mon, Jan 13, 2020 at 9:55 AM Jordan Crouse wrote: > > On Mon, Jan 13, 2020 at 10:36:04AM -0500, Brian Ho wrote: > > This wait queue is signaled on all IRQs for a given GPU and will be > > used as part of the new MSM_WAIT_IOVA ioctl so userspace can sleep > > until the value at a given iova

Re: [PATCH] drm/i915: convert to new logging macros based on struct intel_engine_cs.

On Mon, 13 Jan 2020, Jani Nikula wrote: On Mon, 13 Jan 2020, Chris Wilson wrote: Quoting Wambui Karuga (2020-01-13 11:10:25) fn(...) { ... struct intel_engine_cs *E = ...; +struct drm_i915_private *dev_priv = E->i915; No new dev_priv. Wambui, we're gradually converting all dev_priv

[PATCH 0/2] drm/msm: Add the MSM_WAIT_IOVA ioctl

This patch set implements the MSM_WAIT_IOVA ioctl which lets userspace sleep until the value at a given iova reaches a certain condition. This is needed in turnip to implement the VK_QUERY_RESULT_WAIT_BIT flag for vkGetQueryPoolResults. First, we add a GPU-wide wait queue that is signaled on all

Re: [PATCH v2 2/4] drm/msm: allow zapfw to not be specified in gpulist

On Sun 12 Jan 11:53 PST 2020, Rob Clark wrote: > From: Rob Clark > > For newer devices we want to require the path to come from the > firmware-name property in the zap-shader dt node. > Reviewed-by: Bjorn Andersson > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/msm/adreno/adreno_gpu.c

Re: [PATCH v2 1/4] drm/msm: support firmware-name for zap fw (v2)

On Sun 12 Jan 11:53 PST 2020, Rob Clark wrote: > From: Rob Clark > > Since zap firmware can be device specific, allow for a firmware-name > property in the zap node to specify which firmware to load, similarly to > the scheme used for dsp/wifi/etc. > > v2: only need a single error msg when we

[PATCH next] drm/i915: fix build error without ACPI

If CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=m, compilation complains with undefined references: drivers/gpu/drm/i915/display/intel_panel.o: In function `intel_backlight_device_register': intel_panel.c:(.text+0x4dd9): undefined reference to `backlight_device_register'

[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Frida LCD Co., Ltd.

Add an entry for Shenzhen Frida LCD Co., Ltd. v2: No change v3: No change Signed-off-by: Paul Cercueil Acked-by: Sam Ravnborg Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git

RE: drm_cflush_sg() loops for over 3ms - scheduler not running tasks.

From: David Laight > Sent: 13 January 2020 14:35 > > I've been looking at why some RT processes don't get scheduled promptly. > In my test the RT process's affinity ties it to a single cpu (this may not be > such > a good idea as it seems). > > What I've found is that the Intel i915 graphics

[PATCH] drm/i915: Fix too few arguments to function i915_capture_error_state

If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there is an error when compile the kernel: drivers/gpu/drm/i915/gt/intel_reset.c: In function intel_gt_handle_error: drivers/gpu/drm/i915/gt/intel_reset.c:1233:3: error: too few arguments to function i915_capture_error_state

drm_cflush_sg() loops for over 3ms

I've been looking at why some RT processes don't get scheduled promptly. In my test the RT process's affinity ties it to a single cpu (this may not be such a good idea as it seems). What I've found is that the Intel i915 graphics driver uses the 'events_unbound' kernel worker thread to

Re: [PATCH] drm/i915: convert to new logging macros based on struct intel_engine_cs.

On Mon, 13 Jan 2020, Chris Wilson wrote: Quoting Wambui Karuga (2020-01-13 11:10:25) fn(...) { ... struct intel_engine_cs *E = ...; +struct drm_i915_private *dev_priv = E->i915; No new dev_priv. There should be no reason for drm_dbg here, as the rest of the debug is behind ENGINE_TRACE

Re: [PATCH 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

On 27/12/2019 0.24, Rob Herring wrote: > On Tue, Dec 17, 2019 at 12:15:05PM +0200, Peter Ujfalusi wrote: >> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge. >> >> Signed-off-by: Peter Ujfalusi >> --- >> .../display/bridge/toshiba,tc358768.yaml | 158 ++ >> 1 file

Re: [PULL] drm-intel-next

Quoting Jani Nikula (2020-01-14 11:43:22) > > Hi Dave & Daniel - > > Last batch for v5.6, slightly delayed I'm afraid. I'd like to close https://gitlab.freedesktop.org/drm/intel/issues/738 for 5.6, otherwise we'll have some more nasty emails from bewildered users/devs.

Re: [PULL] drm-intel-next

On Tue, 14 Jan 2020, Chris Wilson wrote: > Quoting Jani Nikula (2020-01-14 11:43:22) >> >> Hi Dave & Daniel - >> >> Last batch for v5.6, slightly delayed I'm afraid. > > I'd like to close https://gitlab.freedesktop.org/drm/intel/issues/738 > for 5.6, otherwise we'll have some more nasty emails

[PATCH v2] drm/syncobj: Add documentation for timeline syncobj

We've added a set of new APIs to manipulate syncobjs holding timelines of dma_fence. This adds a bit of documentation about how this works. v2: Small language nits (Lionel) Signed-off-by: Lionel Landwerlin Cc: Christian Koenig Cc: Jason Ekstrand Cc: David(ChunMing) Zhou ---

[PULL] drm-intel-next

0:53:58 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-01-14 for you to fetch changes up to f2221a50494037af98206713155c8d4f2e7bccaa: drm/i915: Update DRIVER_DATE to 20200114 (2020-01-14 13:39:38 +

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

On Mon, Jan 13, 2020 at 04:39:00PM -0800, Manasi Navare wrote: > Hi Ville, > > So the two major changes you would like to see here are: > > use version_greate(edid) function > and make use of : > drm_for_each_detailed_block() instead of the for loop. > But this function does not parse the

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

Fixing Nick's email. On 2020-01-10 5:43 p.m., Manasi Navare wrote: > On Thu, Jan 09, 2020 at 05:24:30PM +0200, Jani Nikula wrote: >> On Tue, 07 Jan 2020, Manasi Navare wrote: >>> Adaptive Sync is a VESA feature so add a DRM core helper to parse >>> the EDID's detailed descritors to obtain the

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

On Tue, 14 Jan 2020, Harry Wentland wrote: > Fixing Nick's email. > > On 2020-01-10 5:43 p.m., Manasi Navare wrote: >> On Thu, Jan 09, 2020 at 05:24:30PM +0200, Jani Nikula wrote: >>> On Tue, 07 Jan 2020, Manasi Navare wrote: +EXPORT_SYMBOL(drm_get_adaptive_sync_limits); >>> >>> Why the