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

[[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

[[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 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 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 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 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

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 >

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 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 > >

[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

[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

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 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 : > >

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 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: [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: [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

[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

[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

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.

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: [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

[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

[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: [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

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: [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: [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] 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

[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

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 =

[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: [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: [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

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: [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 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 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 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 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 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 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 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] 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 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 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

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 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

[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 ---

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

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: [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

[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 +

[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

[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

[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

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

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 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

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: [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 ---

[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: [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

[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 |

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:

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'