Re: [PATCH 07/14] drm/mgag200: Add support for MATROX PCI device IDs 0x520 and 0x521

On 19 July 2017 at 00:43, Takashi Iwai wrote: > From: Egbert Eich > > Add two more models G200_PCI and G200 for PCI device IDs 0x520 and > 0x521, respectively. They need to retrieve the reference clock and > pclk min/max values from BIOS, and set up the PLLs

[Bug 101837] libdrm fails to get bus id

https://bugs.freedesktop.org/show_bug.cgi?id=101837 --- Comment #2 from Daniel Power --- dmesg: https://pastebin.com/fcz5mEb0 xorg: https://pastebin.com/2dacJqTe -- You are receiving this mail because: You are the assignee for the

[PATCH v5 6/7] dt-bindings: display: rockchip: fill Documents for vop series

Signed-off-by: Mark Yao --- Changes in v5: - clean document commit title - move changes description out of docummit commit msg Changes in v2: - rename rk322x to rk3228 - correct some vop registers define

[PATCH v5 7/7] drm/rockchip: vop: rk3328: fix overlay abnormal

It's a hardware bug, all window's overlay channel reset value is same, hardware overlay would be die. so we must initial difference id for each overlay channel. The Channel register is supported on all vop will full design. Following is the details for this register VOP_WIN0_CTRL2 bit[7:4]

[PATCH v5 0/7] drm/rockchip: add all full framework vop support

These patches try to make all current rockchip full framework vop works on drm, fill missing vop on full framework. Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big

[PATCH v5 1/7] drm/rockchip: vop: initialize registers directly

At present we are using init_table to initialize some registers, but the Register init table use un-document define, it is unreadable, and sometimes we only want to update tiny bits, init table method is not friendly, it's diffcult to reuse for difference chips. To make it clean, initialize

