Re: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console

Hi On Mon, Jun 30, 2014 at 8:59 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote: On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote: Resend without html krud which causes list to bounce the message. Hi This commit (

Re: [Intel-gfx] [PATCH] drm/i915: Only unbind vgacon, not other console drivers

vga console Reported-and-tested-by: Ed Tomlinson e...@aei.ca Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: David Herrmann dh.herrm...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: David Herrmann dh.herrm...@gmail.com Thanks David --- drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH] drm: Unlink dead file_priv from list of active files first

...@chris-wilson.co.uk Cc: Ursulin, Tvrtko tvrtko.ursu...@intel.com I have the same change in my local drm_file cleanup. This is: Reviewed-by: David Herrmann dh.herrm...@gmail.com Thanks David --- drivers/gpu/drm/drm_fops.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff

Re: [Intel-gfx] [PATCH] drm: Restore drm_file-is_master

Hi On Thu, Aug 7, 2014 at 3:04 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: Despite the claims of commit 48ba813701eb14b3008edefef4a0789b328e278c Author: David Herrmann dh.herrm...@gmail.com Date: Tue Jul 22 18:46:09 2014 +0200 drm: drop redundant drm_file-is_master drm_file

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

Hi On Wed, Aug 6, 2014 at 9:10 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: The current refcounting scheme is that the fb lookup idr also holds a reference. This works out nicely bacause thus far we've always explicitly cleaned up idr entries for framebuffers: - Userspace fbs get removed

Re: [Intel-gfx] [PATCH] drm: Include task-name and master status in debugfs clients info

Hi On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: Showing who is the current master is useful for trying to decypher errors when trying to acquire master (e.g. a race with X taking over from plymouth). By including the process name as well as the pid simplifies

Re: [Intel-gfx] [PATCH] drm: Include task-name and master status in debugfs clients info

Hi On Mon, Sep 1, 2014 at 4:19 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, Sep 01, 2014 at 04:11:43PM +0200, David Herrmann wrote: Hi On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: Showing who is the current master is useful for trying

Re: [Intel-gfx] [PATCH 0/3] fbdev no more!

Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, So I've taken a look again at the locking mess in our fbdev support and cried. Fixing up the console_lock mess around the fbdev notifier will be real work, semanatically the fbdev layer does lots of

Re: [Intel-gfx] [PATCH 0/3] fbdev no more!

Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski l...@amacapital.net wrote: On 06/16/2013 07:57 AM, Daniel Vetter wrote: Hi all, So I've taken a look again at the locking mess in our fbdev support and cried. Fixing up the console_lock mess around the fbdev notifier will be real work,

Re: [Intel-gfx] [PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

Hi On Mon, Jul 1, 2013 at 10:05 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: When converting to the preallocated drm_mm_node interfaces in commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Dec 7 20:37:07 2012 + drm/i915:

Re: [Intel-gfx] [PATCH 1/6] drm: pre allocate node for create_block

Hi On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote: For an upcoming patch where we introduce the i915 VMA, it's ideal to have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated). Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this will

Re: [Intel-gfx] [PATCH 1/6] drm: pre allocate node for create_block

Hi On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote: For an upcoming patch where we introduce the i915 VMA, it's ideal to have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated). Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this will

Re: [Intel-gfx] [PATCH] [v3] drm: pre allocate node for create_block

) Add back accidentally removed newline (David) CC: dri-de...@lists.freedesktop.org CC: David Herrmann dh.herrm...@gmail.com Signed-off-by: Ben Widawsky b...@bwidawsk.net I already suspected that you'd embed drm_mm_node in a follow-up patch but I am not subscribed to intel-gfx so I didn't get

Re: [Intel-gfx] [PATCH 3/3] drm: Remove drm_mode_validate_clocks

-by: David Herrmann dh.herrm...@gmail.com I also did a short grep MODE_CLOCK_RANGE and radeon/i915 tv-helpers are the last users. All others use MODE_BAD. But I guess MODE_CLOCK_RANGE is more verbose so there is no need to remove it. Regards David --- drivers/gpu/drm/drm_modes.c | 37

Re: [Intel-gfx] Design review request: DRM color manager

