Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev

On 30/05/17 05:13 AM, Chris Wilson wrote: > On Mon, May 29, 2017 at 09:04:07PM +0200, Daniel Vetter wrote: >> On Mon, May 29, 2017 at 09:02:38PM +0200, Daniel Vetter wrote: >>> On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote: Since commit a39be606f99d ("drm: Do a full device

Re: [PATCH] drm/i915/gvt: remove redundant -Wall

ping for review ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 31/37] drm/stm: Drop drm_vblank_cleanup

On 05/24/2017 04:52 PM, Daniel Vetter wrote: > Again seems just cargo-culted. > > Cc: Yannick Fertre > Cc: Philippe Cornu > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/stm/ltdc.c | 2 -- > 1 file changed, 2

Re: [PATCH v11] drm: Unplug drm device when unregistering it (v8)

On Mon, May 29, 2017 at 5:25 PM, Chris Wilson wrote: > convince us to look into this patch again? > -Chris > >> > >> > drivers/gpu/drm/drm_drv.c | 26 ++ >> > drivers/gpu/drm/udl/udl_drv.c | 3 ++- >> > include/drm/drmP.h| 6

Re: [PATCH 20/29] sync_file.txt: standardize document format

Em Wed, 24 May 2017 22:36:36 -0300 Gustavo Padovan escreveu: > Hi Mauro, > > 2017-05-18 Mauro Carvalho Chehab : > > > Each text file under Documentation follows a different > > format. Some doesn't even have titles! > > > > Change its

Re: [PATCH 1/8] drm/exynos: use drm_for_each_connector_iter()

2017년 05월 12일 04:10에 Gustavo Padovan 이(가) 쓴 글: > From: Gustavo Padovan > > Drop legacy drm_for_each_connector() in favor of the race-free > drm_for_each_connector_iter() > > Cc: Inki Dae > Cc: Joonyoung Shim >

Re: [PATCH 18/37] drm/exynos: Drop drm_vblank_cleanup

Hi Daniel, 2017년 05월 24일 23:51에 Daniel Vetter 이(가) 쓴 글: > Only in the load failure path, where the hardware is quiet anyway. > > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park

[PULL] drm-intel-next