[PATCH v5 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

In the hardware design process, the design of line flags register is associated with the interrupt register, placing the line flags in the interrupt definition is more reasonable, and it would make multi-vop define easilier. Changes in v3: - Explain more in details, introduce why we need this

[PATCH v5 5/7] drm/rockchip: vop: add a series of vop support

Vop Full framework now has following vops: IP versionchipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big 3.6 rk3399 lit 3.7 rk3228 3.8 rk3328 The above IP version is from H/W define, some of vop support

[PATCH v5 4/7] drm/rockchip: vop: group vop registers

Grouping the vop registers facilitates make register definition clearer, and also is useful for different vop reuse the same group register. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 99 +-

[PATCH v5 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

Since the drm atomic framework, only a small part of the vop register needs sync write, Currently seems only following registers need sync write: cfg_done, standby and interrupt related register. All ctrl registers are using the sync write method that is inefficient, hardcode the write_relaxed

Re: [PATCH v2 5/5] dt-bindings: display: fill Documents for series of vop

On 2017年07月18日 01:24, Rob Herring wrote: On Wed, Jul 12, 2017 at 10:04:02AM +0800, Mark Yao wrote: Changes in v2: - rename rk322x to rk3228(Heiko Stübner) This goes below '---' and you need a commit msg here. Also, it is not clear in the subject this is for Rockchip. Got it, will fix it at

[Bug 93762] Entire system stutters every so often when running proprietary game Minecraft

https://bugs.freedesktop.org/show_bug.cgi?id=93762 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED

linux-next: manual merge of the drm-misc tree with the drm-intel tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/i915_drv.c between commit: 99c539bef538 ("drm/i915: unregister interfaces first in unload") from the drm-intel tree and commit: baf54385af78 ("drm/i915: Drop drm_vblank_cleanup") from the

Re: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq

On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote: > After detecting an IRQ storm, hotplug detection will switch from > irq-based detection to poll-based detection. After a short delay or > when resetting storm detection from debugfs, detection will switch > back to being irq-based. > >

Re: [RFC 1/7] drm/gem: Add drm_gem_dumb_map_offset()

Den 19.07.2017 23.01, skrev Eric Anholt: Noralf Trønnes writes: Add a common drm_driver.dumb_map_offset function for GEM backed drivers. Signed-off-by: Noralf Trønnes Instead of just introducing the new code, could we replace CMA's code with calls

Re: [PATCH v2 0/5] arm64: dts: rockchip: support mail and IPA thermal for rk3399

Am Mittwoch, 19. Juli 2017, 17:06:59 CEST schrieb Caesar Wang: > Hi Rob & Heiko, > > Do we have the chance to merge these patches? From the mali-thermal thingy, it doesn't look like Rob likes that IPA stuff. So I'll most likely pick the other patches that rely on approved bindings after I

Re: [RFC 1/7] drm/gem: Add drm_gem_dumb_map_offset()

Noralf Trønnes writes: > Add a common drm_driver.dumb_map_offset function for GEM backed drivers. > > Signed-off-by: Noralf Trønnes Instead of just introducing the new code, could we replace CMA's code with calls to this at the same time? I suspect that

Re: [RFC 2/7] drm: Add GEM backed framebuffer library

Noralf Trønnes writes: > Den 12.07.2017 15.46, skrev Noralf Trønnes: >> Add a library for drivers that can use a simple representation >> of a GEM backed framebuffer. >> >> Signed-off-by: Noralf Trønnes >> --- > > This patch adds a gem backed

Re: [PATCH v5 4/6] drm: Allow DSI devices to be registered before the host registers.

Eric Anholt writes: > When a mipi_dsi_host is registered, the DT is walked to find any child > nodes with compatible strings. Those get registered as DSI devices, > and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes. > > There is one special case

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

I believe the solution is to not call drm_crtc_vblank_off for atomic modesetting in nouveau_display_fini. I think Ben's working on it. On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann wrote: > mimic the behavior of vblank_disable_fn(), another caller of >

[Bug 100399] Kernel invalid opcode on unbinding amdgpu

https://bugs.freedesktop.org/show_bug.cgi?id=100399 --- Comment #10 from jimijames.b...@gmail.com --- OK, that's weird. Running sudo lsof /dev/dri/* doesn't get me any info about the AMD card at all. I ran it at boot, when it's bound to vfio-pci (I set it up to be that way at boot), then I ran it

Re: [PATCH] gpu: Convert to using %pOF instead of full_name

Hi Rob, Thank you for the patch. On Tuesday 18 Jul 2017 16:43:04 Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob

Re: [RFC][PATCH v3] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

On Wed, Jul 19, 2017 at 3:16 AM, Jose Abreu wrote: > Hi John, > > > On 18-07-2017 18:59, John Stultz wrote: >> Currently the hikey dsi logic cannot generate accurate byte >> clocks values for all pixel clock values. Thus if a mode clock >> is selected that cannot match

Re: [PATCH 3/9] drm/i915: Avoid the gpu reset vs. modeset deadlock

On Wed, Jul 19, 2017 at 3:44 PM, Daniel Vetter wrote: > On Wed, Jul 19, 2017 at 3:32 PM, Chris Wilson > wrote: >> Quoting Daniel Vetter (2017-07-19 13:54:56) >>> ... using the biggest hammer we have. This is essentially a weaponized >>> version

Re: [PATCH v2 0/3] drm/mst: Fix sideband msg reception error path

On Wed, 2017-07-19 at 14:43 +0300, Imre Deak wrote: > This is a resend of the last two patches from [1], addressing Lyude's > comments and adding his R-bs. The first patch in [1] isn't needed any It's "her" by the way :P. Also would you mind resending this with a Cc to sta...@vger.kernel.org

Re: [PATCH v3 3/3] drm/mst: Avoid processing partially received up/down message transactions

On Wed, 2017-07-19 at 16:46 +0300, Imre Deak wrote: > Currently we may process up/down message transactions containing > uninitialized data. This can happen if there was an error during the > reception of any message in the transaction, but we happened to > receive > the last message correctly

Re: [PATCH 2/2] android: amdgpu: fix build break

On 19 July 2017 at 11:18, Chih-Wei Huang wrote: > Define two macros to avoid building errors. > > Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file) > > Signed-off-by: Chih-Wei Huang > --- > amdgpu/Android.mk | 6 ++ > 1 file

[PATCH] drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()

Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") misses some pieces, due to a problem with the patch format, this patch adds the remaining bits. Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") Signed-off-by: Matthias Kaehlcke