Hi On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank shashank.sha...@intel.com wrote: Benefits of using color manager: 1. Unique framework for all the color correction properties, across all DRM drivers, across various platforms. 2. Only one set/get call

Re: [Intel-gfx] Design review request: DRM color manager

Hi On Mon, May 12, 2014 at 5:28 PM, Daniel Vetter dan...@ffwll.ch wrote: Those are all just reasons for atomic modeset and maybe an atomic modeget ioctl which transfers the entire blob of things. Maybe we should start with the atomic modeget to get things rolling. Otoh you can always do that

Re: [Intel-gfx] [PATCH 09/10] i915: add DP 1.2 MST support (v0.3)

Hi On Wed, May 14, 2014 at 2:03 AM, Dave Airlie airl...@gmail.com wrote: Since any objects you get with find are only valid under mode_config.mutex, yes some drivers mess this up, but they should be fixed. Didn't know that we have such a rule. Then it's fine, of course. The page-flip code is

Re: [Intel-gfx] [PATCH] drm/sysfs: expose the force connector attribute

Hi On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote: Signed-off-by: Thomas Wood thomas.w...@intel.com The commit-msg lacks any discussion why this change is done. What is the reason to do that? Isn't the kernel-command-line enough? Why is this a regular feature instead

Re: [Intel-gfx] [PATCH] drm/sysfs: expose the force connector attribute

Hi On Mon, May 19, 2014 at 4:41 PM, Thomas Wood thomas.w...@intel.com wrote: On 19 May 2014 15:13, David Herrmann dh.herrm...@gmail.com wrote: Hi On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote: Signed-off-by: Thomas Wood thomas.w...@intel.com The commit-msg lacks

Re: [Intel-gfx] [PATCH] drm/sysfs: expose the force connector attribute

Hi On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote: On Mon, May 19, 2014 at 4:41 PM, Thomas Wood thomas.w...@intel.com wrote: It was intended as a debug/testing feature to allow tests in intel-gpu-tools

Re: [Intel-gfx] [PATCH 0/7] drm drivers: kill drm_get_connector_name() and drm_get_encoder_name()

patch need to wait for radeon and nouveau patches to get merged, obviously. I tried reviewing these, but it doesn't apply on drm-intel-next. Trusting in coccinelle, this is: Acked-by: David Herrmann dh.herrm...@gmail.com Thanks David ___ Intel-gfx mailing

Re: [Intel-gfx] [PATCH] drm/i915: Kick out vga console

. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813 Cc: David Herrmann dh.herrm...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v1) Signed

Re: [Intel-gfx] [PATCH] drm/i915: Kick out vga console

Hi On Wed, Jun 4, 2014 at 2:20 PM, Jani Nikula jani.nik...@linux.intel.com wrote: On Wed, 04 Jun 2014, David Herrmann dh.herrm...@gmail.com wrote: You rely on compiler-optimizations here. dummy_con is not available if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure if dead

Re: [Intel-gfx] [PATCH 3/5] vt: Don't ignore unbind errors in vt_unbind

, which is very backwards to me.. so your change to use retval looks fine to me. This is: Reviewed-by: David Herrmann dh.herrm...@gmail.com Thanks David --- drivers/tty/vt/vt.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c

Re: [Intel-gfx] [PATCH 2/5] vt: Fix up unregistration of vt drivers

Hi On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: A bunch of issues: - We should not kick out the default console (which is tracked in conswitchp), so check for that. - Add better error codes so callers can differentiate between something went wrong and your

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console

unregistered - this can happen when e.g. reloading i915.ko. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813 Cc: David Herrmann dh.herrm...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc

Re: [Intel-gfx] [PATCH 2/5] vt: Fix up unregistration of vt drivers