:01 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-05-29 for you to fetch changes up to cd9f4688a3297c0df0eecc2adaae5812d3e5b997: drm/i915: Update DRIVER_DATE to 20170529 (2017-05-29 09:00:58 +0

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #27 from MirceaKitsune --- In weekly news, it appears a recent openSUSE Tumbleweed snapshot (which among other changes upgraded Mesa 17.0.5 to 17.1.0) made the issue a lot rarer for the time

Re: [PATCH v11] drm: Unplug drm device when unregistering it (v8)

On Fri, Apr 14, 2017 at 11:15:04AM -0400, Sean Paul wrote: > On Thu, Apr 13, 2017 at 03:32:44PM +0800, Jeffy Chen wrote: > > After unbinding drm, the user space may still owns the drm dev fd, and > > may still be able to call drm ioctl. > > > > We're using an unplugged state to prevent something

Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev

On Mon, May 29, 2017 at 09:04:07PM +0200, Daniel Vetter wrote: > On Mon, May 29, 2017 at 09:02:38PM +0200, Daniel Vetter wrote: > > On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote: > > > Since commit a39be606f99d ("drm: Do a full device unregister when > > > unplugging")

Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev

On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote: > Since commit a39be606f99d ("drm: Do a full device unregister when > unplugging") drm_unplug_dev has been calling drm_dev_unregister followed > by a drm_put_dev when open_count reaches 0. This drm_put_dev calls > drm_dev_unregister

Re: [PATCH v5 04/10] drm: Use mode_valid() in atomic modeset

On Thu, May 25, 2017 at 03:19:16PM +0100, Jose Abreu wrote: > This patches makes use of the new mode_valid() callbacks introduced > previously to validate the full video pipeline when modesetting. > > This calls the connector->mode_valid(), encoder->mode_valid(), > bridge->mode_valid() and

Re: [PATCH 07/37] drm: Extract drm_vblank.[hc]

On 2017-05-24 07:51, Daniel Vetter wrote: > drm_irq.c contains both the irq helper library (optional) and the > vblank support (optional, but part of the modeset uapi, and doesn't > require the use of the irq helpers at all. > > Split this up for more clarity of the scope of the individual bits.

Re: drm_atomic_helper_resume() locking changes in v4.12

On Mon, May 29, 2017 at 05:29:55PM +0300, Jyri Sarha wrote: > Hi, > I have "WARN_ON(!drm_modeset_is_locked(>mutex))" in tilcdc crtc > enable and disable callbacks. Now those warnings are firing when > resuming from suspend and I see that "drm_modeset_lock_all(dev)" has > been removed from

[PATCH] drm: Fix locking in drm_atomic_helper_resume

In the conversion to drop drm_modeset_lock_all and the magic implicit context I failed to realize that _resume starts out with a pile of state copies, but not with the locks. And hence drm_atomic_commit won't grab these for us. Cc: Jyri Sarha Fixes: a5b8444e289c

Re: drm_atomic_helper_resume() locking changes in v4.12

On Mon, May 29, 2017 at 05:29:55PM +0300, Jyri Sarha wrote: > Hi, > I have "WARN_ON(!drm_modeset_is_locked(>mutex))" in tilcdc crtc > enable and disable callbacks. Now those warnings are firing when > resuming from suspend and I see that "drm_modeset_lock_all(dev)" has > been removed from

Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev

On Mon, May 29, 2017 at 09:02:38PM +0200, Daniel Vetter wrote: > On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote: > > Since commit a39be606f99d ("drm: Do a full device unregister when > > unplugging") drm_unplug_dev has been calling drm_dev_unregister followed > > by a drm_put_dev

Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev

On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote: > Since commit a39be606f99d ("drm: Do a full device unregister when > unplugging") drm_unplug_dev has been calling drm_dev_unregister followed > by a drm_put_dev when open_count reaches 0. This drm_put_dev calls > drm_dev_unregister

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: > On 05/26/2017 09:15 AM, Daniel Vetter wrote: > > On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote: > >> From: Hans Verkuil > >> > >> Implement support for this DisplayPort feature. > >> > >> The

Re: [PATCH 08/37] drm/doc: Polish irq helper documentation

On Thu, May 25, 2017 at 12:46:29AM -0700, Stefan Agner wrote: > On 2017-05-24 07:51, Daniel Vetter wrote: > > Pull a (much shorter) overview into drm_irq.c, and instead put the > > callback documentation into in-line comments in drm_drv.h. > > Looks good and just found all I needed to know to fix

[PATCH 03/15] drm: zte: use devm_of_platform_populate()

Use devm_of_platform_populate() to be sure that of_platform_depopulate is called when removing the driver. Signed-off-by: Benjamin Gaignard CC: Shawn Guo CC: David Airlie CC: dri-devel@lists.freedesktop.org CC:

[PATCH 04/15] drm: msm: use devm_of_platform_populate()

Use devm_of_platform_populate() to simplify driver code. Signed-off-by: Benjamin Gaignard CC: Rob Clark CC: David Airlie CC: linux-arm-...@vger.kernel.org CC: dri-devel@lists.freedesktop.org CC:

[PATCH 00/15] make more driver use devm_of_platform_populate()

Number of calls to of_platform_populate() aren't unbalanced by a call to of_platform_depopulate() that could generate issue will loading/unloading the drivers. Make those drivers use devm_of_platform_populate() fix the problem without need to add remove function. In some case replacing

drm_atomic_helper_resume() locking changes in v4.12

Hi, I have "WARN_ON(!drm_modeset_is_locked(>mutex))" in tilcdc crtc enable and disable callbacks. Now those warnings are firing when resuming from suspend and I see that "drm_modeset_lock_all(dev)" has been removed from "drm_atomic_helper_resume()". I guess I should remove those warnings from

[PATCH] drm/meson: Fix driver bind when only CVBS is available

While introducing HDMI support, component matching on connectors node were bypassed since no driver would actually bind on the DT node. But when only a CVBS connector is present, only a single node is found in the graph, but ignored and a NULL match table is given to the component code. This code

[PULL] drm-intel-fixes

Hi Dave, fixes all around, including GVT. I guess Joonas' RCU sync fix is the most important one. I've got the DP quirk stuff I asked about sitting on a branch, feeding to drm-tip too, hoping to get a bit more testing on it. I'll send a separate pull request for it later this week. BR, Jani.

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

https://bugs.freedesktop.org/show_bug.cgi?id=99349 --- Comment #11 from Gert Wollny --- Created attachment 131567 --> https://bugs.freedesktop.org/attachment.cgi?id=131567=edit TGSI for failing shader This is the failing shader. For some reasons 151 GPRs are allocate as

Re: [PATCH libdrm] Android's major/minor/makedev live in

On 28 May 2017 at 15:38, Rob Herring wrote: > On Mon, May 22, 2017 at 11:06 AM, Emil Velikov > wrote: >> On 20 May 2017 at 19:24, enh wrote: >>> Bug: https://github.com/android-ndk/ndk/issues/398 >>> --- >>> Android.common.mk | 1 +

Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

Am 29.05.2017 um 09:30 schrieb Dave Airlie: From: Dave Airlie This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced

Re: [PATCH 23/37] drm/imx: Drop drm_vblank_cleanup

Hi Daniel, On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote: > It's only done in the driver load error path, where vblanks don't need > to be quiescent anyway. And that's all drm_vblank_cleanup does, since > the core will release the vblank allocations on its own already. So > drop it.

Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On Thu, 18 May 2017, "Pandiyan, Dhinakaran" wrote: > On Thu, 2017-05-18 at 14:10 +0300, Jani Nikula wrote: >> Face the fact, there are Display Port sink and branch devices out there >> in the wild that don't follow the Display Port specifications, or they >> have

Re: [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On Thu, 18 May 2017, Clint Taylor wrote: > On 05/18/2017 04:10 AM, Jani Nikula wrote: >> Face the fact, there are Display Port sink and branch devices out there >> in the wild that don't follow the Display Port specifications, or they >> have bugs, or just otherwise

Re: [PATCH v5 07/10] drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback

On 05/25/2017 04:19 PM, Jose Abreu wrote: > Now that we have a callback to check if bridge supports a given mode > we can use it in Synopsys Designware HDMI bridge so that we restrict > the number of probbed modes to the ones we can actually display. > > Also, there is no need to use mode_fixup()

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #43 from erhar...@mailbox.org --- What would be the best way to do this? Start a 2nd bisect in search for the commit which causes/fixes the boot failure and exclude/include it in my 1st bisect? Sorry, I don't have that much experience

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

https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #51 from Eike --- I just received my replacement MG279Q, here is what changed and what didn't. The monitor OSD still reports 139Hz instead of 144, BUT all artifacts (vertical lines) are gone. So to everyone who has

[Bug 101213] Kernel 4.11: amdgpu regression causes artifacts with OLAND amd gpu gcn 1.0

https://bugs.freedesktop.org/show_bug.cgi?id=101213 --- Comment #4 from siyia --- ooops yeah so should i close this issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 101213] Kernel 4.11: amdgpu regression causes artifacts with OLAND amd gpu gcn 1.0

https://bugs.freedesktop.org/show_bug.cgi?id=101213 --- Comment #3 from Michel Dänzer --- It's a different bugzilla. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 101213] Kernel 4.11: amdgpu regression causes artifacts with OLAND amd gpu gcn 1.0

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

Re: [PATCH v4 00/11] drm: sun4i: Add support for the HDMI controller

On Sat, May 27, 2017 at 06:09:25PM +0200, Maxime Ripard wrote: > Hi, > > Here is an attempt at getting the HDMI controller running. > > This HDMI controller is found on a number of old Allwinner SoCs (A10, A10s, > A20, A31). > > This driver only supports for now the A10s because it was an easy

Re: [PATCH 32/37] drm/sun4i: Drop drm_vblank_cleanup

On Wed, May 24, 2017 at 04:52:07PM +0200, Daniel Vetter wrote: > Again seems just cargo-culted ... It's not ordered against any > irq/vblank/modeset shutdown. > > Cc: Maxime Ripard > Signed-off-by: Daniel Vetter Acked-by: Maxime

Re: Maintaining small drm drivers

On Mon, May 29, 2017 at 8:53 AM, Daniel Vetter wrote: >>> Find another smaller driver in need of some cleanup (we can add more >>> to drm-misc), cross review. Yes it's a bit of work (see above), but at >>> least from the drm subsystem pov the end result will be worth it, >>>

[PATCH 4/5] amdgpu/cs: split out fence dependency checking

From: Dave Airlie This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies. Reviewed-by: Christian König Signed-off-by: Dave Airlie ---

[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

From: Dave Airlie This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with two new chunks, one for syncobj pre

[PATCH 2/5] drm/syncobj: add sync obj wait interface. (v4)

From: Dave Airlie This interface will allow sync object to be used to back Vulkan fences. This API is pretty much the vulkan fence waiting API, and I've ported the code from amdgpu. v2: accept relative timeout, pass remaining time back to userspace. v3: return to absolute

[PATCH 1/5] drm: introduce sync objects (v3)

From: Dave Airlie Sync objects are new toplevel drm object, that contain a pointer to a fence. This fence can be updated via command submission ioctls via drivers. There is also a generic wait obj API modelled on the vulkan wait API (with code modelled on some amdgpu code).

[PATCH 3/5] drm/syncobj: add sync_file interaction. (v1.1)

From: Dave Airlie This interface allows importing the fence from a sync_file into an existing drm sync object, or exporting the fence attached to an existing drm sync object into a new sync file object. This should only be used to interact with sync files where necessary.

drm-syncobj - mostly wait changes

The wait patch seemed to get the most discussion last time, so I've overhauled it. The others are mostly unchanged. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #42 from Michel Dänzer --- That's quite a lot of candidates still. To narrow it down further, you can find out which commit fixed the boot failure, and then manually apply that for testing the skipped commits. --

Re: [PULL] drm-misc-next

On Fri, May 26, 2017 at 04:58:37PM -0400, Sean Paul wrote: > Hi Dave, > Here's another misc-next pull for you. We have some nice improvements in core > adding mode_valid hooks and de-duping the allocation code. Daniel continues to > improve documentation (\o/), and a bunch of little stuff was

Re: [PULL] drm-misc-fixes

On Sun, May 28, 2017 at 12:08:13PM +0200, Lukas Wunner wrote: > On Fri, May 26, 2017 at 08:36:45AM +0200, Daniel Vetter wrote: > > On Thu, May 25, 2017 at 7:44 PM, Sean Paul wrote: > > > The pull is noisy because it includes -rc2. > > > > dim has you covered for this, in

Re: [PATCH 02/37] drm: Remove drm_device->virtdev

On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote: > This is a leftover from the drm_bus days, where we've had a > bus-specific device type for every bus type in drm_device. Except for > pci (which we can't remove because dri1 drivers) this is all gone. > And > the virt driver also doesn't

Re: Maintaining small drm drivers

On Sun, May 28, 2017 at 2:10 PM, Patrik Jakobsson wrote: > On Fri, May 26, 2017 at 8:49 AM, Daniel Vetter wrote: >> On Thu, May 25, 2017 at 1:09 AM, Patrik Jakobsson >> wrote: >>> On Wed, May 24, 2017 at 9:52 PM,

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

Hopefully addressing most of these in the upcoming set, some comments below. >> +/** >> + * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute >> value >> + * >> + * @timeout_ns: timeout in ns >> + * >> + * Calculate the timeout in jiffies from an absolute timeout in ns. >> +

[Bug 101224] texelFetch(usampler) returns black color

https://bugs.freedesktop.org/show_bug.cgi?id=101224 Bug ID: 101224 Summary: texelFetch(usampler) returns black color Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW