[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #8 from Shmerl --- (In reply to Philipp Überbacher from comment #5) > I've used this to get a apitrace quickly and I have one with just 1.1 GB. > However, replaying it does not produce the freeze. Maybe the

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #7 from Shmerl --- I have the freeze with hairworks disabled all the same. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel

[radeon-alex:amd-staging-drm-next 625/639] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1513:28: error: 'DRM_ROTATE_0' undeclared

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 57f5c7f15032e48265fb4302cf8eb62ec7ce3246 commit: 24ede71be1fefa780f3e8c3ad7e9b65a5d4fd4c2 [625/639] drm/amd/display: Create dm_plane_state. config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc

[PATCH v2 4/5] 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 v2 5/5] dt-bindings: display: fill Documents for series of vop

Changes in v2: - rename rk322x to rk3228(Heiko Stübner) Signed-off-by: Mark Yao --- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v2 2/5] drm/rockchip: vop: support verify registers with vop version

Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 66 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 18 ++-- drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 20 ++--- 3 files changed, 77 insertions(+), 27

[PATCH v2 3/5] drm/rockchip: vop: move line_flag_num to interrupt registers

Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 ++-- drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 3 files changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH v2 1/5] drm/rockchip: vop: get rid of register init table

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. Signed-off-by: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6

[PATCH v2 0/5] drm/rockchip: add all full framework vop support

These patches try to make all current rockchip full framework vop works on drm, The newer vop design always have some different to the old one, So we add a register verify mechanism to distinguish those register, then the registers table can be reused. And people can easy to know the different

[Bug 101294] radeonsi minecraft forge splash freeze since 17.1

https://bugs.freedesktop.org/show_bug.cgi?id=101294 --- Comment #15 from Michel Dänzer --- (In reply to MirceaKitsune from comment #14) > I assume I'm experiencing the same bug described here [...] You're most definitely not. Many different causes can result in similar

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

On 2017年07月11日 20:45, Heiko Stübner wrote: Hi Mark, Am Dienstag, 11. Juli 2017, 20:42:38 CEST schrieb Mark Yao: Signed-off-by: Mark Yao --- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH v2 1/7] dt-bindings: display: renesas: Add R-Car M3-W HDMI TX DT bindings

On Mon, Jul 10, 2017 at 11:25:31AM +0200, Simon Horman wrote: > On Mon, Jun 26, 2017 at 10:56:42AM -0500, Rob Herring wrote: > > On Wed, Jun 21, 2017 at 12:31:27PM +0300, Laurent Pinchart wrote: > > > The M3-W HDMI TX controller seems to be compatible for the H3. No > > > extension to the DT

[regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Greetings, I met $subject in master-rt post drm merge, but taking the config (attached) to virgin v4.12-10624-g9967468c0a10, it's reproducible. KERNEL: vmlinux-4.12.0.g9967468-preempt.gz DUMPFILE: vmcore CPUS: 8 DATE: Tue Jul 11 18:55:28 2017 UPTIME: 00:02:03 LOAD

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > OK, thanks. So in other words, a fairly standard desktop with a PCIe > board plugged in. No funny business. (Laptops can create a ton of > additional weirdness, which I assumed you had since you were talking > about STR.) Yup, garden

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: > Some details that may be useful in analysis of the bug: > > 1. lspci -nn -d 10de: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

On (07/11/17 11:31), Sergey Senozhatsky wrote: [..] > (replying to both Petr and Daniel) > > interesting direction, gents. > > and this is what I thought about over the weekend; it's very sketchy and > I didn't spend too much time on it. (I'm on a sick leave now, sorry). > > it's quite close to

Re: [PATCH v4 14/14] drm: remove unused and redundant callbacks

On 2017-07-11 10:13, Daniel Vetter wrote: > On Thu, Jul 06, 2017 at 02:20:48PM +0200, Peter Rosin wrote: >> Drivers no longer have any need for these callbacks, and there are no >> users. Zap. Zap-zap-zzzap-p-pp-p. >> >> Signed-off-by: Peter Rosin > > On patches 4-14: Acked-by:

Re: [PATCH v4 01/14] drm/atomic: export drm_atomic_replace_property_blob

On 2017-07-11 10:01, Daniel Vetter wrote: > On Thu, Jul 06, 2017 at 02:20:35PM +0200, Peter Rosin wrote: >> While at it, add some words in the kernel-doc about the 'replaced' arg and >> remove a faulty kernel-doc comment on the return value. >> >> Also remove a redundant return statement. >> >>

Re: [PATCH v4 03/14] drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths

On 2017-07-11 10:10, Daniel Vetter wrote: > On Thu, Jul 06, 2017 at 02:20:37PM +0200, Peter Rosin wrote: >> The legacy path implements setcmap in terms of crtc .gamma_set. >> >> The atomic path implements setcmap by directly updating the crtc gamma_lut >> property. >> >> This has a couple of

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

On (07/11/17 09:50), Daniel Vetter wrote: [..] > > ok, obviously stupid. > > > > I meant to hold con->lock between console_disable() and console_enable(). > > so no other CPU can unregister it, etc. printk->console_unlock(), thus, > > can either have a racy con->flags check (no con->lock taken)

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

Hello, On (07/10/17 20:07), Daniel Vetter wrote: [..] > > Would it be acceptable to remove "console=tty0" parameter and push > > the messages only to the serial console? > > > > Also there is the patchset from Peter Zijlstra that allows to > > use early console all the time, see > >

Re: [PATCH v4 02/14] drm/atomic-helper: update lut props directly in ..._legacy_gamma_set

On 2017-07-11 10:02, Daniel Vetter wrote: > On Thu, Jul 06, 2017 at 02:20:36PM +0200, Peter Rosin wrote: >> Do not waste cycles looking up the property id when we have the >> actual property already. >> >> Signed-off-by: Peter Rosin > > With the names adjusted per my comments on

Re: [PATCH] fbdev: make get_fb_unmapped_area depends of !MMU

Hi Benjamin, [auto build test ERROR on linus/master] [also build test ERROR on v4.12 next-20170711] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/fbdev-make

[Bug 100400] [Solved] Game Valhalla Hills crash on startup

https://bugs.freedesktop.org/show_bug.cgi?id=100400 --- Comment #13 from CraZy bisCuiT --- Thanks for fixing! With the current mesa-git and llvm-svn it seems to work flawlessly! -- You are receiving this mail because: You are the assignee for the

[Bug 99349] Failed to build shader (translation from TGSI)

https://bugs.freedesktop.org/show_bug.cgi?id=99349 --- Comment #16 from higu...@gmx.net --- So if the patch works, will it be merged? or is already merged, and if yes, in what version? -- You are receiving this mail because: You are the assignee for the

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

https://bugs.freedesktop.org/show_bug.cgi?id=100742 --- Comment #3 from Alex Deucher --- I think we probably need to add a new op to the context ioctl to allow the application to request a floor for a specific clock (sclk, mclk, dclk, eclk, etc.) so that the application

[PATCH v2 3/3] drm: rcar-du: Repair vblank for DRM page flips using the VSP

From: Kieran Bingham The driver recently switched from handling page flip completion in the DU vertical blanking handler to the VSP frame end handler to fix a race condition. This unfortunately resulted in incorrect timestamps in the vertical blanking

[PATCH v2 2/3] drm: rcar-du: Fix planes to CRTC assignment when using the VSP

The DU can compose the output of a VSP with other planes on Gen2 hardware, and of two VSPs on Gen3 hardware. Neither of these features are supported by the driver, and the current implementation always assigns planes to CRTCs the same way. Simplify the implementation by configuring plane

[PATCH v2 0/2] drm: rcar-du: Repair vblank event handling

Hello, The recent changes to the rcar-du driver to fix a page flip handling race condition changed the order of which vblanks and page flips are handled, resulting in incorrect timestamps being reported in the vblan events. Correct this by handling vblank events in the same completion handler as

[PATCH v2 1/3] drm: rcar-du: Use the VBK interrupt for vblank events

When implementing support for interlaced modes, the driver switched from reporting vblank events on the vertical blanking (VBK) interrupt to the frame end interrupt (FRM). This incorrectly divided the reported refresh rate by two. Fix it by moving back to the VBK interrupt. Fixes: 906eff7fcada

[Bug 101294] radeonsi minecraft forge splash freeze since 17.1

https://bugs.freedesktop.org/show_bug.cgi?id=101294 --- Comment #14 from MirceaKitsune --- Greetings. I'm also getting a GPU crash / system lockup, when running Minecraft as well as other game engines. It doesn't happen during the splash screen, but

[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

https://bugs.freedesktop.org/show_bug.cgi?id=101672 --- Comment #8 from MirceaKitsune --- Created attachment 132621 --> https://bugs.freedesktop.org/attachment.cgi?id=132621=edit mesa_err_2.log The freeze persists in Mesa 17.1.4. This comes as a surprise

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

https://bugs.freedesktop.org/show_bug.cgi?id=100742 --- Comment #2 from higu...@gmx.net --- maybe my bug is a dupe from this https://bugs.freedesktop.org/show_bug.cgi?id=101749 i notice that we all have a RX480... does other AMDGPU cards also have this or is the problem only related with this

Re: [PATCH 00/11] drm/sun4i: add CEC support

On 11/07/17 22:39, Maxime Ripard wrote: > On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote: >> From: Hans Verkuil >> >> This patch series adds CEC support for the sun4i HDMI controller. >> >> The CEC hardware support for the A10 is very low-level as it just >>

[PATCH] drm: rcar-du: Use the VBK interrupt for vblank events

When implementing support for interlaced modes, the driver switched from reporting vblank events on the vertical blanking (VBK) interrupt to the frame end interrupt (FRM). This incorrectly divided the reported refresh rate by two. Fix it by moving back to the VBK interrupt. Fixes: 906eff7fcada

Re: [PATCH 00/11] drm/sun4i: add CEC support

On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series adds CEC support for the sun4i HDMI controller. > > The CEC hardware support for the A10 is very low-level as it just > controls the CEC pin. Since I also wanted to

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

On Tue, Jul 11, 2017 at 9:53 PM, Rob Clark wrote: > On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter wrote: >> On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote: >>> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:

Re: VT console blank ignored by DRM drivers on QEMU

On Tue, Jul 11, 2017 at 8:10 PM, Takashi Iwai wrote: > On Tue, 11 Jul 2017 19:35:36 +0200, > Daniel Vetter wrote: >> >> On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote: >> > On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote: >> >>> DPMS

Re: [PATCH 00/11] drm/sun4i: add CEC support

On 11/07/17 08:30, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series adds CEC support for the sun4i HDMI controller. > > The CEC hardware support for the A10 is very low-level as it just > controls the CEC pin. Since I also wanted to support GPIO-based CEC >

[PATCH] drm/amdgpu: Off by one sanity checks

This is just future proofing code, not something that can be triggered in real life. We're testing to make sure we don't shift wrap when we do "1ull << i" so "i" has to be in the 0-63 range. If it's 64 then we have gone too far. Signed-off-by: Dan Carpenter diff

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote: >> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote: >>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:

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

On Tue, Jul 11, 2017 at 12:22 AM, Daniel Vetter wrote: > On Mon, Jul 10, 2017 at 02:09:42PM -0700, Jason Ekstrand wrote: > > On Mon, Jul 10, 2017 at 9:15 AM, Christian König < > deathsim...@vodafone.de> > > wrote: > > > > > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: > > > >

Re: [PATCH] dt-bindings: display: sunxi: Improve endpoint ID scheme readability

On Mon, Jul 10, 2017 at 11:48:00PM +0800, Chen-Yu Tsai wrote: > On Sun, Jun 18, 2017 at 10:05 PM, Rob Herring wrote: > > On Wed, Jun 14, 2017 at 02:30:16PM +0800, Chen-Yu Tsai wrote: > >> The explanation for the endpoint ID numbering scheme is convoluted > >> and hard to

Re: [PATCH v3] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

On Mon, Jul 10, 2017 at 04:55:04PM +1000, Jonathan Liu wrote: > The drm_driver lastclose callback is called when the last userspace > DRM client has closed. Call drm_fbdev_cma_restore_mode to restore > the fbdev console otherwise the fbdev console will stop working. > > Fixes: 9026e0d122ac ("drm:

Re: [RFC 0/3] drm/msm+clk: handover of bootloader display

On Tue, Jul 11, 2017 at 2:35 PM, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Jul 11, 2017 at 8:20 PM, Rob Clark wrote: >> So now that this is working (at least on a single device), I figured >> it was a good time to send out an RFC to start

Re: [RFC 0/3] drm/msm+clk: handover of bootloader display

Hi Rob, On Tue, Jul 11, 2017 at 8:20 PM, Rob Clark wrote: > So now that this is working (at least on a single device), I figured > it was a good time to send out an RFC to start discussion about how > to do this properly, in particular the CCF/powerdomain parts. > > The

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce >

[RFC 2/3] drm/msm: inherit display from bootloader

It is quite common for bootloader to enable display on tablets/phones. But until now for upstream kernel we've been ignoring that since it highly confuses drm/msm, and recommending to disable the bootloader display. (Otherwise we end up trying to set rates on already enabled clks and all sorts of

[RFC 1/3] clk: inherit display clocks enabled by bootloader

The goal here is to support inheriting a display setup by bootloader, although there may also be some non-display related use-cases. Rough idea is to add a flag for clks and power domains that might already be enabled when kernel starts, and make corresponding fixups to clk enable/prepare_count

[RFC 3/3] drm/bridge: adv7511: deal with bootloader lighting up display

We need to do some things a bit differently if the bridge chip is already powered up when the driver loads (ie. bootloader has already enabled display). In particular we don't want to do anything that would kill the display. --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 57

[RFC 0/3] drm/msm+clk: handover of bootloader display

So now that this is working (at least on a single device), I figured it was a good time to send out an RFC to start discussion about how to do this properly, in particular the CCF/powerdomain parts. The first patch adds flags so we can mark power domains and leaf node clocks which might (or might

Re: VT console blank ignored by DRM drivers on QEMU

On Tue, 11 Jul 2017 19:35:36 +0200, Daniel Vetter wrote: > > On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote: > > On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote: > >>> DPMS should be an error anyway, we want that to be able to properly > >>> thread the

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Some details that may be useful in analysis of the bug: 1. lspci -nn -d 10de: 2. What displays, if any, you have plugged into the NVIDIA board when this happens? 3. Any boot parameters, esp relating to ACPI, PM, or related? Cheers, -ilia On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith

Re: [PATCH v8 4/6] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v4

On Tue, Jul 11, 2017 at 3:07 PM, kbuild test robot wrote: > make ARCH=i386 Yeah, either this code shouldn't have been built on 32-bit arch at all, or be portable. >arch/x86/pci/fixup.c: In function 'pci_amd_enable_64bit_bar': >>> arch/x86/pci/fixup.c:674:15:

Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

On Tue, Jul 11, 2017 at 11:20 AM, Dave Airlie wrote: > On 11 July 2017 at 18:36, Christian König wrote: >> Am 11.07.2017 um 08:49 schrieb Dave Airlie: >>> >>> On 7 July 2017 at 19:07, Christian König wrote: Hi Dave,

Re: VT console blank ignored by DRM drivers on QEMU

On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote: > On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote: >>> DPMS should be an error anyway, we want that to be able to properly >>> thread the acquire_ctx EDEADLK backoff stuff through that we need for >>>

Re: [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp

Quoting Chris Wilson (2017-02-14 12:40:01) > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized > memory (8802538683d0) > [ 236.828642] > 42001e7f0008 > [ 236.839543] i i i i u u u u i i i i i i i i u u u u u u u u

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote: > On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: >> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: > > be even better if you could calculate whether the mode is

[Bug 92715] [IGT] [BYT-M/KBL/BXT/BDW/IVB/BSW] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 --- Comment #31 from Armando Antonio --- The following test fail on BSW with latest configuration Test list

[Bug 92715] [IGT] [BYT-M/KBL/BXT/BDW/IVB/BSW] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 Armando Antonio changed: What|Removed |Added Summary|[IGT]

[Bug 92715] [IGT] [BYT-M/KBL/BXT/BDW/IVB] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 --- Comment #29 from Armando Antonio --- Sorry this is the test list igt@gem_reset_stats@ban-default -- You are receiving this mail because: You are the assignee for the

[Bug 101749] sclk scales badly in war thunder

https://bugs.freedesktop.org/show_bug.cgi?id=101749 --- Comment #1 from Christoph Haag --- Possibly the same as bug 100742 which is very visible with SteamVR. -- You are receiving this mail because: You are the assignee for the

[Bug 92715] [IGT] [BYT-M/KBL/BXT/BDW/IVB] gem_reset_stats sub tests fail

https://bugs.freedesktop.org/show_bug.cgi?id=92715 Armando Antonio changed: What|Removed |Added Summary|[IGT]

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: > be even better if you could calculate whether the mode is valid, but I > didn't > spend enough time to figure out if this is

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

On Tue, Jul 11, 2017 at 12:17 AM, Christian König wrote: > Am 11.07.2017 um 04:36 schrieb Michel Dänzer: > >> On 11/07/17 06:09 AM, Jason Ekstrand wrote: >> >>> On Mon, Jul 10, 2017 at 9:15 AM, Christian König >>>

[Bug 101712] [Turks PRO/Radeon HD 6570/7570/8550] CPU lockup after ring 0 stalled

https://bugs.freedesktop.org/show_bug.cgi?id=101712 --- Comment #6 from guiscara...@gmail.com --- Created attachment 132618 --> https://bugs.freedesktop.org/attachment.cgi?id=132618=edit Dmesg after boot (In reply to Julien Isorce from comment #5) > Thx for the apitrace. I could not reproduce

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: >>> > be even better if you could calculate whether the mode is valid, but I >>> > didn't >>> > spend enough time to figure out if this is possible. >>> >>> Theoretically that might be possible, checking if the requested

[Bug 100189] segfault at 234 error 4 in i915_dri.so

https://bugs.freedesktop.org/show_bug.cgi?id=100189 --- Comment #15 from Indie --- I actually need this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 12:56 AM, Daniel Vetter wrote: > On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote: >> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote: >> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: >> >> Currently the

[Bug 101712] [Turks PRO/Radeon HD 6570/7570/8550] CPU lockup after ring 0 stalled

https://bugs.freedesktop.org/show_bug.cgi?id=101712 Vedran Miletić changed: What|Removed |Added Summary|CPU lockup after ring 0 |[Turks PRO/Radeon

[PATCH] fbdev: Nuke FBINFO_MODULE

Instead check info->ops->owner, which amounts to the same. Spotted because I want to remove the pile of broken and cargo-culted fb_info->flags assignments in drm drivers. v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines that I've failed to spot. v3: Don't nuke

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote: > On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote: >> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote: >>> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >>> +{

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

On Tue, Jul 11, 2017 at 10:17 AM, Chris Wilson wrote: > Quoting Rob Clark (2017-07-11 14:38:22) >> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >> +{ >> + struct msm_drm_private *priv = dev->dev_private; >> + unsigned long size; >> +

[PATCH v2 06/12] drm/mediatek: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst Cc: CK Hu Cc: Philipp Zabel

[PATCH v2 10/12] drm/vc4: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. VC4 has its own nonblocking modeset tracking through the vc4->async_modeset semaphore, so it doesn't need to stall in swap_state. Pass stall =

[PATCH v2 09/12] drm/tilcdc: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst Cc: Jyri Sarha Cc: Tomi Valkeinen

[PATCH v2 11/12] drm/atomic: Add __must_check to drm_atomic_helper_swap_state.

Now that all drivers check the return value, convert swap_state to __must_check. This is done separately to force build warnings if we missed a driver. Signed-off-by: Maarten Lankhorst --- include/drm/drm_atomic_helper.h | 3 ++- 1 file changed, 2

[PATCH v2 05/12] drm/i915: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 10 +- 1 file changed, 9

[PATCH v2 12/12] drm/atomic: Allow drm_atomic_helper_swap_state to fail

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index

[PATCH v2 08/12] drm/tegra: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst Cc: Thierry Reding Cc: Jonathan Hunter

[PATCH v2 07/12] drm/msm: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. MSM has its own busy tracking, which means the swap_state call can be done with stall = false, in which case it should never return an error.

[PATCH v2 00/12] drm/atomic: Make drm_atomic_helper_swap_state waiting interruptible.

drm_atomic_helper_swap_state could previously never fail, in order to still continue it would set a limit of 10s on waiting for previous updates to complete, then it moved forward. This can be very bad when ignoring previous updates, because the hw state and sw state may get out of sync when for

[PATCH v2 04/12] drm/atmel-hlcdc: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Atmel tracks pending commits through dc->commit.pending, so it can ignore the changes by setting stall = false. We never return failure in this

[PATCH v2 01/12] drm/nouveau: Fix error handling in nv50_disp_atomic_commit

Make it more clear that post commit return ret is really return 0, and add a missing drm_atomic_helper_cleanup_planes when drm_atomic_helper_wait_for_fences fails. Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces internally") Cc: Ben Skeggs Cc:

[PATCH v2 03/12] drm/nouveau: Handle drm_atomic_helper_swap_state failure

drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org ---

[PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

We want to change swap_state to wait indefinitely, but to do this swap_state should wait interruptibly. This requires propagating the error to each driver. Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote: >> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >> +{ >> + struct msm_drm_private *priv = dev->dev_private; >> +

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

Quoting Rob Clark (2017-07-11 14:38:22) > +static unsigned long hijack_firmware_fb(struct drm_device *dev) > +{ > + struct msm_drm_private *priv = dev->dev_private; > + unsigned long size; > + int i; > + > + /* if we have simplefb/efifb, find it's aperture and hijack > +

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote: > +static unsigned long hijack_firmware_fb(struct drm_device *dev) > +{ > + struct msm_drm_private *priv = dev->dev_private; > + unsigned long size; > + int i; > + > + /* if we have simplefb/efifb, find

[PATCH 2/3] fbdev: fbmem: export get/put_fb_info()

Needed for following patch. Signed-off-by: Rob Clark --- drivers/video/fbdev/core/fbmem.c | 6 -- include/linux/fb.h | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c

[PATCH 3/3] drm/msm: hijack firmware fb's memory

If we are kicking out efifb or simplefb then we want to hijack the outgoing fb's memory and wrap it in a gem object so that it can be allocated for use by fbdev helpers. This way we keep the same scanout buffer that the display is already using. This is prep-work for enabling drm/msm to take

[PATCH 1/3] drm/msm: kick out firmware framebuffer

Fixes a problem with console not appearing when booting with EFI that has GOP support, because fb0 would end up being efifb, even after drm has taken over the display. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_drv.c | 20

[PATCH 0/3] drm/msm: hijack firmware fb's memory

The first patch I've already sent to list and plan to include in a v4.13-fixes pull request, but I'm resending as part of this patchset since 3/3 depends on it. The 2nd patch exports get_fb_info()/put_fb_info() so that in the 3rd patch we can iterate over the registered fb's (before kicking out

[PATCH 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even

[PATCH 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil Implement support for this DisplayPort feature. The cec device is created whenever it detects an adapter that has this feature. It is only removed when a new adapter is connected that does not support this. If a new adapter is connected that has

[PATCH 2/3] drm-kms-helpers.rst: document the DP CEC helpers

From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst

[PATCH 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on the latest mainline kernel (as of today) which has all the needed cec and drm 4.13 patches merged. This patch series has been tested with

[PULL] drm-intel-next-fixes

Hi Dave, drm/i915 fixes for v4.13-rc1. Almost half of them for stable kernels, the rest for issues in this merge window. Two batches of GVT fixes, otherwise fixes all around. BR, Jani. The following changes since commit bdbbf7d619d1fd2f1fa9eb529b7817e4faf73f5e: drm/i915: Clear execbuf's vma

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

Hi Mark, Am Dienstag, 11. Juli 2017, 20:42:38 CEST schrieb Mark Yao: > Signed-off-by: Mark Yao > --- > Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git >

[PATCH 4/5] 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 rk322x 3.8 rk3328 The above IP version is from H/W define, some of vop support

  1   2   >