[PATCH v2.1 2/4] drm/atomic: Add accessor macros for the current state, v2.

On Thu, Nov 17, 2016 at 02:20:10PM +0100, Maarten Lankhorst wrote: > With checks! This will allow safe access to the current state, > while ensuring that the correct locks are held. > > Changes since v1: > - Constify returned states. > - Require plane lock to return plane state, don't allow

[PATCH 5/7] drm: Don't compute obj counts expensively in get_resources

On Fri, Dec 09, 2016 at 09:47:56PM +, Chris Wilson wrote: > On Fri, Dec 09, 2016 at 03:19:42PM +0100, Daniel Vetter wrote: > > Looping when we keep track of this is silly. Only thing we have to > > be careful is with sampling the connector count. To avoid inconsisten > > results due to gcc

[PATCH] dma-buf: Final bits of doc polish

- Put all the remaing bits of the old doc into suitable places in the new sphinx world. - Also document the poll support, we forgot to do that. - Delete dma-buf-sharing.txt. v2: Don't forget to update MAINTAINERS. Cc: linux-doc at vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > And since I failed to make this clear: There's not really a > fundamental > reason ast and cirrus use the dirty tracking for fbdev. It's just that > doing it that way was the fastest way to get those servers booting, and > ever since no

[PATCH] linux/types.h: enable endian checks for all sparse builds

On Fri, Dec 09, 2016 at 03:18:02PM +, Bart Van Assche wrote: > On 12/08/16 22:40, Madhani, Himanshu wrote: > > We’ll take a look and send patches to resolve these warnings. > > Thanks! > > Bart. > Sounds good. I posted what I have so far so that you can start from that. -- MST

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote: > Yeah if you have discrete vram then your dumb display driver isn't all > that pretty. We essentially just have the few drivers Dave hacked up to be > able to boot some servers. And there's definitely lots of room for more > shared code for

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote: > What are people using fbcon for that needs acceleration, this is where I get > a bit lost. > > It's a console, if you aren't sshing into the machine. > > It's main purpose should just be for gathering oopses and you've a lot better > chance

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

.87233.bd56de8-1 * llvm-svn 4.0.0svn_r289147-1 * lib32-llvm-svn 4.0.0svn_r289117-1 -- 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

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

o work. -- 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/20161209/98790937/attachment.html>

[PATCH 7/7] drm: Resurrect atomic rmfb code

On Fri, Dec 09, 2016 at 03:19:44PM +0100, Daniel Vetter wrote: > This was somehow lost between v3 and the merged version in Maarten's > patch merged as: > > commit f2d580b9a8149735cbc4b59c4a8df60173658140 > Author: Maarten Lankhorst > Date: Wed May 4 14:38:26 2016 +0200 > > drm/core: Do

[Intel-gfx] [PATCH 6/7] drm: Don't walk fb list twice in getresources

On Fri, Dec 09, 2016 at 03:19:43PM +0100, Daniel Vetter wrote: > We can be more clever than that and merge the 2 list walking loops. > It's all under the one mutex critical section anyway, so nothing funny > can happen. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_mode_config.c

[PATCH 5/7] drm: Don't compute obj counts expensively in get_resources

On Fri, Dec 09, 2016 at 03:19:42PM +0100, Daniel Vetter wrote: > Looping when we keep track of this is silly. Only thing we have to > be careful is with sampling the connector count. To avoid inconsisten > results due to gcc re-computing this, use READ_ONCE. Later on in the function we take the

[RFC] Using DC in amdgpu for upcoming GPU

On Fri, Dec 9, 2016 at 9:34 PM, Dave Airlie wrote: > I actually love bandwidth_calcs.c I'd like to merge it even before DAL, yes > it's ugly code, and it's horrible but it's a single piece of hw team magic, > and > we can hide that. It's the sw abstraction magic that is my issue. If anyone

[drm-intel:drm-intel-next-queued 1/1] htmldocs: drivers/gpu/drm/i915/i915_drv.h:1106: warning: No description found for parameter 'i915'