Re: [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

El Wed, Jul 19, 2017 at 08:30:36AM +0200 Daniel Vetter ha dit: > On Tue, Jul 18, 2017 at 01:48:53PM -0700, Matthias Kaehlcke wrote: > > Hi Daniel, > > > > El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit: > > > > > On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v7)

/20170719-022127 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) arch/x86/include/asm/uaccess_

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

On Wed, 2017-07-19 at 11:31 +0300, Paul Kocialkowski wrote: > On Tue, 2017-07-18 at 22:21 +0100, Chris Wilson wrote: > > Quoting Paul Kocialkowski (2017-07-18 16:16:26) > > > It may occur that a hotplug uevent is detected at resume, even > > > though it > > > does not indicate that an actual

[PATCH] xf86drm: continue after drmProcessPlatformDevice failure

On ChromeOS devices, readdir() processes the directory in the following order: -NAME- -TYPE- .n/a .. n/a vgem n/a card1 DRM_BUS_PLATFORM renderD129 DRM_BUS_PLATFORM card0 DRM_BUS_PCI renderD128

[PATCH 019/102] drm: kirin: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 021/102] drm/rockchip: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 024/102] drm/sun4i: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 020/102] drm/nouveau/tegra: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 026/102] gpu: host1x: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 025/102] drm/tegra: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 023/102] drm/stm: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 022/102] drm/sti: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH] drm: Prevent early NULL dereference of fb_helper->fb

Prior to the fbdev being asynchronously configured on boot, the fb_helper->fb may be unset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101767 Signed-off-by: Chris Wilson Cc: Thierry Reding Cc: Daniel Vetter ---

[GIT PULL] imx-drm: scanout burst lock support

Hi Dave, please consider merging this tag which improvemes for scanout memory access patterns on i.MX and contains a small cleanup for ipu_plane_atomic_update. regards Philipp The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10

[GIT PULL] imx-drm: fix parallel-display regression and plane format list

Hi Dave, This tag contains a regression fix for the parallel-display output on i.MX and a typo fix for the plane format list that replaces a duplicated entry with the correct format. regards Philipp The following changes since commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c: Linux 4.12

[PATCH v2 7/7] drm/atomic: Remove deprecated accessor macros

Now that the last users have been converted, we can finally get rid of for_each_obj_in_state, we have better macros to replace them with. Signed-off-by: Maarten Lankhorst Cc: Daniel Vetter Cc: Jani Nikula

[PATCH v2 5/7] drm/msm: Convert to use new iterator macros, v2.

for_each_obj_in_state is about to be removed, so convert to the new iterator macros. Just like in omap, use crtc_state->active instead of crtc_state->enable when waiting for completion. Changes since v1: - Fix compilation. Signed-off-by: Maarten Lankhorst Cc:

[PATCH v2 6/7] drm/nouveau: Convert nouveau to use new iterator macros, v2.

Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Changes since v1: - Don't mix up old and new state. (danvet) - Rebase on top of interruptible swap_state

[PATCH v2 0/7] drm/atomic: Remove deprecated atomic iterator macros, v2.

It's time to kill off for_each_obj_in_state, and convert the remainder to for_each_(old/new/both)_obj_in_state. Some patches have been upstreamed, these are the remaining few with compile fixes. Maarten Lankhorst (7): drm/atomic: Use new iterator macros in

[PATCH v2 3/7] drm/rcar-du: Use new iterator macros, v2.

for_each_obj_in_state is about to be removed, so use the correct new iterator macros. Also look at new_plane_state instead of plane->state when looking up the hw planes in use. They should be the same except when reallocating, (in which case this code is skipped) and we should really stop looking

[PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

Instead of assigning plane to __plane, iterate over plane which is the same thing. Simplify the check for n_planes != 1, at that point we know plane != NULL as well. Rename obj_state to new_obj_state, and get rid of the bogus stuff. crtc->state->state is NEVER non-null, if it is, there is a bug.

[PATCH v2 4/7] drm/omapdrm: Fix omap_atomic_wait_for_completion

Use the new iterator macro and look for crtc_state->active instead of enable, only crtc_state->enable implies that vblanks will happen. Signed-off-by: Maarten Lankhorst Cc: Tomi Valkeinen Reviewed-by: Daniel Vetter

[PATCH v2 1/7] drm/atomic: Use new iterator macros in drm_atomic_helper_wait_for_flip_done, again.

for_each_obj_in_state is about to be removed, so use the correct new iterator macro. I renamed the variable to 'unused', but forgot to convert drm_atomic_helper_wait_for_flip_done to the new iterator macro, so make it work this time. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Remove intel_flip_work infrastructure

Quoting Daniel Vetter (2017-07-19 14:24:20) > On Wed, Jul 19, 2017 at 02:07:36PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-07-19 13:55:01) > > > This gets rid of all the interactions between the legacy flip code and > > > the modeset code. Yay! > > > > Including our missed vblank

[Bug 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

https://bugs.freedesktop.org/show_bug.cgi?id=101832 --- Comment #4 from Laurent carlier --- got this: [lordh@lordh-pc lib]$ ldd -r libswrAVX2.so.0.0.0 linux-vdso.so.1 (0x7ffefe1b9000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f8206c77000)

Re: [PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock

On Wed, Jul 19, 2017 at 4:05 PM, Daniel Vetter wrote: > On Wed, Jul 19, 2017 at 3:42 PM, Chris Wilson > wrote: >> Quoting Daniel Vetter (2017-07-19 13:54:58) >>> diff --git a/drivers/gpu/drm/i915/intel_display.c >>>

Re: [Intel-gfx] [PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic

Quoting Daniel Vetter (2017-07-19 14:15:44) > On Wed, Jul 19, 2017 at 02:06:43PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-07-19 13:55:00) > > > A bit an oversight - the current code did nothing, since only > > > legacy flips used the unpin_work_count and assorted logic. > > > >

[Bug 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

https://bugs.freedesktop.org/show_bug.cgi?id=101832 --- Comment #3 from Emil Velikov --- Seems like some binary is having unresolved symbols - unw_get_proc_name at least. AFAICT it cannot happen for the DRI module, and since you're not using SWR none of it backends

Re: [PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock

On Wed, Jul 19, 2017 at 3:42 PM, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-19 13:54:58) >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index 5aa7ca1ab592..4762f158032d 100644 >> ---

Re: [PATCH 9/9] drm/i915: Drop unpin stall in atomic_prepare_commit

Op 19-07-17 om 14:55 schreef Daniel Vetter: > The core already does this in setup_commit(). With this we can also > remove the unpin_work_count since it's the last user. > > Cc: Maarten Lankhorst > Cc: Ville Syrjälä >

[PATCH v3 3/3] drm/mst: Avoid processing partially received up/down message transactions

Currently we may process up/down message transactions containing uninitialized data. This can happen if there was an error during the reception of any message in the transaction, but we happened to receive the last message correctly with the end-of-message flag set. To avoid this abort the

Re: [PATCH 3/9] drm/i915: Avoid the gpu reset vs. modeset deadlock

On Wed, Jul 19, 2017 at 3:32 PM, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-19 13:54:56) >> ... using the biggest hammer we have. This is essentially a weaponized >> version of the timeout-based wedging Chris added in >> >> commit

Re: [PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock

Quoting Daniel Vetter (2017-07-19 13:54:58) > There's no reason to entirely wedge the gpu, for the minimal deadlock > bugfix we only need to unbreak/decouple the atomic commit from the gpu > reset. The simplest wait to fix that is by replacing the > unconditional fence wait a the top of

Re: [PATCH 3/9] drm/i915: Avoid the gpu reset vs. modeset deadlock

Quoting Daniel Vetter (2017-07-19 13:54:56) > ... using the biggest hammer we have. This is essentially a weaponized > version of the timeout-based wedging Chris added in > > commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 > Author: Chris Wilson > Date: Thu Jun 22

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Remove intel_flip_work infrastructure

On Wed, Jul 19, 2017 at 02:07:36PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-19 13:55:01) > > This gets rid of all the interactions between the legacy flip code and > > the modeset code. Yay! > > Including our missed vblank boosting. (That's been dead for a while.) Hm right,

[Bug 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

https://bugs.freedesktop.org/show_bug.cgi?id=101832 --- Comment #2 from Laurent carlier --- building without swr fixes the problem -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Drop unpin stall in atomic_prepare_commit

On Wed, Jul 19, 2017 at 02:09:02PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-19 13:55:02) > > The core already does this in setup_commit(). With this we can also > > remove the unpin_work_count since it's the last user. > > Also note that the loop only existed for the legacy

Re: [Intel-gfx] [PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic

On Wed, Jul 19, 2017 at 02:06:43PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-19 13:55:00) > > A bit an oversight - the current code did nothing, since only > > legacy flips used the unpin_work_count and assorted logic. > > > > Cc: Maarten Lankhorst

Re: [PATCH 4/9] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

On Wed, Jul 19, 2017 at 02:04:25PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-19 13:54:57) > > Blocking in a worker is ok, > > but needlessly inefficient, > > > that's what the unbound_wq is for. And it > > unifies the paths between the blocking and nonblocking commit, giving >

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Drop unpin stall in atomic_prepare_commit

Quoting Daniel Vetter (2017-07-19 13:55:02) > The core already does this in setup_commit(). With this we can also > remove the unpin_work_count since it's the last user. Also note that the loop only existed for the legacy pageflip support, with that removed it becomes entirely redundant. -Chris

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Remove intel_flip_work infrastructure

Quoting Daniel Vetter (2017-07-19 13:55:01) > This gets rid of all the interactions between the legacy flip code and > the modeset code. Yay! Including our missed vblank boosting. (That's been dead for a while.) -Chris ___ dri-devel mailing list

Re: [Intel-gfx] [PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic

Quoting Daniel Vetter (2017-07-19 13:55:00) > A bit an oversight - the current code did nothing, since only > legacy flips used the unpin_work_count and assorted logic. > > Cc: Maarten Lankhorst > Cc: Ville Syrjälä >

Re: [PATCH 4/9] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

Quoting Daniel Vetter (2017-07-19 13:54:57) > Blocking in a worker is ok, but needlessly inefficient, > that's what the unbound_wq is for. And it > unifies the paths between the blocking and nonblocking commit, giving > me just one path where I have to implement the deadlock avoidance >

[PATCH 9/9] drm/i915: Drop unpin stall in atomic_prepare_commit

The core already does this in setup_commit(). With this we can also remove the unpin_work_count since it's the last user. Cc: Maarten Lankhorst Cc: Ville Syrjälä Signed-off-by: Daniel Vetter ---

[PATCH 4/9] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

Blocking in a worker is ok, that's what the unbound_wq is for. And it unifies the paths between the blocking and nonblocking commit, giving me just one path where I have to implement the deadlock avoidance trickery in the next patch. Cc: Chris Wilson Cc: Mika Kuoppala

[PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic

A bit an oversight - the current code did nothing, since only legacy flips used the unpin_work_count and assorted logic. Cc: Maarten Lankhorst Cc: Ville Syrjälä Signed-off-by: Daniel Vetter ---

[PATCH 8/9] drm/i915: Remove intel_flip_work infrastructure

This gets rid of all the interactions between the legacy flip code and the modeset code. Yay! Cc: Maarten Lankhorst Cc: Ville Syrjälä Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c

[PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock

There's no reason to entirely wedge the gpu, for the minimal deadlock bugfix we only need to unbreak/decouple the atomic commit from the gpu reset. The simplest wait to fix that is by replacing the unconditional fence wait a the top of commit_tail by a wait which completes either when the fences

[PATCH 6/9] drm/i915: Rip out legacy page_flip completion/irq handling

All these races and things are now solved through the vblank evasion trick, plus event handling is done using normal vblank even processing and drm_crtc_arm_vblank_event. We can get rid of all this complexity. Cc: Maarten Lankhorst Cc: Ville Syrjälä

[PATCH 3/9] drm/i915: Avoid the gpu reset vs. modeset deadlock

... using the biggest hammer we have. This is essentially a weaponized version of the timeout-based wedging Chris added in commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 Author: Chris Wilson Date: Thu Jun 22 11:56:25 2017 +0100 drm/i915: Break modeset deadlocks

[PATCH 0/9] gpu reset vs modeset fix, plus page_flip removal

Hi all, This fixes the dreaded gpu reset vs. modeset deadlocks. And since the defunct legacy page_flip code is the reason for a bunch of special cases I did remove that too, on Maarten's request. Please review, this is currently blocking extended CI runs on our haswell farm rather badly. The

[PATCH 1/9] drm/i915: Nuke legacy flip queueing code

Just a very minimal patch to nuke that code. Lots of the flip interrupt handling stuff is still around. Cc: Maarten Lankhorst Cc: Ville Syrjälä Signed-off-by: Daniel Vetter ---

[PATCH 2/9] drm/i915: Unbreak gpu reset vs. modeset locking

Taking the modeset locks unconditionally isn't the greatest idea, because atm that part is still broken and times out (and then atomic keels over). And there's really no reason to do so, the old code didn't do that either. To make the patch a bit simpler let's also nuke 2 cases that are only

Re: [PATCH] drm/syncobj: Fix kerneldoc

On Tue, Jul 18, 2017 at 09:41:13AM +0200, Daniel Vetter wrote: > make htmldocs helps with catching these. > > Cc: Dave Airlie > Signed-off-by: Daniel Vetter Applied with Dave's ack from irc. -Daniel > --- > Documentation/gpu/drm-mm.rst | 2 +- >

Re: [PATCH] drm/msm/mdp5: Fix compilation warnings

Quoting Viresh Kumar (2017-06-29 10:19:59) > Following compilation warnings were observed for these files: > > CC [M] drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup': > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning:

[PATCH v2 2/3] drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()

In case of an unknown broadcast message is sent mstb will remain unset, so check for this. Cc: Dave Airlie Cc: Lyude Cc: Daniel Vetter Signed-off-by: Imre Deak Reviewed-by: Lyude ---

[PATCH v2 3/3] drm/mst: Avoid processing partially received up/down message transactions

Currently we may process up/down message transactions containing uninitialized data. This can happen if there was an error during the reception of any message in the transaction, but we happened to receive the last message correctly with the end-of-message flag set. To avoid this abort the

[PATCH v2 0/3] drm/mst: Fix sideband msg reception error path

This is a resend of the last two patches from [1], addressing Lyude's comments and adding his R-bs. The first patch in [1] isn't needed any more. Patch 3 is a fix for a related issue I noticed since the original patchset. https://lists.freedesktop.org/archives/dri-devel/2016-May/107420.html Cc:

[PATCH v2 1/3] drm/mst: Fix error handling during MST sideband message reception

Handle any error due to partial reads, timeouts etc. to avoid parsing uninitialized data subsequently. Also bail out if the parsing itself fails. Cc: Dave Airlie Cc: Lyude Cc: Daniel Vetter Signed-off-by: Imre Deak

Re: [PATCH v12 6/6] drm/i915: Introduce GEM proxy

s/GEM proxy/a GEM proxy object/ Quoting Tina Zhang (2017-07-19 11:59:05) Rationale goes here. > Signed-off-by: Tina Zhang > --- > drivers/gpu/drm/i915/i915_gem.c| 26 +- > drivers/gpu/drm/i915/i915_gem_object.h | 9 + >

[PATCH v12 6/6] drm/i915: Introduce GEM proxy

Signed-off-by: Tina Zhang --- drivers/gpu/drm/i915/i915_gem.c| 26 +- drivers/gpu/drm/i915/i915_gem_object.h | 9 + drivers/gpu/drm/i915/i915_gem_tiling.c | 5 + 3 files changed, 39 insertions(+), 1 deletion(-) diff --git

[PATCH v12 4/6] drm/i915/gvt: add opregion support

Windows guest UPT driver can use operegion to configure the setting for display. Without the opregion support, the display registers won't be set and this blocks display model to get the correct information of the guest display plane. Signed-off-by: Bing Niu Signed-off-by:

[PATCH v12 5/6] vfio: ABI for mdev display dma-buf operation

Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and get the plan and its related information. The dma-buf's life cycle is handled by user mode and tracked by kernel. The returned fd in struct vfio_device_query_gfx_plane can be a new fd or an old fd of a re-exported dma-buf.

[PATCH v12 0/6] drm/i915/gvt: Dma-buf support for GVT-g

v11->v12: 1) add drm_format_mod back. (Gerd and Zhenyu) 2) add region_index. (Gerd) 3) refine the lifecycle of dmabuf. 4) send to dri-devel@lists.freedesktop.org. (Ville) v10->v11: 1) rename plane_type to drm_plane_type. (Gerd) 2) move fields of vfio_device_query_gfx_plane to