Hi On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote: Hi On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: A bunch of issues: - We should not kick out the default console (which

Re: [Intel-gfx] [PATCH 1/3] drm: add register and unregister functions for connectors

| 2 +- drivers/staging/imx-drm/imx-drm-core.c| 6 +++--- You even caught imx.. and you removed the EXPORT_SYMBOL. So looks all good to me. I like that refactoring and I don't think we need an ACK from all driver authors. This is: Reviewed-by: David Herrmann dh.herrm...@gmail.com Maybe

Re: [Intel-gfx] [PATCH 2/3] drm/debugfs: add a force file per connector

Hi On Thu, May 29, 2014 at 5:57 PM, Thomas Wood thomas.w...@intel.com wrote: Add a file to debugfs for each connector to enable modification of the force connector attribute. This allows connectors to be enabled or disabled for testing and debugging purposes. Signed-off-by: Thomas Wood

Re: [Intel-gfx] [PATCH 3/3] drm/debugfs: add an edid_override file per connector

Hi On Thu, May 29, 2014 at 5:57 PM, Thomas Wood thomas.w...@intel.com wrote: Add a file to debugfs for each connector that allows the edid data to be overridden. Signed-off-by: Thomas Wood thomas.w...@intel.com --- drivers/gpu/drm/drm_crtc.c | 4 +++ drivers/gpu/drm/drm_debugfs.c

Re: [Intel-gfx] [PATCH 13/19] drm: do not steal the display if we have a master

: Reviewed-by: David Herrmann dh.herrm...@gmail.com Thanks David Cc: dri-de...@lists.freedesktop.org Credits-to: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/drm_fb_helper.c | 6 ++ 1 file changed, 6 insertions(+) diff

Re: [Intel-gfx] [PATCH 46/48] drm: Optionally create mm blocks from top-to-bottom

. Cc: David Herrmann dh.herrm...@gmail.com Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/drm_mm.c| 56 +++-- drivers/gpu/drm/i915/i915_gem.c | 3 +- drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH 4/5] drm: Add support for subclassing struct drm_device

Hi On Wed, Jan 8, 2014 at 7:31 PM, Damien Lespiau damien.lesp...@intel.com wrote: Currently, drivers are expected to allocate private data and attach it to dev_private in struct drm_device. This has the unfortunate property to require driver code to juggle between the pointer to struct

Re: [Intel-gfx] [PATCH 4/5] drm: Add support for subclassing struct drm_device

Hi On Thu, Jan 9, 2014 at 1:11 PM, Damien Lespiau damien.lesp...@intel.com wrote: On Wed, Jan 08, 2014 at 09:26:51PM +0100, Daniel Vetter wrote: So the parent structure is expected to have struct drm_device at offset 0? I'd rather like to see a drm_dev_init() alongside drm_dev_alloc()

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

in the DRM mode_config crtc_list. Rather than having drivers trying to track the position of their CRTCs in the list, expose the code which already exists for calculating the appropriate mask bit for a CRTC. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Reviewed-by: David Herrmann

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

Hi Russel On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote: Does that -1 ever make sense? We don't support mode-object-hotplugging so all drm_crtc objects are known at initialization time. I'd

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

Hi On Mon, Jan 13, 2014 at 2:55 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote: Hi Russel On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 13, 2014 at 12:58:54PM

Re: [Intel-gfx] [PATCH] drm/gem: Always initialize the gem object in object_init

anything, so looks good: Reviewed-by: David Herrmann dh.herrm...@gmail.com Thanks David Testcase: igt/gem_fd_exhaustion Reported-and-Suggested-by: Linus Torvalds torva...@linux-foundation.org Cc: Linus Torvalds torva...@linux-foundation.org References: http://lists.freedesktop.org/archives

Re: [Intel-gfx] [PATCH] drm: Fix use-after-free in the shadow-attache exit code

for shadow attached drivers Reported-by: Dave Jones da...@redhat.com Cc: Dave Jones da...@redhat.com Cc: Dave Airlie airl...@redhat.com Cc: David Herrmann dh.herrm...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/drm_pci.c | 2 +- 1 file changed, 1 insertion

Re: [Intel-gfx] [PATCH v2 4/4] Documentation: drm: describing plane alpha and color blending property

at ffwll.ch Cc: Laurent Pinchart laurent.pinchart+renesas at ideasonboard.com Cc: David Herrmann dh.herrmann at gmail.com Cc: Alex Deucher alexander.deucher at amd.com Cc: Ville Syrjälä ville.syrjala at linux.intel.com Cc: Sagar Kamble sagar.a.kamble at intel.com Cc: Purushothaman, Vijay