ic create & destroy :: TO: Ben Widawsky :: CC: Daniel Vetter --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 6425 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/4b507515/attachment-0001.gz>

[RFC] Using DC in amdgpu for upcoming GPU

Hi Alex, I'll leave the other bits out, just replying to atomic/android comments. On Fri, Dec 9, 2016 at 6:32 PM, Deucher, Alexander wrote: > I understand forward progress on APIs, but frankly from my perspective, > atomic has been a disaster for stability of both atomic and pre-atomic code.

[RFC] Using DC in amdgpu for upcoming GPU

I guess things went a bit sideways by me and Dave only talking about the midlayer, so let me first state that the DC stuff has massively improved through replacing all the backend services that reimplemented Linux helper libraries with their native equivalent. That's some serious work, and it

[Bug 94158] [amdgpu][tonga] GPU randomly gets stuck at 100% load and high clocks

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

[Bug 80419] XCOM: Enemy Unknown Causes lockup

: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/7a49e30b/attachment.html>

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

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

[PATCH 5/5] dma-buf: Final bits of doc polish

- Put all the remaing bits of the old doc into suitable places in the new sphinx world. - Also document the poll support, we forgot to do that. - Delete dma-buf-sharing.txt. Cc: linux-doc at vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter ---

[PATCH 4/5] dma-buf: Update cpu access documentation

- Again move the information relevant for driver writers next to the callbacks. - Put the overview and userspace interface documentation into a DOC: section within the code. - Remove the text that mmap needs to be coherent - since the DMA_BUF_IOCTL_SYNC landed that's no longer the case. But

[PATCH 3/5] dma-buf: Reorganize device dma access docs

- Put the initial overview for dma-buf into dma-buf.rst. - Put all the comments about detailed semantics into the right kernel-doc comment for functions or ops structure member. - To allow that detail, switch the reworked kerneldoc to inline style for dma_buf_ops. - Tie everything together

[PATCH 2/5] dma-buf: Update kerneldoc for sync_file_create

This was missed when adding a dma_fence_get call. While at it also remove the kerneldoc for the static inline helper - no point documenting internals down to every detail. Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating sync_file") Cc: Gustavo Padovan Cc: Sean

[PATCH 1/5] dma-buf: Extract dma-buf.rst

Just prep work to polish and consolidate all the dma-buf related documenation. Unfortunately I didn't discover a way to both integrate this new file into the overall toc while keeping it at the current place. Work around that by moving it into the overall driver-api/index.rst. Cc: linux-doc at

[PATCH 0/5] sphinxification for dma-buf docs

Hi all, Not yet everything in this area, I still want to sprinkle nice docs around all the fence code. Especially some text to explain implicit vs. explicit fencing and how it's all supposed to work. But just cleanup in the dma-buf part was quite a bit of work, and I'd like to get feedback on

[Bug 98239] saints row 3: performance is limited by flushes

is the only thing that can help with that. -- 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/20161209/4393374e/attachment-0001.html>

[Bug 98239] saints row 3: performance is limited by flushes

themselves probably are the bottleneck. -- 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/20161209/30e7c22c/attachment.html>

[Bug 98239] saints row 3: performance is limited by flushes

rrelated to fps -- 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/20161209/9e7ac762/attachment.html>

[PATCH 08/10] drm/etnaviv: make it possible to reconfigure perf counter

Hi Wladimir, 2016-12-09 16:48 GMT+01:00 Wladimir J. van der Laan : > On Fri, Dec 09, 2016 at 12:21:29PM +0100, Christian Gmeiner wrote: >> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c >> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c >> @@ -1379,6 +1379,9 @@ static void

[PATCH 5/9] drm: kselftest for drm_mm and alignment

On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > Check that we can request alignment to any power-of-two or prime using a > plain drm_mm_node_insert(). > > Signed-off-by: Chris Wilson > +static int igt_align(void *ignored) > +{ > + struct drm_mm mm; > + struct drm_mm_node

[RFC] Using DC in amdgpu for upcoming GPU

> Merging this code as well as maintaining a trust relationship with > Linus, also maintains a trust relationship with the Linux graphics > community and other drm contributors. There have been countless > requests from various companies and contributors to merge unsavoury > things over the

[PATCH 8/9] drm: kselftest for drm_mm and top-down alignment

On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > Check that if we request top-down allocation with a particular alignment > from drm_mm_insert_node() that the start of the node matches our > request. > > Signed-off-by: Chris Wilson > @@ -1038,6 +1038,98 @@ static int igt_topdown(void

[git pull] single drm fix

Hi Linus, Just a single fix for amdgpu to just suspend the gpu on "shutdown" instead of shutting it down fully, as for some reason the hw was getting upset in some situations. Dave. The following changes since commit 3e5de27e940d00d8d504dfb96625fb654f641509: Linux 4.9-rc8 (2016-12-04

[RFC] Using DC in amdgpu for upcoming GPU

bbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/fb292101/attachment-0001.html>

[RFC] Using DC in amdgpu for upcoming GPU

> -Original Message- > From: Dave Airlie [mailto:airlied at gmail.com] > Sent: Thursday, December 08, 2016 3:07 PM > To: Daniel Vetter > Cc: Wentland, Harry; dri-devel; Grodzovsky, Andrey; amd-gfx mailing list; > Deucher, Alexander; Cheng, Tony > Subject: Re: [RFC] Using DC in amdgpu for

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

[Resent pull request using an HTTPS github URL] 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: https://github.com/superna/linux.git

[RFC] Using DC in amdgpu for upcoming GPU

> Merging this code as well as maintaining a trust relationship with > Linus, also maintains a trust relationship with the Linux graphics > community and other drm contributors. There have been countless > requests from various companies and contributors to merge unsavoury > things over the

[Bug 95206] Display port bandwidth regression

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

[PATCH v3 4/5] drm: Add definitions for DP compliance Video pattern tests

Jani, I have added the defs for all compliance video pattern test registers as you had commented on previous version of this patch. It also fixes the indentation. Could you please review this patch? Regards Manasi On Fri, Dec 09, 2016 at 04:32:59PM -0800, Manasi Navare wrote: > v2: > * Add

[PATCH] drm: Make each driver's struct_mutex its own subclass

With prime, we are running into false circular dependencies based on the order in which two drivers may lock their own struct_mutex wrt to a common lock (like the reservation->lock). Work around this by adding the lock_class_key to the struct drm_driver such that each driver can have its own

[PATCH 08/10] drm/etnaviv: make it possible to reconfigure perf counter

On Fri, Dec 09, 2016 at 12:21:29PM +0100, Christian Gmeiner wrote: > --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > @@ -1379,6 +1379,9 @@ static void etnaviv_process_readbacks(struct > etnaviv_gpu *gpu, > const u32 val = gpu_read(gpu,

[RESEND x3][PATCH 2/2 v4] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

On 11/28/2016 08:22 PM, John Stultz wrote: > From: Srinivas Kandagatla > > This patch enables the Audio Data and Clock pads to the adv7533 bridge. > Without this patch audio can not be played. > > Cc: David Airlie > Cc: Archit Taneja > Cc: Laurent Pinchart > Cc: Wolfram Sang

[RESEND x3][PATCH 1/2 v4] drm/bridge: adv7511: Add Audio support.

On 11/28/2016 08:22 PM, John Stultz wrote: > This patch adds support to Audio for both adv7511 and adv7533 > bridge chips. > > This patch was originally from [1] by Lars-Peter Clausen > and was adapted by Archit Taneja and > Srinivas Kandagatla . > > Then I heavily reworked it to use the

[PATCH] drm: Kbuild: add omap_drm.h to the installed headers

Hi Tomi, On Friday 09 Dec 2016 16:23:05 Tomi Valkeinen wrote: > On 08/12/16 01:53, Laurent Pinchart wrote: > > The header defines the userspace API exported by the omapdrm driver, > > install it to make the definitions available to userpace. > > > > Signed-off-by: Laurent Pinchart > > --- > >

[PATCH v3 4/5] drm: Add definitions for DP compliance Video pattern tests

v2: * Add all the other DP Complianec TEST register defs (Jani Nikula) Cc: dri-devel at lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by: Manasi Navare --- include/drm/drm_dp_helper.h | 58 + 1 file changed, 58

[PATCH 2/9] drm: kselftest for drm_mm_reserve_node()

On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > Exercise drm_mm_reserve_node(), check that we can't reserve an already > occupied range and that the lists are correct after reserving/removing. > > Signed-off-by: Chris Wilson > --- >  drivers/gpu/drm/drm_mm_selftests.h |   1 + >  

[PATCH 2/7] drm: Protect master->unique with dev->master_mutex

On Fri, Dec 09, 2016 at 02:54:34PM +, Emil Velikov wrote: > On 9 December 2016 at 14:19, Daniel Vetter wrote: > > No one looks at the major/minor versions except the unique/busid > > stuff. If we protect that with the master_mutex (since it also affects > > the unique of each master, oh well)

[RFC] Using DC in amdgpu for upcoming GPU

On Fri, 09 Dec 2016 12:34:17 -0800 Dave Airlie wrote > On 10 December 2016 at 05:59, Daniel Vetter wrote: > > I guess things went a bit sideways by me and Dave only talking about > > the midlayer, so let me first state that the DC stuff has massively > > improved through

[PATCH] drm: Kbuild: add omap_drm.h to the installed headers

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/20161209/5352ac96/attachment.sig>

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

On Mon, Dec 05, 2016 at 01:23:54PM +0530, Archit Taneja wrote: > Add the regulator supply properties needed by ADV7511 and ADV7533. > > Cc: devicetree at vger.kernel.org > Acked-by: Laurent Pinchart > Signed-off-by: Archit Taneja > --- >

[GIT PULL] drm-vc4-next-2016-12-09

I just got the ack on the DT bindings for VEC, so I'd like to get it pulled if we can. If it's too late for 4.10, I'm fine waiting. Adding VEC support should have a low chance of regressions because it doesn't get a mode configured by default. This is due to it reporting unknown connector state

[PATCH 1/9] drm: kselftest for drm_mm_init()

On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > Simple first test to just exercise initialisation of struct drm_mm. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

[PATCH 4/4] drm/vc4: Don't use drm_put_dev

text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/4aea1ec1/attachment.sig>

[RESEND PATCH v2 5/7] drm/vc4: Document VEC DT binding

e URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/86746d63/attachment.sig>

[PATCH] drm: Add fake controlD* symlinks for backwards compat

On Fri, Dec 09, 2016 at 02:56:56PM +0100, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and > totally runs

[PATCH 7/7] drm: Resurrect atomic rmfb code

This was somehow lost between v3 and the merged version in Maarten's patch merged as: commit f2d580b9a8149735cbc4b59c4a8df60173658140 Author: Maarten Lankhorst Date: Wed May 4 14:38:26 2016 +0200 drm/core: Do not preserve framebuffer on rmfb, v4. Actual code copied from Maarten's patch,

[PATCH 6/7] drm: Don't walk fb list twice in getresources

We can be more clever than that and merge the 2 list walking loops. It's all under the one mutex critical section anyway, so nothing funny can happen. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mode_config.c | 28 +++- 1 file changed, 11 insertions(+), 17

[PATCH 5/7] drm: Don't compute obj counts expensively in get_resources

Looping when we keep track of this is silly. Only thing we have to be careful is with sampling the connector count. To avoid inconsisten results due to gcc re-computing this, use READ_ONCE. And to avoid surprising userspace, make sure we don't copy more connectors than planned, and report the

[PATCH 4/7] drm: Enforce BKL-less ioctls for modern drivers

With the last round of changes all ioctls called by modern drivers now have their own locking. Everything else is only allowed for legacy drivers and hence the lack of locking doesn't matter. One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag. But that only works its magic on the

[PATCH 3/7] drm: setclientcap doesn't need the drm BKL

It only updates per-file feature flags. And all the ioctl which change behaviour depending upon these flags (they're all kms features) do _not_ hold the BKL. Therefor this is pure cargo-cult and can be removed. Note that there's a risk that the ioctl will behave inconsistently, but that's ok. The

[PATCH 2/7] drm: Protect master->unique with dev->master_mutex

No one looks at the major/minor versions except the unique/busid stuff. If we protect that with the master_mutex (since it also affects the unique of each master, oh well) we can mark these two IOCTL with DRM_UNLOCKED. While doing this I realized that the comment for the magic_map is outdated,

[PATCH 1/7] drm/hisilicon: Don't set drm_device->platformdev

It's deprecated and only should be used by drivers which still use drm_platform_init, not by anyone else. And indeed it's entirely unused and can be nuked. This required a bit more fudging, but I guess kirin_dc_ops really wants to operate on the platform_device, not something else. Also bonus

[PATCH 1/1] dri: vc4: set error code on failure

-signature Size: 832 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/4debbbf5/attachment.sig>

[PATCH] drm: Add fake controlD* symlinks for backwards compat

Hey On Fri, Dec 9, 2016 at 2:56 PM, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and > totally runs counter to

[PATCH] linux/types.h: enable endian checks for all sparse builds

On 12/08/16 22:40, Madhani, Himanshu wrote: > We’ll take a look and send patches to resolve these warnings. Thanks! Bart.

[GIT PULL] drm/tegra: Changes for v4.10-rc1

Hi Dave, The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.10-rc1 for you to fetch changes up to

[PATCH 07/36] drm/omap: Init fbdev emulation only when we have displays

On Fri, Dec 09, 2016 at 01:13:11PM +0200, Tomi Valkeinen wrote: > On 30/11/16 15:46, Daniel Vetter wrote: > > On Wed, Nov 30, 2016 at 01:17:09PM +0200, Tomi Valkeinen wrote: > >> From: Peter Ujfalusi > >> > >> Do not try to init the fbdev if either num_crtcs or num_connectors is 0. > >> In this

[PATCH 0/2] Generic HDMI codec: Add channel mapping control

Hi, On 12/08/2016 10:13 PM, Takashi Sakamoto wrote: > On Dec 9 2016 05:52, Takashi Sakamoto wrote: >> On Dec 9 2016 01:37, Arnaud Pouliquen wrote: >>> Aim of this patch is to add 'Playback Channel Map' control to export >>> audio capabilities in term of HDMI sink speakers allocation. >>> This

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, Dec 09, 2016 at 02:57:24PM +0100, David Herrmann wrote: > Hey > > On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter wrote: > >> > So it is possible, only reason vram dumb buffers look worse is that > >> > there's > >> > only 3 and no one cares about them, vs about 20 and a very active > >>

[GIT PULL] drm/panel: Changes for v4.10-rc1

Hi Dave, The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.10-rc1 for you to fetch changes up to

[RESEND PATCH v2 5/7] drm/vc4: Document VEC DT binding

On Fri, Dec 02, 2016 at 02:48:11PM +0100, Boris Brezillon wrote: > Document the DT binding for the VEC (Video EnCoder) IP. > > Signed-off-by: Boris Brezillon > --- > Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 14 > ++ > 1 file changed, 14 insertions(+) Acked-by:

[RFC PATCH 0/3] staging: remove fbdev drivers

Hey On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter wrote: >> > So it is possible, only reason vram dumb buffers look worse is that there's >> > only 3 and no one cares about them, vs about 20 and a very active community >> > of contributors (also for core drm improvements) for the other case. >>

[PATCH] drm: Add fake controlD* symlinks for backwards compat

We thought that no userspace is using them, but oops libdrm is using them to figure out whether a driver supports modesetting. Check out drmCheckModesettingSupported but maybe don't because it's horrible and totally runs counter to where we want to go with libdrm device handling. The function

[PATCH 2/7] drm: Protect master->unique with dev->master_mutex

On 9 December 2016 at 14:19, Daniel Vetter wrote: > No one looks at the major/minor versions except the unique/busid > stuff. If we protect that with the master_mutex (since it also affects > the unique of each master, oh well) we can mark these two IOCTL with > DRM_UNLOCKED. > > While doing this

[PATCH] drm: Add fake controlD* symlinks for backwards compat

On Fri, Dec 09, 2016 at 11:57:34AM +0100, David Herrmann wrote: > Hi Greg > > On Fri, Dec 9, 2016 at 11:53 AM, Greg Kroah-Hartman > wrote: > > On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote: > >> We thought that no userspace is using them, but oops libdrm is using > >> them to

[PATCH 2/9] drm: kselftest for drm_mm_reserve_node()

On Fri, Dec 09, 2016 at 04:31:50PM +0200, Joonas Lahtinen wrote: > On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > > +static int igt_reserve(void *ignored) > > +{ > > + int n, ret; > > + > > + for (n = 1; n < 50; n++) { > > The right amount of loops might be something to discuss. The

[PATCH 11/10] drm/etnaviv: HACK: enable debug register

I am not sure how the correct solution should look like. Maybe enable debug registers globally via not existing SET_PARAM ioctl. Signed-off-by: Christian Gmeiner --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git

[PATCH 03/36] drm/omap: add crtc background property

On Fri, Dec 09, 2016 at 01:03:33PM +0200, Tomi Valkeinen wrote: > On 30/11/16 15:32, Daniel Vetter wrote: > > On Wed, Nov 30, 2016 at 01:17:05PM +0200, Tomi Valkeinen wrote: > >> Add DRM property for crtc background color property. Background > >> color is shown on areas where there are no planes.

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, Dec 09, 2016 at 10:48:07PM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > > > And since I failed to make this clear: There's not really a > > fundamental > > reason ast and cirrus use the dirty tracking for fbdev. It's just that > >

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, Dec 09, 2016 at 10:44:16PM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote: > > Yeah if you have discrete vram then your dumb display driver isn't all > > that pretty. We essentially just have the few drivers Dave hacked up to be > > able to

[RFC PATCH 0/3] staging: remove fbdev drivers

Am Freitag, den 09.12.2016, 22:44 +1100 schrieb Benjamin Herrenschmidt: > On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote: > > Yeah if you have discrete vram then your dumb display driver isn't all > > that pretty. We essentially just have the few drivers Dave hacked up to be > > able to

[PATCH 0/5] sphinxification for dma-buf docs

On Fri, 9 Dec 2016 19:53:04 +0100 Daniel Vetter wrote: > Not yet everything in this area, I still want to sprinkle nice docs around all > the fence code. Especially some text to explain implicit vs. explicit fencing > and how it's all supposed to work. > > But just cleanup in the dma-buf part

[Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

On 9 December 2016 at 13:56, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and > totally runs counter to where

[RFC 00/10] implement alternative and much simpler id allocator

On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes wrote: > TL;DR: these patches save 250 KB of memory, with more low-hanging > fruit ready to pick. > > While browsing through the lib/idr.c code, I noticed that the code at > the end of ida_get_new_above() probably doesn't work as intended:

[PATCH v1.5 6/6] arm64: dts: r8a7796: Connect FCP devices to IPMMU

Signed-off-by: Ulrich Hecht --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi index 52e81bb..f5496d4 100644 ---

[PATCH v1.5 5/6] v4l: vsp1: Provide display list and VB2 queue with FCP device

Prevents IPMMU trap during boot on r8a7795/6 Salvator-X boards: ipmmu-vmsa febd.mmu: Unhandled faut: status 0x0101 iova 0x7f09a000 Code by Magnus Damm. Signed-off-by: Ulrich Hecht --- drivers/media/platform/vsp1/vsp1_dl.c| 12 +---

[PATCH v1.5 4/6] drm: rcar-du: Map memory through the VSP device

From: Laurent Pinchart For planes handled by a VSP instance, map the framebuffer memory through the VSP to ensure proper IOMMU handling. Signed-off-by: Laurent Pinchart ---

[PATCH v1.5 3/6] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP

From: Laurent Pinchart The display buffers must be mapped for DMA through the device that performs memory access. Expose an API to map and unmap memory through the VSP device to be used by the DU. Signed-off-by: Laurent Pinchart

[PATCH v1.5 2/6] v4l: rcar-fcp: Add an API to retrieve the FCP device

From: Laurent Pinchart The new rcar_fcp_get_device() function retrieves the struct device related to the FCP device. This is useful to handle DMA mapping through the right device. Signed-off-by: Laurent Pinchart

[PATCH v1.5 1/6] v4l: rcar-fcp: Don't get/put module reference

From: Laurent Pinchart Direct callers of the FCP API hold a reference to the FCP module due to module linkage, there's no need to take another one manually. Take a reference to the device instead to ensure that it won't disappear behind the caller's

[PATCH v1.5 0/6] R-Car DU: Fix IOMMU operation when connected to VSP

Hi! This is a slightly updated version of Laurent's series that adds the fix suggested by Magnus Damm and connects the FCP devices on M3-W to their IPMMU. It also drops the patches that have already been picked up in the media tree. With this series and an assortment of patches from the

[RFC PATCH 0/3] staging: remove fbdev drivers

Hi Ben, On Fri, Dec 9, 2016 at 12:44 PM, Benjamin Herrenschmidt wrote: >> So it is possible, only reason vram dumb buffers look worse is that there's >> only 3 and no one cares about them, vs about 20 and a very active community >> of contributors (also for core drm improvements) for the other

[PATCH V3 3/3] drm: Add new driver for MXSFB controller

Hi Marek, MXSFB can connect with LDB(LVDS display bridge) on i.MX6SX. We have an existing LDB drm driver which works with IPUv3 embedded in i.MX6Q/DL and i.MX53. Do you see a clear picture how all of these stuffs work together? Adding Philipp also. Regards, Liu Ying On Fri, Dec 2, 2016 at

[PATCH 07/36] drm/omap: Init fbdev emulation only when we have displays

on't have any display outputs. Tomi -- 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/20161209/c02e482b/attachment.sig>

[PATCH 9/9] drm: kselftest for drm_mm and color adjustment

Check that after applying the driver's color adjustment, fitting of the node and its alignment are still correct. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 178 + 2 files changed, 179

[PATCH 8/9] drm: kselftest for drm_mm and top-down alignment

Check that if we request top-down allocation with a particular alignment from drm_mm_insert_node() that the start of the node matches our request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 92

[PATCH 7/9] drm: kselftest for drm_mm and top-down allocation

Check that if we request top-down allocation from drm_mm_insert_node() we receive the next available hole from the top. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 96 ++ 2 files changed, 97

[PATCH 6/9] drm: kselftest for drm_mm and eviction

Check that we add arbitrary blocks to the eviction scanner in order to find the first minimal hole that matches our request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 167 + 2 files

[PATCH 5/9] drm: kselftest for drm_mm and alignment

Check that we can request alignment to any power-of-two or prime using a plain drm_mm_node_insert(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 3 + drivers/gpu/drm/test-drm_mm.c | 113 + 2 files changed, 116 insertions(+)

[PATCH 4/9] drm: kselftest for drm_mm_insert_node_in_range()

Exercise drm_mm_insert_node_in_range(), check that we only allocate from the specified range. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 188 + 2 files changed, 189 insertions(+) diff

  1   2   >