Hi Chris
On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson 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
> Cc: David Herrmann
> Cc: dri-de...@lists.freedesktop
Hi Chris
On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson 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
> Cc: David Herrmann
> Cc: dri-de...@lists.freedesktop.org
ing the linear walk is a significant improvement.
>
> v2: Use generic interval-tree template for u64 and faster insertion.
>
> Signed-off-by: Chris Wilson
> Cc: David Herrmann
> Cc: dri-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_mm.c | 133
> +++
ve undefined behaviour. Add a couple of WARNs upon creating the
> drm_mm node to prevent later bugs.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_mm.c | 9 +
> 1 file changed, 9 insertions(+)
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/d
://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c
>
> Cc: Daniel Stone
> Cc: Keith Packard
> Cc: tfh...@err.no
> Signed-off-by: Daniel Vetter
Reviewed-by: David Herrmann
Thanks
David
> ---
> Documentation/gpu/introduction.rst | 11
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 common
> path (that of crea
Hey
On Mon, May 15, 2017 at 1:42 PM, Chris Wilson 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
>> wrote:
>> > Constructing the name takes the majority of the time for a
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), &(dev)->mode_config.encoder_list, head)
>> \
>> + if ((encoder_mask)
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
> Reported-by: Alex Deucher
> Cc:
>
> 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
>> Reported-by: Alex Deucher
>> Cc: Alex Deucher
>> Cc: David Herrmann
>> Cc: Greg Kro
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
> Reported-by: Alex Deucher
> Cc: Alex Deucher
> Cc: Davi
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
> ---
> drivers/gpu/drm/Kconfig| 5 +
> drivers/gpu/drm/Makef
On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann wrote:
> On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
> wrote:
> for (i = 0; i < count; ++i)
> swap(order[i], order[drm_lcg_random(state) % count]);
>
> Much simpler and I cannot see why it wouldn't work.
Hey Chris
On Tue, Dec 13, 2016 at 4:40 PM, Chris Wilson 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
>> wrote:
>> > On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson
>> > wrote
ll time (igt/benchmarks/prime_lookup) - both are dramatic
> improvements over the existing linear lists.
>
> v2: Favour rbtree over rhashtable
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631
> Signed-off-by: Chris Wilson
> Cc: Sean Paul
> C
Hi
On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane M
Hey
On Mon, Mar 21, 2016 at 6:14 PM, Daniel Vetter 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
>> wrote:
>> > Just a bit of wording polish plus mentioning that it
Hi
On Wed, Mar 23, 2016 at 12:56 PM, Chris Wilson 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 linux) user-space can
>> ignore
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.
Thanks
David
___
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 occasionally and in the futu
or 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_mm internal_tree nodes) later on.
Agreed.
Acked-by: David Herrmann
Thanks
David
>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
> Signed-off-by: Daniel Vetter
I&
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
>> - drm_mode_addf
Hi
On Tue, Jan 9, 2018 at 11:20 AM, Daniel Vetter wrote:
> On Wed, Jan 03, 2018 at 11:21:03PM +0100, Noralf Trønnes wrote:
>> From: David Herrmann
>>
>> Rather than doing drm_file allocation/destruction right in the fops, lets
>> provide separate helpers. This decoupl
Hi
On Wed, Mar 8, 2017 at 3:12 PM, Daniel Vetter 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
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h
tput.
>
> Cc: Tomeu Vizoso
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-uapi.rst | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/Documentati
/drm-mm.rst | 2 +-
> drivers/gpu/drm/drm_mm.c | 41 +++--
> include/drm/drm_mm.h | 84
> ++--
> 3 files changed, 89 insertions(+), 38 deletions(-)
I liked the "DRM Roaster" more than the "Roster"!
Reviewed-by: Da
rivers/dma-buf/dma-buf.c | 6 +++---
> include/linux/dma-buf.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 91aff74ed092..ab814aff0a5b 100644
> --- a/
Hi
On Thu, Dec 29, 2016 at 9:48 PM, Daniel Vetter wrote:
> We forgot to clean this up when adding connector refcounting.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 5 -
> 1 file changed, 5 deletions(-)
Patch 1-10 all:
Reviewed-
Hi
On Sun, Jun 16, 2013 at 4:57 PM, 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,
> semanatically the fbdev layer does lots of stupid things (like the
Hi
On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski 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,
>> semanat
Hi
On Mon, Jul 1, 2013 at 10:05 PM, Daniel Vetter wrote:
> When converting to the preallocated drm_mm_node interfaces in
>
> commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d
> Author: Chris Wilson
> Date: Fri Dec 7 20:37:07 2012 +
>
> drm/i915: Preallocate the drm_mm_node prior to manip
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky 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 break a bunch
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky 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 break a bunch
(David)
> Free node, and NULL it in failed create_stolen (David)
> Add back accidentally removed newline (David)
>
> CC:
> CC: David Herrmann
> Signed-off-by: Ben Widawsky
I already suspected that you'd embed drm_mm_node in a follow-up patch
but I am not subscribed to in
Hi
On Wed, Jul 31, 2013 at 2:23 AM, Stéphane Marchesin
wrote:
> Signed-off-by: Stéphane Marchesin
Something like "unused" in the commit message makes "git log
[--oneline]" much more verbose without the need to read the patch.
Apart from that:
Reviewed-by: David Herrma
Hi
On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank
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 do you register only a si
Hi
On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank
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 IDs/names.
>>> That’s the who
Hi
On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank
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 for all kind of prope
Hi
On Mon, May 12, 2014 at 5:28 PM, Daniel Vetter 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
> in userspace
Hi
On Wed, May 14, 2014 at 2:03 AM, Dave Airlie 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 what worried me,
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
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 of a debugfs attribute?
> ---
> drivers/g
Hi
On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
> On 19 May 2014 15:13, David Herrmann wrote:
>> Hi
>>
>> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
>>> Signed-off-by: Thomas Wood
>>
>> The commit-msg lacks any discussion why this c
Hi
On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter 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 wrote:
>> > It was intended as a debug/testing feature to allow tests in
>> > intel-gpu
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
Thanks
David
___
Intel-
ht resurrect it again.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
> Cc: David Herrmann
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Chris Wilson (v1)
> Signed-off
Hi
On Wed, Jun 4, 2014 at 2:20 PM, Jani Nikula wrote:
> On Wed, 04 Jun 2014, David Herrmann 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-co
o me.. so
your change to use "retval" looks fine to me. This is:
Reviewed-by: David Herrmann
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
> index 5077f
)) {
> + if (con_back->con && con_back->con != csw) {
Funny thing is, if you run do_bind_con_driver() on the range first,
you kick out the existing driver and can then unload it regardless
whether the fallback was FLAG_MODULE or not. Therefore, I think that
change is sa
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter 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 driver isn't re
en the vga console is already unregistered - this
> can happen when e.g. reloading i915.ko.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
> Cc: David Herrmann
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fb...@vger.kernel.org
>
Hi
On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter 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 wrote:
>> > A bunch of issues:
>> > - We should not kick out t
| 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
> drivers/staging/imx-drm/imx-drm-core.c| 6 +++---
You even caught imx.. and you removed the EXPORT_SYMBO
Hi
On Thu, May 29, 2014 at 5:57 PM, Thomas Wood 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
> ---
> drivers/gp
Hi
On Thu, May 29, 2014 at 5:57 PM, Thomas Wood wrote:
> Add a file to debugfs for each connector that allows the edid data to be
> overridden.
>
> Signed-off-by: Thomas Wood
> ---
> drivers/gpu/drm/drm_crtc.c | 4 +++
> drivers/gpu/drm/drm_debugfs.c | 56
> ++
Hi
On Tue, Mar 25, 2014 at 3:32 PM, wrote:
> From: Sagar Kamble
>
> v2: Added description for "src-color" and "constant-alpha" property.
>
> Cc: Rob Landley
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: David Herrmann
Hi
On Thu, Mar 27, 2014 at 10:50 AM, wrote:
> From: Sagar Kamble
>
> v2: Added description for "src-color" and "constant-alpha" property.
> [Review by Laurent Pinchart]
>
> v3: Fixed typos. [Review by David Herrmann]
>
> Cc: Rob Landley
plementation of the hotplug alternative.
>
> v2: - Do the check first, irrespective of "bound".
> - Cc dri-devel
Thank god all that will get dropped with CONFIG_FB=n. Anyhow:
Reviewed-by: David Herrmann
Thanks
David
> Cc: dri-de...@lists.freedesktop.org
> Credits-
allocation flags into separate enums
> Make checkpatch happy where logical/easy
>
> v3 by Ben:
> Rebased on top of the many drm_mm changes since the original patches
> Remove ATOMIC from allocator flags (Chris)
> Reverse order of TOPDOWN and BOTTOMUP
CC'ing dri-devel as I'm
Hi
On Wed, Jan 8, 2014 at 7:31 PM, Damien Lespiau 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 drm_device and dev->dev_p
Hi
On Thu, Jan 9, 2014 at 1:11 PM, Damien Lespiau 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() similar to devi
t. 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
> Reviewed-by: David Herrmann
> [tred...@nvidia.com: add drm_crtc
Hi Russel
On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
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 initiali
Hi
On Mon, Jan 13, 2014 at 2:55 PM, Russell King - ARM Linux
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
>> wrote:
>> > On Mon, Jan 13, 2014 at 12
doesn't allocate anything, so looks good:
Reviewed-by: David Herrmann
Thanks
David
> Testcase: igt/gem_fd_exhaustion
> Reported-and-Suggested-by: Linus Torvalds
> Cc: Linus Torvalds
> References:
> http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
&g
drivers
>
> Reported-by: Dave Jones
> Cc: Dave Jones
> Cc: Dave Airlie
> Cc: David Herrmann
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_
Hi
On Thu, Oct 16, 2014 at 3:39 PM, Cheng, Yao 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 "GET_MMAP_OFFSET_IOCTL" need be a
Hi
On Mon, Jun 30, 2014 at 8:59 AM, Chris Wilson 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 ( a4de05268e674
:20:46 2014 +0200
>
> drm/i915: Kick out vga console
>
> Reported-and-tested-by: Ed Tomlinson
> Cc: Chris Wilson
> Cc: David Herrmann
> Signed-off-by: Daniel Vetter
Reviewed-by: David Herrmann
Thanks
David
> ---
> drivers/gpu/drm/i915/i915_dma.c | 5 +++--
>
> 28 48 81 c6 48 80 00 00 e8 80 14 01 00 84 c0 74 bc 49
> RIP [] per_file_stats+0x110/0x160 [i915]
> RSP
>
> Reported-by: "Ursulin, Tvrtko"
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81712
> Signed-off-by: Chris Wilson
> Cc: "Urs
Hi
On Thu, Aug 7, 2014 at 3:04 PM, Chris Wilson wrote:
> Despite the claims of
>
> commit 48ba813701eb14b3008edefef4a0789b328e278c
> Author: David Herrmann
> Date: Tue Jul 22 18:46:09 2014 +0200
>
> drm: drop redundant drm_file->is_master
>
> drm_file-&
Hi
On Wed, Aug 6, 2014 at 9:10 AM, Daniel Vetter 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 in the rmfb ioctl or
Hi
On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering
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 treat this f
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 this. Anyway:
Reviewed-by: David Herrmann
Thanks
David
> /**
> * Copy a
ff 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
> ---
> include/drm/drm_crtc.h | 2 --
> 1 file changed, 2 deletions(-)
Reviewed-by: David Herrmann
Thanks
David
&
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 15:36:00 2015 -0400
>
> drm/i915: enable atomic fb-helper
>
> I'
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
>> Author: Rob Clark
>> Date: Tue Aug 25 15:36:00 2
ne->state->fb;
> + if (new_fb)
> + drm_framebuffer_reference(new_fb);
> + plane->fb = new_fb;
> + plane->crtc = plane->state->crtc;
> +
> + if (plane->old_fb)
>
round 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
Thanks
David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 broken userspace, and the kernel
s are preserved.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_crtc.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
Same as 1/2:
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
-by: Daniel Vetter
I recommend pushing it on your fdo branch to let the kbuild-bots run
it for some tests. But otherwise, looks good to me:
Reviewed-by: David Herrmann
Thanks
David
> ---
> drivers/gpu/drm/Makefile | 3 ++-
> drivers/gpu/drm/drm_agpsupport.c | 4
&g
ature.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: David Herrmann
Thanks
David
> ---
> Documentation/DocBook/drm.tmpl | 1 +
> drivers/gpu/drm/drm_ioctl.c| 76
> ++
> 2 files changed, 55 insertions(+), 22 deletions(-)
>
>
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 for i915 and radeon. The
M lock might deadlock
> -*/
> - if (!(flags & DRM_UNLOCKED)) {
> - DRM_ERROR("Refusing locked ioctl access.\n");
> - return ERR_PTR(-EDEADLK);
> - }
Yeah, just drop that right away, regardless of the core changes. We
have lockdep or WARN_
gt; v4: Rebase on top of render-node support in exynos.
>
> Signed-off-by: Daniel Vetter
With the core-patch fixed:
Reviewed-by: David Herrmann
Maybe, as a followup, you might want to turn all core-ioctls to
include a DRM_GLOBAL_LOCK flag and then drop DRM_UNLOCKED entirely.
This is more e
Hi
On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter wrote:
> They're only used in the drm ioctl table, and there they're excluded
> when AGP support is disabled. So this is just dead code ripe for
> removal.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Davi
't support it, we 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_al
nt the kernel from messing with them. But nowadays we
have kernel drivers which control hand-over and hardware ownership, so
I cannot see why this protection is still needed:
Acked-by: David Herrmann
Thanks
David
> With this patch i915.ko module reloading works again reliably,
> something
Hi
On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson 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 the task of grabbing e
Hi
On Mon, Sep 1, 2014 at 4:19 PM, Chris Wilson 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
>> wrote:
>> > Showing who is the current master is useful for trying to decyphe
Hi
On Fri, Sep 12, 2014 at 5:07 PM, Daniel Vetter 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.
&g
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),
> +
Hi
On Wed, Oct 15, 2014 at 4:14 AM, Cheng, Yao 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,
, one for the gtt map and the other for the cpu map.
Yes, please! (also fine with Jani's concerns)
Reviewed-by: David Herrmann
Thanks
David
> Cc: "Cheng, Yao"
> Cc: David Herrmann
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c | 9 ++
Hi
On Mon, Oct 20, 2014 at 8:37 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> 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 assign these to an idr and use
Hi
On Mon, Oct 20, 2014 at 8:37 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This takes the tiling info from the connector and
> exposes it to userspace, as a blob object in a
> connector property.
>
> The contents of the blob is ABI.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/dr
97 matches
Mail list logo