Re: [Intel-gfx] [PATCH v3 1/1] Documentation: drm: describing plane alpha and color blending property

Hi On Thu, Mar 27, 2014 at 10:50 AM, sagar.a.kam...@intel.com wrote: From: Sagar Kamble sagar.a.kam...@intel.com v2: Added description for src-color and constant-alpha property. [Review by Laurent Pinchart] v3: Fixed typos. [Review by David Herrmann] Cc: Rob Landley rob

Re: [Intel-gfx] Design review request: DRM color manager

Hi On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank shashank.sha...@intel.com wrote: Gentle reminder Usual approach is to send any proposals as inline plain-text. It's really hard to comment on attachments, especially if it's an MS-office format. Anyhow, some comments on the proposal: 1) Why

Re: [Intel-gfx] Design review request: DRM color manager

Hi On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank shashank.sha...@intel.com wrote: 1) Why do you register only a single property? Why not register a separate property for each color-correction that is available? This way you can drop the property-id and use the high-level DRM-prop

Re: [Intel-gfx] [PATCH] drm: Fixup locking for universal cursor planes

Hi On Fri, Sep 12, 2014 at 5:07 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Bunch of things amiss: - Updating crtc-cursor_x/y was done without any locking. Spotted by David Herrmann. - Dereferencing crtc-cursor-fb was using the wrong lock, should take the crtc lock. - Grabbing _all_

