commit a481daa88fd (drm/radeon: always apply pci shutdown callbacks) breaks reboot

Since: commit a481daa88fd4d6b54f25348972bba10b5f6a84d0 Author: Alex Deucher Date: Thu Sep 22 14:43:50 2016 -0400 drm/radeon: always apply pci shutdown callbacks We can't properly detect all hypervisors and we need this to properly tear down the hardware. I cannot reboot my

[bug report] drm/vc4: Add support for drawing 3D frames.

^ > Presumably this could be removed? I think so. Want to send the patch? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/6d50a618/attachment.sig>

[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote: > That might take some time. Because bisecting always takes a long time > and especially since hitting this WARNING sometimes takes over an hour. > Anyhow, please prod me if I stay silent for too long. For the record: I just had to power cycle

commit a481daa88fd (drm/radeon: always apply pci shutdown callbacks) breaks reboot

> -Original Message- > From: Markus Trippelsdorf [mailto:markus at trippelsdorf.de] > Sent: Wednesday, October 12, 2016 4:40 PM > To: Deucher, Alexander > Cc: Koenig, Christian; dri-devel at lists.freedesktop.org > Subject: commit a481daa88fd (drm/radeon: always apply pci shutdown >

[bug report] drm/vc4: Add support for drawing 3D frames.

Hello Eric Anholt, The patch d5b1a78a772f: "drm/vc4: Add support for drawing 3D frames." from Nov 30, 2015, leads to the following static checker warning: drivers/gpu/drm/vc4/vc4_gem.c:797 vc4_wait_for_seqno_ioctl_helper() warn: ret is never (-4) drivers/gpu/drm/vc4/vc4_gem.c

[RFC] drm/fb-helper: reject any changes to the fbdev

On Wed, Oct 12, 2016 at 08:55:45AM -0700, Stefan Agner wrote: > On 2016-10-12 03:42, Ville Syrjälä wrote: > > On Tue, Oct 11, 2016 at 04:15:04PM -0700, Stefan Agner wrote: > >> The current fbdev emulation does not allow to push back changes in > >> width, height or depth to KMS, hence reject any

[PATCH libdrm] Add support for DRM_MODE_PAGE_FLIP_TARGET_* flags

From: Michel Dänzer Signed-off-by: Michel Dänzer --- The corresponding kernel changes have landed in Linus' tree. include/drm/drm.h | 1 + include/drm/drm_mode.h | 39 --- xf86drmMode.c | 16

Question: Re: [PATCH] drm/bridge: analogix: protect power when get_modes or detect

An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/e2118efc/attachment.html>

[PATCH] drm/bridge: analogix: protect power when get_modes or detect

The drm callback ->detect and ->get_modes seems is not power safe, they may be called when device is power off, do register access on detect or get_modes will cause system die. Here is the path call ->detect before analogix_dp power on [] analogix_dp_detect+0x44/0xdc []

[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 12 Oct 2016, Paul Bolle wrote: > On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: >> Bisecting the offending commit between v4.8 and v4.8.1 would be a good >> start. > > That would be between v4.7 and v4.8. (I guess my report was ambiguous.) > > That might take some time. Because

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On Wed, 12 Oct 2016, Emil Velikov wrote: > On 11 October 2016 at 10:33, Jani Nikula > wrote: >> On Tue, 11 Oct 2016, "Sun, Jing A" wrote: >>> It's needed that DRM Driver module could be removed and reloaded after >>> kernel booting on the projects that I have been working on, and I hope >>>

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

On 10/12/2016 05:11 PM, Shuah Khan wrote: + Fixing Krzysztof Kozlowski address. > Hi Inki, > > On 08/15/2016 10:40 PM, Inki Dae wrote: > >>> >>> okay the very first commit that added IOMMU support >>> introduced the code that rejects non-contig gem memory >>> type without IOMMU. >>> >>> commit

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

Hi Inki, On 08/15/2016 10:40 PM, Inki Dae wrote: >> >> okay the very first commit that added IOMMU support >> introduced the code that rejects non-contig gem memory >> type without IOMMU. >> >> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c >> Author: Inki Dae >> Date: Sat Oct 20 07:53:42

[PATCH libdrm] Add support for DRM_MODE_PAGE_FLIP_TARGET_* flags

Hi Michel, On 12 October 2016 at 10:41, Michel Dänzer wrote: > From: Michel Dänzer > > Signed-off-by: Michel Dänzer > --- > > The corresponding kernel changes have landed in Linus' tree. > > include/drm/drm.h | 1 + > include/drm/drm_mode.h | 39

[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 2016-10-12 at 17:34 +0300, Jani Nikula wrote: > In the mean time, please file a bug over at [1] so we don't lose > track. Done:  https://bugs.freedesktop.org/show_bug.cgi?id=98214 Paul Bolle

[Bug 67713] Freezes on Trinity 7500G

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/29951c2a/attachment.html>

[Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

On ti, 2016-10-11 at 12:03 -0700, Robert Bragg wrote: > > > +               case DRM_I915_PERF_PROP_MAX: > > > +                       BUG(); > > > > We already handle this case above, but I guess we still need this in > > order to silence gcc... > > right, and preferable to

[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On ke, 2016-10-12 at 11:56 +0200, Paul Bolle wrote: > On a laptop that tracks the latest stable release (Ie, it now runs > v4.8.1) I see this WARNING >     WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) > > Full trace pasted below. I never saw this WARNING before v4.8. Since > v4.8 I've had

[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: > Bisecting the offending commit between v4.8 and v4.8.1 would be a good > start. That would be between v4.7 and v4.8. (I guess my report was ambiguous.) That might take some time. Because bisecting always takes a long time and especially

GPU-DRM-Savage: Less function calls in savage_bci_cmdbuf() after error detection

>> Date: Thu, 18 Aug 2016 21:28:58 +0200 >> >> The kfree() function was called in a few cases by the >> savage_bci_cmdbuf() function during error handling >> even if a passed variable contained a null pointer. >> >> Adjust jump targets according to the Linux coding style convention. >> >>

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On Wed, 12 Oct 2016, "Sun, Jing A" wrote: > I think "installing a kernel with my changes for both drm and i915" > takes more time and effort to complete than "only updating DRM/i915 > modules without rebuilding the whole kernel". In some cases, that's > beneficial. It's possible to change and

[PATCH] drm/amd/powerplay: don't give up if DPM is already running

Hi Grazvydas and Alex, We needed to disable dpm when rmmod amdgpu for this issue. I am checking the function of disable dpm task. Best Regards Rex -Original Message- From: Alex Deucher [mailto:alexdeuc...@gmail.com] Sent: Wednesday, October 12, 2016 4:01 AM To: Grazvydas Ignotas;

[RFC] drm/fb-helper: reject any changes to the fbdev

On Tue, Oct 11, 2016 at 04:15:04PM -0700, Stefan Agner wrote: > The current fbdev emulation does not allow to push back changes in > width, height or depth to KMS, hence reject any changes with an > error. This makes sure that fbdev ioctl's fail properly and user > space does not assume that

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/527f1b70/attachment.html>

[patch] drm/savage: dereferencing an error pointer

> A recent cleanup changed the kmalloc() + copy_from_user() to > memdup_user() but the error handling wasn't updated so we might call > kfree(-EFAULT) and crash. > > Fixes: a6e3918bcdb1 ('GPU-DRM-Savage: Use memdup_user() rather than > duplicating') > Signed-off-by: Dan Carpenter > > diff

[patch] drm/amdgpu: potential NULL dereference in debugfs code

On Wed, Oct 12, 2016 at 5:20 AM, Christian König wrote: > Am 12.10.2016 um 08:17 schrieb Dan Carpenter: >> >> debugfs_create_file() returns NULL on error, it only returns error >> pointers if debugfs isn't enabled in the config and we checked for that >> earlier so it can't happen. >> >> Fixes:

[RFC] drm/fb-helper: reject any changes to the fbdev

, var->yres_virtual, > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/51786b07/attachment.sig>

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On 11 October 2016 at 10:33, Jani Nikula wrote: > On Tue, 11 Oct 2016, "Sun, Jing A" wrote: >> It's needed that DRM Driver module could be removed and reloaded after >> kernel booting on the projects that I have been working on, and I hope >> such module type change could be accepted. Looks like

drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On a laptop that tracks the latest stable release (Ie, it now runs v4.8.1) I see this WARNING     WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Full trace pasted below. I never saw this WARNING before v4.8. Since v4.8 I've had it in all (four, actually) boots. What am I expected to do about

[RFC 6/6] drivers: staging: ion: add ION_IOC_TAG ioctl

On Wednesday, October 12, 2016 7:50 AM Ruchi Kandoi wrote: > +/** > + * struct ion_fd_data - metadata passed from userspace for a handle s/fd/tag/ ? > + * @handle: a handle > + * @tag: a string describing the buffer > + * > + * For ION_IOC_TAG userspace populates the handle field with > + * the

[patch] drm/amdgpu: potential NULL dereference in debugfs code

Am 12.10.2016 um 08:17 schrieb Dan Carpenter: > debugfs_create_file() returns NULL on error, it only returns error > pointers if debugfs isn't enabled in the config and we checked for that > earlier so it can't happen. > > Fixes: 4f4824b55650 ('drm/amd/amdgpu: Convert ring debugfs entries to

[RFC 0/6] Module for tracking/accounting shared memory buffers

Am 12.10.2016 um 01:50 schrieb Ruchi Kandoi: > This patchstack adds memtrack hooks into dma-buf and ion. If there's upstream > interest in memtrack, it can be extended to other memory allocators as well, > such as GEM implementations. We have run into similar problems before. Because of this I

Question: Re: [PATCH] drm/bridge: analogix: protect power when get_modes or detect

On Wed, Oct 12, 2016 at 6:22 AM, Mark yao wrote: > > I'm not familiar with the analogix driver, maybe use a power reference count > would better then direct power on/off analogix_dp. > > Does anyone has the idea to protect detect and get_modes context? > I'm not sure a reference count is going

[PATCH] drm/gma500: add comments for new parameters

Added comments for new parameters. Signed-off-by: Jiang Biao --- drivers/gpu/drm/gma500/gtt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c index 8f69225..76aea2e 100644 --- a/drivers/gpu/drm/gma500/gtt.c +++

[RFC 0/6] Module for tracking/accounting shared memory buffers

On 10/11/2016 04:50 PM, Ruchi Kandoi wrote: > Any process holding a reference to these buffers will keep the kernel from > reclaiming its backing pages. mm counters don't provide a complete picture of > these allocations, since they only account for pages that are mapped into a > process's

[RFC] drm/fb-helper: reject any changes to the fbdev

On 2016-10-12 09:12, Ville Syrjälä wrote: > On Wed, Oct 12, 2016 at 08:55:45AM -0700, Stefan Agner wrote: >> On 2016-10-12 03:42, Ville Syrjälä wrote: >> > On Tue, Oct 11, 2016 at 04:15:04PM -0700, Stefan Agner wrote: >> >> The current fbdev emulation does not allow to push back changes in >>

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

On 11/10/16 09:04 PM, Christian König wrote: > Am 11.10.2016 um 05:58 schrieb Michel Dänzer: >> On 07/10/16 09:34 PM, Mike Lothian wrote: >>> This has discussion has gone a little quiet >>> >>> Was there any agreement about what needed doing to get this working >>> for i965/amdgpu? >> Christian,

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/d66af789/attachment.html>

[patch] drm/savage: dereferencing an error pointer

A recent cleanup changed the kmalloc() + copy_from_user() to memdup_user() but the error handling wasn't updated so we might call kfree(-EFAULT) and crash. Fixes: a6e3918bcdb1 ('GPU-DRM-Savage: Use memdup_user() rather than duplicating') Signed-off-by: Dan Carpenter diff --git

[patch] drm/amdgpu: potential NULL dereference in debugfs code

debugfs_create_file() returns NULL on error, it only returns error pointers if debugfs isn't enabled in the config and we checked for that earlier so it can't happen. Fixes: 4f4824b55650 ('drm/amd/amdgpu: Convert ring debugfs entries to binary') Signed-off-by: Dan Carpenter diff --git

[Bug 177041] When browsing Google Map's Satellite view in Chrome or Firefox the screen freezes and goes black, occasionally control is returned to user

https://bugzilla.kernel.org/show_bug.cgi?id=177041 --- Comment #1 from Michel Dänzer --- Can you try a newer kernel, ideally 4.8.y? I seem to remember running into this before, but no longer with current kernels. Unfortunately, I don't remember specifically how this was fixed. -- You are

[bug report] drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.

Hello Rex Zhu, This is a semi-automatic email about new static checker warnings. The patch 599a7e9fe1b6: "drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7." from Sep 9, 2016, leads to the following Smatch complaint:

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

I think "installing a kernel with my changes for both drm and i915" takes more time and effort to complete than "only updating DRM/i915 modules without rebuilding the whole kernel". In some cases, that's beneficial. Also reloadablility is always a good thing to have and I truly hope

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/b1e0e045/attachment.html>

[RFC] drm/fb-helper: reject any changes to the fbdev

On Tue, Oct 11, 2016 at 04:15:04PM -0700, Stefan Agner wrote: > The current fbdev emulation does not allow to push back changes in > width, height or depth to KMS, hence reject any changes with an > error. This makes sure that fbdev ioctl's fail properly and user > space does not assume that

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/faacb826/attachment.html>

[RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 10:24:23PM +0100, Brian Starkey wrote: > On Tue, Oct 11, 2016 at 10:02:43PM +0200, Daniel Vetter wrote: > > The problem with just that is that there's lots of different things > > that can feed into the overall needs_modeset variable. That's why we > > split it up into

[RFC] drm/fb-helper: reject any changes to the fbdev

On 2016-10-12 03:42, Ville Syrjälä wrote: > On Tue, Oct 11, 2016 at 04:15:04PM -0700, Stefan Agner wrote: >> The current fbdev emulation does not allow to push back changes in >> width, height or depth to KMS, hence reject any changes with an >> error. This makes sure that fbdev ioctl's fail

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On Wed, Oct 12, 2016 at 03:08:24AM +, Sun, Jing A wrote: > Interestingly, I am able to reload i915 and drm. Our CI has tests for > i915 unload/reload, but does not check drm. In any case the config > problem should not impact the reloadability of i915. > == > Sorry that I didn't make

[RFC PATCH 00/11] Introduce writeback connectors

Hi Eric, On Tue, Oct 11, 2016 at 12:01:14PM -0700, Eric Anholt wrote: >Brian Starkey writes: > >> Hi, >> >> This RFC series introduces a new connector type: >> DRM_MODE_CONNECTOR_WRITEBACK >> It is a follow-on from a previous discussion: [1] >> >> Writeback connectors are used to expose the

[git pull] drm pull for v4.9

Hi Linus, sorry for the delay, had sick wife/baby combo deal last week, which led to a much reduced sleep pattern. during that I mismerged i915. this email is all in small letters because my gpg key expired so I couldn't sign the tag, and it's too early in the morning for me to go do gpg stuff.

[git pull] drm for 4.8

On 12 October 2016 at 05:59, Linus Torvalds wrote: > What's the status of the 4.9 merge window pull request? The GPU side > is the main remaining pile for this merge window according to > linux-next. I'd hate to get a last-minute pull at the end of the week I'm lining it up this morning, had

[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay

gnee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161012/5f3992c5/attachment.html>

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

Interestingly, I am able to reload i915 and drm. Our CI has tests for i915 unload/reload, but does not check drm. In any case the config problem should not impact the reloadability of i915. == Sorry that I didn't make myself clear. In order to replace the default i915 module with an updated

[RFC 0/6] Module for tracking/accounting shared memory buffers

On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote: > memtrack maintains a per-process list of shared buffer references, which is > exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally > "tagged" with a short string: for example, Android userspace would use this >