[PATCH v12 2/6] drm: Introduce RGB 64-bit 16:16:16:16 float format

The RGB 64-bit 16:16:16:16 float pixel format is needed by windows guest VM. This patch is to introduce the format to drm. v1: Suggested by Ville to submit this patch to dri-devel. Signed-off-by: Xiaoguang Chen Signed-off-by: Tina Zhang ---

[PATCH v12 1/6] drm/i915/gvt: Add framebuffer decoder support

Framebuffer decoder returns guest framebuffer information. Guest framebuffer includes primary, cursor and sprite plane. Signed-off-by: Xiaoguang Chen Signed-off-by: Tina Zhang --- drivers/gpu/drm/i915/gvt/Makefile | 3 +-

[PATCH v12 3/6] drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support

The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10 guest VM. This patch is to add this pixel format support to gvt device model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash and make guest screen black. Signed-off-by: Xiaoguang Chen

[Bug 101837] libdrm fails to get bus id

https://bugs.freedesktop.org/show_bug.cgi?id=101837 --- Comment #1 from Michel Dänzer --- Please attach the corresponding dmesg output and Xorg log file. -- You are receiving this mail because: You are the assignee for the bug.___

[PATCH v12 3/6] drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support

The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10 guest VM. This patch is to add this pixel format support to gvt device model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash and make guest screen black. Signed-off-by: Xiaoguang Chen

[PATCH v12 0/6] drm/i915/gvt: Dma-buf support for GVT-g

v11->v12: 1) add drm_format_mod back. (Gerd and Zhenyu) 2) add region_index. (Gerd) 3) refine the lifecycle of dmabuf. 4) send to dri-devel@lists.freedesktop.org. (Ville) v10->v11: 1) rename plane_type to drm_plane_type. (Gerd) 2) move fields of vfio_device_query_gfx_plane to

[PATCH v12 2/6] drm: Introduce RGB 64-bit 16:16:16:16 float format

The RGB 64-bit 16:16:16:16 float pixel format is needed by windows guest VM. This patch is to introduce the format to drm. v1: Suggested by Ville to submit this patch to dri-devel. Signed-off-by: Xiaoguang Chen Signed-off-by: Tina Zhang ---

[PATCH v12 1/6] drm/i915/gvt: Add framebuffer decoder support

Framebuffer decoder returns guest framebuffer information. Guest framebuffer includes primary, cursor and sprite plane. Signed-off-by: Xiaoguang Chen Signed-off-by: Tina Zhang --- drivers/gpu/drm/i915/gvt/Makefile | 3 +-

  1   2   >