Re: [Intel-gfx] [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392

Hi +static struct drm_ioctl_desc ipvr_gem_ioctls[] = { + DRM_IOCTL_DEF_DRV(IPVR_CONTEXT_CREATE, + ipvr_context_create_ioctl, DRM_UNLOCKED), + DRM_IOCTL_DEF_DRV(IPVR_CONTEXT_DESTROY, + ipvr_context_destroy_ioctl, DRM_UNLOCKED), +

Re: [Intel-gfx] [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392

Hi On Wed, Oct 15, 2014 at 4:14 AM, Cheng, Yao yao.ch...@intel.com wrote: Hi Herrmann -Original Message- From: David Herrmann [mailto:dh.herrm...@gmail.com] Sent: Monday, October 13, 2014 10:27 PM To: Cheng, Yao Cc: Intel Graphics Development; Jiang, Fei; dri-de

Re: [Intel-gfx] [PATCH 2/6] drm: add tile_group support.

Hi On Mon, Oct 20, 2014 at 8:37 AM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com A tile group is an identifier shared by a single monitor, DisplayID topology has 8 bytes we can use for this, just use those for now until something else comes up in the future. We

Re: [Intel-gfx] [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392

Hi On Thu, Oct 16, 2014 at 3:39 PM, Cheng, Yao yao.ch...@intel.com wrote: Accepted :) I will update the patch to implement the mmap interface and remove the legacy MMAP_IOCTL. BTW I didn't see a field to get mmap_offset in struct drm_gem_open, I guess something like a new

Re: [Intel-gfx] drm i915 weirdness with /sys/class/drm/card0*/status

Hi On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 16.06.15 13:47, Daniel Vetter (dan...@ffwll.ch) wrote: But what does that actually mean? should logind ever echo detect itself into the file? Should it follow uevents for the files? How should

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> > > I guess for simpler merge ordering we can just pull this into drm-intel > and patch up the vma manager (just need to drop a lot of code and adjust > the search to use the drm_m

Re: [Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset

) is protected by dev->struct_mutex in i915-gem. > > While at it add a note in the create_mmap_offset kerneldoc that > drivers must release it again. And then I also noticed that > drm_gem_object_release entirely lacks kerneldoc. > > Cc: David Herrmann <dh.herrm...@gmail.co

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

Hi On Tue, Oct 6, 2015 at 1:19 PM, Chris Wilson wrote: > On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote: >> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote: >> > In addition to the last-in/first-out stack for accessing drm_mm nodes, >> > we

Re: [Intel-gfx] [PATCH 06/11] drm: Define a drm_invalid_op ioctl implementation

; > +int drm_invalid_op(struct drm_device *dev, void *data, > + struct drm_file *file_priv) > +{ > + return -EINVAL; > +} > +EXPORT_SYMBOL(drm_invalid_op); > + We could just store ERR_PTR(-EINVAL) in the ioctl-table and make the ioctl-handler handle

Re: [Intel-gfx] [PATCH] drm: Nuke drm_framebuffer->helper_private

puting > stuff from the fourcc value. But that would require some drm-wide > cocci and real justification. > > Cc: gary.k.sm...@intel.com > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > include/drm/drm_crtc.h | 2 -- > 1 file changed, 2 deletions(-)

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Update docs about device instance setup

can keep what we have. >> >> That, of course, doesn't get rid of the midlayer, so perhaps a better >> way forward would be to tell driver writers that they should be doing >> subsystem-level setup between drm_dev_alloc() and drm_dev_register(). > > That's exactly what th

Re: [Intel-gfx] [PATCH 07/11] drm/drm_ioctl.c: kerneldoc

lost the magic > ** signature. > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> Reviewed-by: David Herrmann <dh.herrm...@gmail.com> Thanks David > --- > Documentation/DocBook/drm.tmpl | 1 + > drivers/gpu/drm/drm_ioctl.c| 76 > +

Re: [Intel-gfx] [PATCH 10/11] drm/: Drop DRM_UNLOCKED from modeset drivers

nterface extensions. > > v4: Rebase on top of render-node support in exynos. > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> With the core-patch fixed: Reviewed-by: David Herrmann <dh.herrm...@gmail.com> Maybe, as a followup, you might want to turn all core-i

Re: [Intel-gfx] [PATCH 09/11] drm/vmwgfx: Stop checking for DRM_UNLOCKED

t; -* Taking the drm_global_mutex after the TTM lock might deadlock > -*/ > - if (!(flags & DRM_UNLOCKED)) { > - DRM_ERROR("Refusing locked ioctl access.\n"); > - return ERR_PTR(-EDEADLK); > - } Yeah, just drop that right away, re

Re: [Intel-gfx] [PATCH] drm: Remove __OS_HAS_AGP

ille.syrj...@linux.intel.com> > Reviewed-by: Christian König <christian.koe...@amd.com> (v2) > Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> I recommend pushing it on your fdo branch to let the kbuild-bots run it for some tests. But otherwise, looks goo

Re: [Intel-gfx] [PATCH 11/11] drm: Remove dummy agp ioctl wrappers

;daniel.vet...@intel.com> Reviewed-by: David Herrmann <dh.herrm...@gmail.com> Thanks David > --- > include/drm/drm_agpsupport.h | 48 > > 1 file changed, 48 deletions(-) > > diff --git a/include/drm/drm_agpsupport.h b/include/drm/

Re: [Intel-gfx] [PATCH 08/11] drm: Enforce unlocked ioctl operation for kms driver ioctls

Hi On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter wrote: > With the prep patches for i915 all kms drivers either have > DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns > with an invariant return value when in modeset mode. But that's only > the case

Re: [Intel-gfx] [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

>fb = new_fb; > + plane->crtc = plane->state->crtc; > + > + if (plane->old_fb) > + drm_framebuffer_unreference(plane->old_fb); > + } > +

Re: [Intel-gfx] [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

Hi On Tue, Sep 22, 2015 at 12:33 PM, Maarten Lankhorst wrote: > Hey, > > Op 22-09-15 om 11:55 schreef Daniel Vetter: >> From: Matt Roper >> >> Starting with commit >> >> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d >>

Re: [Intel-gfx] [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

Hi On Tue, Sep 22, 2015 at 11:55 AM, Daniel Vetter wrote: > From: Matt Roper > > Starting with commit > > commit 28cc504e8d52248962f5b485bdc65f539e3fe21d > Author: Rob Clark > Date: Tue Aug 25

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

plash screen, nor the login-manager screen can be left around after they quit and handover to the next stage. We have to stay around for hand-over, which is nasty and requires a back-channel which is otherwise not needed at all. Reviewed-by: David Herrmann <dh.herrm...@gmail.com>

Re: [Intel-gfx] [PATCH 2/2] drm/core: Preserve the fb id on close.

nitial framebuffer, except all > planes are preserved. > > Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > --- > drivers/gpu/drm/drm_crtc.c | 11 +-- > 1 file changed, 1 insertion(+), 10 deletions(-) Same as 1/2: Reviewed-by: David Herrmann <

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

Hi On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin wrote: > On 09/10/2015 10:56 AM, Daniel Vetter wrote: >> That's not different from the compositor just freezing instead of >> crashing: Screen contents stays on and nothing happens. Imo this really is >> all just

Re: [Intel-gfx] [PATCH 4/9] drm/core: Add drm_for_each_encoder_mask.

Hi On Tue, Nov 24, 2015 at 7:00 PM, Jani Nikula wrote: > On Tue, 24 Nov 2015, Maarten Lankhorst > wrote: >> +#define drm_for_each_encoder_mask(encoder, dev, encoder_mask) \ >> + list_for_each_entry((encoder),

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

Hey On Mon, Mar 21, 2016 at 6:14 PM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Mon, Mar 21, 2016 at 01:26:58PM +0100, David Herrmann wrote: >> Hi >> >> On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter <daniel.vet...@ffwll.ch> >> wrote: >> &

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

ilson.co.uk> > Cc: Tiago Vignatti <tiago.vigna...@intel.com> > Cc: Stéphane Marchesin <marc...@chromium.org> > Cc: David Herrmann <dh.herrm...@gmail.com> > Cc: Sumit Semwal <sumit.sem...@linaro.org> > Cc: Daniel Vetter <daniel.vet...@intel.com> > C

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

Hi On Wed, Mar 23, 2016 at 12:56 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > On Wed, Mar 23, 2016 at 12:30:42PM +0100, David Herrmann wrote: >> My question was rather about why we do this? Semantics for EINTR are >> well defined, and with SA_RESTART (default on

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

Hi On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti wrote: > Do we have an agreement here after all? David? I need to know whether this > fixup is okay to go cause I'll need to submit to Chrome OS then. Sure it is fine. The code is already there, we cannot change it.

Re: [Intel-gfx] [PATCH 3/3] drm: Skip initialising the drm_mm_node->hole_stack

Hi Chris On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > As we always add this to the drm_mm->hole_stack as our first operation, > we do not need to initialise the list node. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> >

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

. For future i915 > patches, eliminating the linear walk is a significant improvement. > > v2: Use generic interval-tree template for u64 and faster insertion. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: David Herrmann <dh.herrm...@gmail.com> > Cc: dri-d

Re: [Intel-gfx] [PATCH 2/3] drm: Convert drm_vma_manager to embedded interval-tree in drm_mm

Hi Chris On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > Having added an interval-tree to struct drm_mm, we can replace the > auxiliary rb-tree inside the drm_vma_manager with it. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk&

Re: [Intel-gfx] [PATCH] drm: Declare that create drm_mm nodes with size 0 is illegal

node with size > 0 will have undefined behaviour. Add a couple of WARNs upon creating the > drm_mm node to prevent later bugs. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > --- > drivers/gpu/drm/drm_mm.c | 9 + > 1 file changed, 9 insertions

Re: [Intel-gfx] [PATCH] drm: Convert prime dma-buf <-> handle to rbtree

hris-wilson.co.uk> > Cc: Sean Paul <seanp...@chromium.org> > Cc: David Herrmann <dh.herrm...@gmail.com> > --- > drivers/gpu/drm/drm_prime.c | 85 > +++-- > include/drm/drmP.h | 5 +-- > 2 files changed, 77 ins

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

gt; > In debugfs? This patch seems to be for sysfs. Yes, typo. It is meant to be sysfs. >> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") >> Cc: Dave Airlie <airl...@gmail.com> >> Reported-by: Alex Deucher <alexander.deuc...@amd.com> >&

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

t; Oh well, we need to keep it working, and the simplest way is to add a > symlink at the right place in debugfs from controlD* to card*. > > Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") > Cc: Dave Airlie <airl...@gmail.com> > Reported-by: Alex Deucher <alexander.deu

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

h what's been there (David) > - Add a comment what exactly userspace minimally needs. > - Correct the analysis for -intel (Chris). > > Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") > Cc: Dave Airlie <airl...@gmail.com> > Reported-by: Alex Deucher <alexander.deuc

Re: [Intel-gfx] [PATCH 06/34] drm: Add a simple linear congruent generator PRNG

On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann <dh.herrm...@gmail.com> wrote: > On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > for (i = 0; i < count; ++i) > swap(order[i], order[drm_lcg_random(state) % count]); > >

Re: [Intel-gfx] [PATCH 06/34] drm: Add a simple linear congruent generator PRNG

Hey Chris On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson wrote: > For testing, we want a reproducible PRNG, a plain linear congruent > generator is suitable for our very limited selftests. > > Signed-off-by: Chris Wilson > --- >

Re: [Intel-gfx] [PATCH 06/34] drm: Add a simple linear congruent generator PRNG

Hey Chris On Tue, Dec 13, 2016 at 4:40 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > On Tue, Dec 13, 2016 at 04:18:35PM +0100, David Herrmann wrote: >> On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann <dh.herrm...@gmail.com> >> wrote: >> > On Mon, Dec 12

Re: [Intel-gfx] [PATCH 04/17] dma-buf: use preferred struct reference in kernel-doc

<ch...@chris-wilson.co.uk> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > drivers/dma-buf/dma-buf.c | 6 +++--- > include/linux/dma-buf.h | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) Reviewed-by: David Herrmann <dh.herrm...@gmail.com> Th

Re: [Intel-gfx] [PATCH 10/17] drm/atomic-helpers: Remove outdated comment

; 1 file changed, 5 deletions(-) Patch 1-10 all: Reviewed-by: David Herrmann <dh.herrm...@gmail.com> Thanks David > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 8eab8944c736..5e5224460042 100644 > --- a/drivers/gpu

Re: [Intel-gfx] [PATCH 01/17] drm/docs: Small cleanup in drm-uapi.rst

g for prettier output. > > Cc: Tomeu Vizoso <tomeu.viz...@collabora.com> > Cc: Jani Nikula <jani.nik...@intel.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > Documentation/gpu/drm-uapi.rst | 25 +++-- > 1 file ch

Re: [Intel-gfx] [PATCH 03/17] drm/mm: Some doc polish

ons(+), 38 deletions(-) I liked the "DRM Roaster" more than the "Roster"! Reviewed-by: David Herrmann <dh.herrm...@gmail.com> Thanks David > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst > index cb5daffcd6be..5355e5ad51a7 100644 >

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone <dani...@collabora.com> > Cc: Keith Packard <kei...@keithp.com> > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> Reviewe

Re: [Intel-gfx] [PATCH 08/24] drm: Remove DRM_MINOR_CNT

Hi On Wed, Mar 8, 2017 at 3:12 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: > This was originally added by David Herrmann for range checks, but > entirely unused. It confused me, so let's remove it. > > Cc: David Herrmann <dh.herrm...@gmail.com> > Signed-off-by

Re: [Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

Hey On Mon, May 15, 2017 at 12:10 PM, Chris Wilson wrote: > Constructing the name takes the majority of the time for allocating a > sync_file to wrap a fence, and the name is very rarely used (only via > the sync_file status user interface). To reduce the impact on the

Re: [Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

Hey On Mon, May 15, 2017 at 1:42 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > On Mon, May 15, 2017 at 12:50:04PM +0200, David Herrmann wrote: >> Hey >> >> On Mon, May 15, 2017 at 12:10 PM, Chris Wilson <ch...@chris-wilson.co.uk> >> wrote: >&g

Re: [Intel-gfx] [RFC v2 3/8] drm: Export some ioctl functions

Hi On Tue, Jan 9, 2018 at 11:16 AM, Daniel Vetter wrote: > On Wed, Jan 03, 2018 at 11:21:05PM +0100, Noralf Trønnes wrote: >> Export the following functions so in-kernel users can allocate >> dumb buffers: >> - drm_file_alloc >> - drm_file_free >> - drm_prime_handle_to_fd_ioctl

Re: [Intel-gfx] [RFC v2 1/8] drm: provide management functions for drm_file

Hi On Tue, Jan 9, 2018 at 11:20 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Wed, Jan 03, 2018 at 11:21:03PM +0100, Noralf Trønnes wrote: >> From: David Herrmann <dh.herrm...@gmail.com> >> >> Rather than doing drm_file allocation/destruction right in the fops,