[GIT PULL] exynos-drm-next

Hi Dave, Sorry for late. Just refactoring HDMI driver by using infoframe helper function, fixing GSC Kconfig dependency issue and including trivial cleanups. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit

[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161206/46ac7ef1/attachment.html>

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

On 06/12/16 05:07 AM, Alex Deucher wrote: > Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a > struct drm_device's ->control member is always NULL. > > In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses > ->control->debugfs_root though. This results in the following

[PULL] MXSFB driver

On 2 December 2016 at 04:02, Marek Vasut wrote: > Hi, > > as asked by Daniel, I collected the MXSFB DT Acks and the driver and > wrapped it into PR (below). Hi Marek this isn't pullable as-is as it seems to be based on -next tree or something. Please create pull requests based on a Linus or

[PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

ri-devel -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/277500f5/attachment.html>

[PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

On 06/12/16 10:42 AM, Mike Lothian wrote: > Hi > > This patch (in drm-next and drm-intel-nightly) stops my system from > booting, I don't see any errors, just a black screen and a reboot after > the kernel has been selected > > I have confirmed that reverting this patch gets those two branches

[PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

sa and X developer > -- next part ------ An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/7649e049/attachment.html>

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

;debugfs[i].num_files, > >adev->ddev->primary); > > } > > #endif > > -- > > 2.10.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/371cb336/attachment-0001.html>

[Bug 98993] dosbox artefacts when using opengl

TML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/2b1da60c/attachment.html>

[Bug 98993] dosbox artefacts when using opengl

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

[Bug 98993] dosbox artefacts when using opengl

... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/e7ac8c04/attachment.html>

[PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2

On Mon, Dec 05, 2016 at 05:56:40PM +, Emil Velikov wrote: > On 1 December 2016 at 04:18, Jonathan Gray wrote: > > DRI devices on OpenBSD are not in their own directory. They reside in > > /dev with a large number of statically generated /dev nodes. > > > > Avoid stat'ing all of /dev on

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

ssignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/1b048001/attachment.html>

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

d off" if we switch to the console with Ctrl-Alt-F2? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/5335d959/attachment.html>

[PATCH 0/8] Host1x IOMMU support + VIC support

On Mon, Dec 05, 2016 at 08:51:31PM +0100, Thierry Reding wrote: > On Thu, Nov 10, 2016 at 08:23:37PM +0200, Mikko Perttunen wrote: > > This series adds IOMMU support to Host1x and TegraDRM > > and adds support for the VIC host1x client so that > > host1x can be tested on modern Tegra platforms. >

[Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status

On Mon, Dec 05, 2016 at 12:33:28PM -0800, Manasi Navare wrote: > On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote: > > Hm, tiny new bikeshed: I'd drop the _property postfix here. The function > > name is already really long as-is, and the fact that the link status is > > exposed as a

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

On Tue, Dec 06, 2016 at 02:01:37AM +, Mike Lothian wrote: > Feel free to add a tested by from myself > > Thanks for the fix > > On Mon, 5 Dec 2016 at 20:33 Deucher, Alexander > wrote: > > > > -Original Message- > > > From: Nicolai Stange [mailto:nicstange at gmail.com] > > > Sent:

[Intel-gfx] [PATCH 1/4] drm: Add a new connector atomic property for link status

On Mon, Dec 05, 2016 at 04:27:35PM -0800, Manasi Navare wrote: > At the time userspace does setcrtc, we've already promised the mode > would work. The promise is based on the theoretical capabilities of > the link, but it's possible we can't reach this in practice. The DP > spec describes how the

[Bug 98541] [bisected] gpu hang

: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/e223522a/attachment-0001.html>

[PULL] MXSFB driver

On Tue, Dec 06, 2016 at 11:08:06AM +1000, Dave Airlie wrote: > On 2 December 2016 at 04:02, Marek Vasut wrote: > > Hi, > > > > as asked by Daniel, I collected the MXSFB DT Acks and the driver and > > wrapped it into PR (below). > > Hi Marek > > this isn't pullable as-is as it seems to be based

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

Am 06.12.2016 um 02:00 schrieb Michel Dänzer: > On 06/12/16 05:07 AM, Alex Deucher wrote: >> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a >> struct drm_device's ->control member is always NULL. >> >> In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses >>

[PATCH v2 2/3] drm/edid: Implement SCDC support detection

On Mon, Dec 05, 2016 at 06:11:44PM +0100, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote: > > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote: > > > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote: > > > > On Mon, Dec 05, 2016 at

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 02:19:48PM +, Jose Abreu wrote: > > Hi Thierry, > > > > > > On 05-12-2016 11:14, Thierry Reding wrote: > > > On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote: > > >> Hi Thierry, > > >> > > >>

[Bug 91281] Tonga VCE 2160p encode fails with BO to small for addr

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

[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

t attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/7cb9663f/attachment.sig>

[PATCH] drm: Don't block the kworker waiting for mode_config.lock in output_poll()

If we cannot acquire the mode_config.lock immediately, just back off and queue a new attempt after the poll interval. This is mostly to stop the hung task spam when the system is deadlocked, but it will also lessen the load (in such extreme cases). Signed-off-by: Chris Wilson ---

[PATCH] drm: Don't block the kworker waiting for mode_config.lock in output_poll()

On Tuesday, 2016-12-06 11:37:15 +, Chris Wilson wrote: > If we cannot acquire the mode_config.lock immediately, just back off and s/mode_config.lock/mode_config.mutex lock/ ? > queue a new attempt after the poll interval. This is mostly to stop the > hung task spam when the system is

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

mething based on it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/1d6a3e60/attachment.html>

[PATCH] drm/qxl: Don't register debugfs for control minors

2016-12-05 Daniel Vetter : > They're gone since 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"). > Spotted while doing a full audit when revieng a similar patch from > Nicolai for radeon. > > v2: Drink coffee first aka don't forget the unregister side. > > Cc: Dave Airlie > Fixes: 8a357d10043c

[PATCH RFC 1/7] drm/armada: add tracing support

Hi Russell I need the below fixup to make this build for me: diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile index a18f156c8b66..64c0b4546fb2 100644 --- a/drivers/gpu/drm/armada/Makefile +++ b/drivers/gpu/drm/armada/Makefile @@ -4,3 +4,5 @@ armada-y+=

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

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

[Intel-gfx] [PATCH] drm: Don't block the kworker waiting for mode_config.lock in output_poll()

On Tue, Dec 06, 2016 at 11:55:14AM +, Eric Engestrom wrote: > On Tuesday, 2016-12-06 11:37:15 +, Chris Wilson wrote: > > If we cannot acquire the mode_config.lock immediately, just back off and > > s/mode_config.lock/mode_config.mutex lock/ ? Fixed > > > queue a new attempt after the

[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

Hi Mark, On Tuesday 06 Dec 2016 10:05:17 Mark Brown wrote: > On Mon, Dec 05, 2016 at 11:16:22PM +0200, Laurent Pinchart wrote: > > On Monday 05 Dec 2016 13:11:51 Bjorn Andersson wrote: > >> Further more, a DT binding for a particular block should describe that > >> block; so if we have three

[PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

2016-12-05 13:49 GMT+01:00 Tomi Valkeinen : > On 29/11/16 13:57, Bartosz Golaszewski wrote: >> Add the dumb-vga-dac node to the board DT together with corresponding >> ports and vga connector. This allows to retrieve the edid info from >> the display automatically. >> > > It's a bit difficult to

[PATCH v4 0/2] ARM: dts: da850: tilcdc related DT changes

This series contains the last DT changes required for LCDC support on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second limits the maximum pixel clock rate. v1 -> v2: - drop patch 3/3 (already merged) - use max-pixelclock instead of max-bandwidth for display mode limiting v2 ->

[PATCH v4 2/2] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc

At maximum CPU frequency of 300 MHz the maximum pixel clock frequency is 37.5 MHz[1]. We must filter out any mode for which the calculated pixel clock rate would exceed this value. Specify the max-pixelclock property for the display node for da850-lcdk. [1]

[PATCH v4 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

Add the dumb-vga-dac node to the board DT together with corresponding ports and vga connector. This allows to retrieve the edid info from the display automatically. Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850-lcdk.dts | 69 1 file

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/6c3e2521/attachment.html>

[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

-- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/b95837c1/attachment-0001.sig>

[bug report] drm/bridge: Add ti-tfp410 DVI transmitter driver

Hello Jyri Sarha, The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter driver" from Oct 31, 2016, leads to the following static checker warning: drivers/gpu/drm/bridge/ti-tfp410.c:141 tfp410_get_connector_ddc() warn: missing error code here?

[PATCH v4 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

Hi Bartosz, Thank you for the patch. On Tuesday 06 Dec 2016 14:13:45 Bartosz Golaszewski wrote: > Add the dumb-vga-dac node to the board DT together with corresponding > ports and vga connector. This allows to retrieve the edid info from > the display automatically. > > Signed-off-by: Bartosz

[PATCH] drm: rcar-du: Fix R-Car Gen3 crash when VSP is disabled

Hello, On Wednesday 26 Oct 2016 18:13:23 Magnus Damm wrote: > On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote: > > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote: > >> From: Magnus Damm > >> > >> For the DU to operate on R-Car Gen3 hardware a

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/67489c84/attachment.html>

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote: > +++ b/kernel/locking/mutex.c > @@ -350,7 +350,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock, > * access and not reliable. > */ > static noinline > -bool mutex_spin_on_owner(struct mutex *lock, struct task_struct

[PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

2016-12-06 16:03 GMT+01:00 Sekhar Nori : > On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote: >> 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen : >>> On 29/11/16 13:57, Bartosz Golaszewski wrote: Add the dumb-vga-dac node to the board DT together with corresponding ports and vga

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: > +++ b/include/linux/ww_mutex.h > @@ -222,11 +222,7 @@ extern int __must_check > __ww_mutex_lock_interruptible(struct ww_mutex *lock, > */ > static inline int ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx > *ctx) >

[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface

ext part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/db7147ba/attachment.html>

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: > @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, > unsigned int subclass, > struct mutex_waiter waiter; > unsigned long flags; > bool first = false; > - struct ww_mutex *ww; >

[Freedreno] [PATCH 12/12] drm/msm: gpu: Use the zap shader on 5XX if we can

On Mon, Dec 05, 2016 at 11:57:12AM -0800, Bjorn Andersson wrote: > On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote: > > > The A5XX GPU powers on in "secure" mode. In secure mode the GPU can > > only render to buffers that are marked as secure and inaccessible > > to the kernel and user through

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: > +static inline int __sched > +__ww_mutex_add_waiter(struct mutex_waiter *waiter, > + struct mutex *lock, > + struct ww_acquire_ctx *ww_ctx) > +{ > + struct mutex_waiter *cur; > + > + if

[PATCH 00/10] virtio: sparse fixes

I run latest sparse from git on virtio drivers (turns out the version I had was rather outdated). This patchset fixes a couple of bugs this uncovered, and adds some annotations to make it sparse-clean. In particular, endian-ness is often tricky, so this patchset enabled endian-ness checks for

[PATCH 02/10] drm/virtio: fix endianness in primary_plane_update

virtio_gpu_cmd_transfer_to_host_2d expects x and y parameters in LE, but virtio_gpu_primary_plane_update passes in the CPU format instead. Signed-off-by: Michael S. Tsirkin --- drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 03/10] drm/virtio: fix lock context imbalance

When virtio_gpu_free_vbufs exits due to list empty, it does not drop the free_vbufs lock that it took. list empty is not expected to happen anyway, but it can't hurt to fix this and drop the lock. Signed-off-by: Michael S. Tsirkin --- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +++- 1 file

[PATCH 04/10] drm/virtio: annotate virtio_gpu_queue_ctrl_buffer_locked

virtio_gpu_queue_ctrl_buffer_locked is called with ctrlq.qlock taken, it releases and acquires this lock. This causes a sparse warning. Add appropriate annotations for sparse context checking. Signed-off-by: Michael S. Tsirkin --- drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++ 1 file changed, 2

[PATCH 10/10] virtio: enable endian checks for sparse builds

__CHECK_ENDIAN__ isn't on by default presumably because it triggers too many sparse warnings for correct code. But virtio is now clean of these warnings, and we want to keep it this way - enable this for sparse builds. Signed-off-by: Michael S. Tsirkin --- It seems that there should be a better

[Bug 97980] [amdgpu] New kernel warning during shutdown

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

[Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth

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

[Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth

||g/show_bug.cgi?id=97980 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/062e3

[Bug 97980] [amdgpu] New kernel warning during shutdown

||g/show_bug.cgi?id=98638 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/94b9b

[RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

n-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/1e6499f1/attachment.sig>

[PATCH] drm/panel: simple: Check against num_timings when setting preferred for timing

pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/5695986c/attachment.sig>

[Intel-gfx] [PATCH 1/4] drm: Add a new connector atomic property for link status

On Tue, Dec 06, 2016 at 08:23:05AM +0100, Daniel Vetter wrote: > On Mon, Dec 05, 2016 at 04:27:35PM -0800, Manasi Navare wrote: > > At the time userspace does setcrtc, we've already promised the mode > > would work. The promise is based on the theoretical capabilities of > > the link, but it's

[PATCH] drm/panel: simple: add 8bit-bps for Sharp lq123p1jx31

--- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/7b336421/attachment-0001.sig>

[PATCH 1/3] drm/panel: simple: add more properties to Innolux G121I1-L01

ure Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/d4935fbd/attachment.sig>

[PATCH 2/3] drm/panel: simple: add support for AUO G133HAN01

- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/35068881/attachment.sig>

[PATCH v4 1/4] drm: Add a new connector atomic property for link status

At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the

[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

Hi Mark, On Tuesday 06 Dec 2016 13:20:20 Mark Brown wrote: > On Tue, Dec 06, 2016 at 02:46:55PM +0200, Laurent Pinchart wrote: > > On Tuesday 06 Dec 2016 10:05:17 Mark Brown wrote: > > > On Mon, Dec 05, 2016 at 11:16:22PM +0200, Laurent Pinchart wrote: > > > > This has been discussed previously,

[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

reedesktop.org/archives/dri-devel/attachments/20161206/720fbb93/attachment-0001.sig>

[Freedreno] [PATCH 12/12] drm/msm: gpu: Use the zap shader on 5XX if we can

On Tue, Dec 6, 2016 at 10:35 AM, Jordan Crouse wrote: > On Mon, Dec 05, 2016 at 11:57:12AM -0800, Bjorn Andersson wrote: >> On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote: >> >> > The A5XX GPU powers on in "secure" mode. In secure mode the GPU can >> > only render to buffers that are marked

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: > @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state, > unsigned int subclass, >* mutex_unlock() handing the lock off to us, do a trylock >* before testing the error conditions to

Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote: > > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > > device-dax instance under the nvme device, or if you already have the

[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to display anything

changed the product to reflect the correct issue source. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/59e9f

[PATCH] drm/fence: add drm_crtc_create_fence()

From: Gustavo Padovan Instead of dealing with crtc details inside drm_atomic.c we should just export a function that creates a new crtc fence for us and use that. Suggested-by: Chris Wilson Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/drm_atomic.c

[Freedreno] [PATCH 11/12] drm/msm: Add a quick and dirty PIL loader

On Mon, Dec 05, 2016 at 11:57:43AM -0800, Bjorn Andersson wrote: > > + if (of_property_read_u32(pdev->dev.of_node, "qcom,pas-id", _id)) { > > This is constant, so define it in the driver. Little bit concerned it might not always be constant but I suppose we can cross that bridge when we get to

[PATCH] staging/android: remove Sync Framework tasks from TODO

From: Gustavo Padovan The destaging work is now fully complete. Cc: Arve Hjønnevåg Cc: Riley Andrews Signed-off-by: Gustavo Padovan --- drivers/staging/android/TODO | 8 1 file changed, 8 deletions(-) diff --git a/drivers/staging/android/TODO

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

On Tue, Dec 06, 2016 at 11:03:28AM -0500, Waiman Long wrote: > > The mutex_spin_on_owner() function was originally marked noinline > because it could be a major consumer of CPU cycles in a contended lock. > Having it shown separately in the perf output will help the users have a > better

[PATCH] drm/atomic: doc: remove old comment about nonblocking commits

2016-12-05 Daniel Vetter : > On Mon, Dec 05, 2016 at 12:03:46PM -0200, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > We now support nonblocking commits on drm_atomic_helper_commit() > > so the comment is not valid anymore. > > > > Signed-off-by: Gustavo Padovan > > Oops.

[Bug 97980] [amdgpu] New kernel warning during shutdown

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161206/a58a6a95/attachment.html>

[Bug 97980] [amdgpu] New kernel warning during shutdown

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

[Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth

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

[Intel-gfx] [RFC 5/5] drm: Do not log driver prefix in debug messages

Hi Tvrtko, 2016-12-06 Tvrtko Ursulin : > From: Tvrtko Ursulin > > Driver prefix is a bit redundant in debug messages. If we choose > not to log it we change debug messages which used to look like this: > > [i915:edp_panel_off [i915]] Wait for panel power off time > > to this: > >

[PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

ture Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/ca91b559/attachment-0001.sig>

[PATCH 14/22] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote: > Make it clear that the core bridge/dw_hdmi.txt document isn't a device > tree binding by itself but is meant to be referenced by platform device > tree bindings, and update the Rockchip and Freescale DWC HDMI TX > bindings to

[PATCH 15/22] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings

On Fri, Dec 02, 2016 at 01:43:30AM +0200, Laurent Pinchart wrote: > The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add > corresponding device tree bindings based on the DWC HDMI TX bindings > model. > > Signed-off-by: Laurent Pinchart

Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 6, 2016 at 1:47 PM, Logan Gunthorpe wrote: > Hey, > >> Okay, so clearly this needs a kernel side NVMe specific allocator >> and locking so users don't step on each other.. > > Yup, ideally. That's why device dax isn't ideal for this application: it > doesn't provide any way to prevent

[PULL] MXSFB driver

On 12/06/2016 02:08 AM, Dave Airlie wrote: > On 2 December 2016 at 04:02, Marek Vasut wrote: >> Hi, >> >> as asked by Daniel, I collected the MXSFB DT Acks and the driver and >> wrapped it into PR (below). > > Hi Marek Hi! > this isn't pullable as-is as it seems to be based on -next tree or

Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 06, 2016 at 09:51:15AM -0700, Logan Gunthorpe wrote: > Hey, > > On 06/12/16 09:38 AM, Jason Gunthorpe wrote: > >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > >>> device-dax

[Freedreno] [PATCH 12/12] drm/msm: gpu: Use the zap shader on 5XX if we can

On Tue 06 Dec 07:35 PST 2016, Jordan Crouse wrote: > On Mon, Dec 05, 2016 at 11:57:12AM -0800, Bjorn Andersson wrote: > > On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote: > > > > > The A5XX GPU powers on in "secure" mode. In secure mode the GPU can > > > only render to buffers that are marked

Enabling peer to peer device transactions for PCIe devices

> > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > device-dax instance under the nvme device, or if you already have the nvme > > sysfs path the dax instance(s) will appear under the "dax"

[GIT PULL] drm: Add support for the Amlogic Video Processing Unit

Dear DRM/DRI Maintainer, The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911: Linux 4.9-rc4 (2016-11-05 16:23:36 -0700) are available in the git repository at: git at github.com:superna/linux.git tags/meson-drm-for-4.10 for you to fetch changes up to

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

On 12/06/2016 10:06 AM, Peter Zijlstra wrote: > On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote: >> +++ b/kernel/locking/mutex.c >> @@ -350,7 +350,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock, >> * access and not reliable. >> */ >> static noinline >> -bool

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

On 12/06/2016 01:29 PM, Peter Zijlstra wrote: > On Tue, Dec 06, 2016 at 11:03:28AM -0500, Waiman Long wrote: >> The mutex_spin_on_owner() function was originally marked noinline >> because it could be a major consumer of CPU cycles in a contended lock. >> Having it shown separately in the perf

[RFC 1/5] drm/i915: Give our log messages our name

From: Tvrtko Ursulin Define DRM_NAME to i915 so that the log messages we output change from: [drm] RC6 on to: [i915] RC6 on Since I wasn't around in the beginning of DRM I wonder whether that was the intended purpose of DRM_NAME or if it was something else. Today

[PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote: > 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen : >> On 29/11/16 13:57, Bartosz Golaszewski wrote: >>> Add the dumb-vga-dac node to the board DT together with corresponding >>> ports and vga connector. This allows to retrieve the edid

[RFC 5/5] drm: Do not log driver prefix in debug messages

From: Tvrtko Ursulin Driver prefix is a bit redundant in debug messages. If we choose not to log it we change debug messages which used to look like this: [i915:edp_panel_off [i915]] Wait for panel power off time to this: [edp_panel_off [i915]] Wait for panel power

[RFC 3/5] drm: Respect driver set DRM_NAME in drm_dev_printk

From: Tvrtko Ursulin Same as the previous patch did for drm_printk, allow for the logging macros to pass in the driver set DRM_NAME. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_drv.c | 14 +++--- drivers/gpu/drm/i915/i915_drv.c | 3 ++-

[RFC 2/5] drm: Respect driver set DRM_NAME in drm_printk

From: Tvrtko Ursulin Instead of logging with the DRM core name, pass in the name explicitly in order to allow individual drivers to have all their log messages prefixed with their own name. For instance i915, instead of: [drm:edp_panel_off [i915]] Wait for panel

[PATCH] drm/etnaviv: don't invoke OOM killer from dump code

On Fri, Dec 02, 2016 at 11:44:54AM +0100, Lucas Stach wrote: > The dumper is only a debugging aid so we don't want to invoke the OOM > killer if buffer for the potentially large GPU state can't be vmalloced. > > Signed-off-by: Lucas Stach Acked-by: Russell King

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

Hi Daniel, On 06-12-2016 08:23, Daniel Vetter wrote: > On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote: >> On Mon, Dec 05, 2016 at 02:19:48PM +, Jose Abreu wrote: >>> Hi Thierry, >>> >>> >>> On 05-12-2016 11:14, Thierry Reding wrote: On Mon, Dec 05, 2016 at 11:06:15AM

[RFC 0/5] DRM logging tidy

From: Tvrtko Ursulin I wasn't here at the beginnings of DRM so I might have gotten this wrong, however the existance of DRM_NAME suggested to me that the intention was to allow individual drivers to override it and get appropriate prefixes in their log messages. I

  1   2   >