Re: linux-next: build failure after merge of the drm-misc tree

[Maarten Lankhorst]

Op 2021-02-10 om 04:11 schreef Stephen Rothwell:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/v3d/v3d_sched.c:263:1: error: return type is an incomplete 
> type
>   263 | v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job 
> *sched_job)
>   | ^
> drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_gpu_reset_for_timeout':
> drivers/gpu/drm/v3d/v3d_sched.c:289:9: error: 'return' with a value, in 
> function returning void [-Werror=return-type]
>   289 |  return DRM_GPU_SCHED_STAT_NOMINAL;
>   | ^~
> drivers/gpu/drm/v3d/v3d_sched.c:263:1: note: declared here
>   263 | v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job 
> *sched_job)
>   | ^
> drivers/gpu/drm/v3d/v3d_sched.c: At top level:
> drivers/gpu/drm/v3d/v3d_sched.c:298:1: error: return type is an incomplete 
> type
>   298 | v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
>   | ^~~
> drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_cl_job_timedout':
> drivers/gpu/drm/v3d/v3d_sched.c:309:10: error: 'return' with a value, in 
> function returning void [-Werror=return-type]
>   309 |   return DRM_GPU_SCHED_STAT_NOMINAL;
>   |  ^~
> drivers/gpu/drm/v3d/v3d_sched.c:298:1: note: declared here
>   298 | v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
>   | ^~~
> drivers/gpu/drm/v3d/v3d_sched.c: At top level:
> drivers/gpu/drm/v3d/v3d_sched.c:316:1: error: return type is an incomplete 
> type
>   316 | v3d_bin_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:325:1: error: return type is an incomplete 
> type
>   325 | v3d_render_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~
> drivers/gpu/drm/v3d/v3d_sched.c:334:1: error: return type is an incomplete 
> type
>   334 | v3d_generic_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:342:1: error: return type is an incomplete 
> type
>   342 | v3d_csd_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_csd_job_timedout':
> drivers/gpu/drm/v3d/v3d_sched.c:353:10: error: 'return' with a value, in 
> function returning void [-Werror=return-type]
>   353 |   return DRM_GPU_SCHED_STAT_NOMINAL;
>   |  ^~
> drivers/gpu/drm/v3d/v3d_sched.c:342:1: note: declared here
>   342 | v3d_csd_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c: At top level:
> drivers/gpu/drm/v3d/v3d_sched.c:362:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   362 |  .timedout_job = v3d_bin_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:362:18: note: (near initialization for 
> 'v3d_bin_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:369:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   369 |  .timedout_job = v3d_render_job_timedout,
>   |  ^~~
> drivers/gpu/drm/v3d/v3d_sched.c:369:18: note: (near initialization for 
> 'v3d_render_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:376:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   376 |  .timedout_job = v3d_generic_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:376:18: note: (near initialization for 
> 'v3d_tfu_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:383:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   383 |  .timedout_job = v3d_csd_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:383:18: note: (near initialization for 
> 'v3d_csd_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:390:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   390 |  .timedout_job = v3d_generic_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:390:18: note: (near 

Re: [PATCH] dma-fence: basic lockdep annotations

[Maarten Lankhorst]

yone. Automatically annotating all
>   dma_fence_signal() calls would hence cause false positives.
>
> - cross-release had some educated guesses for when a critical section
>   starts, like fresh syscall or fresh work callback. This would again
>   cause false positives without explicit annotations, since for
>   dma_fence the critical sections only starts when we publish a fence.
>
> - Furthermore there can be cases where a thread never does a
>   dma_fence_signal, but is still critical for reaching completion of
>   fences. One example would be a scheduler kthread which picks up jobs
>   and pushes them into hardware, where the interrupt handler or
>   another completion thread calls dma_fence_signal(). But if the
>   scheduler thread hangs, then all the fences hang, hence we need to
>   manually annotate it. cross-release aimed to solve this by chaining
>   cross-release dependencies, but the dependency from scheduler thread
>   to the completion interrupt handler goes through hw where
>   cross-release code can't observe it.
>
> In short, without manual annotations and careful review of the start
> and end of critical sections, cross-relese dependency tracking doesn't
> work. We need explicit annotations.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> v3: Kerneldoc.
>
> v4: Some spelling fixes from Mika
>
> v5: Amend commit message to explain in detail why cross-release isn't
> the solution.
>
> Cc: Mika Kuoppala 
> Cc: Thomas Hellstrom 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/driver-api/dma-buf.rst |  12 +-
>  drivers/dma-buf/dma-fence.c  | 161 +++
>  include/linux/dma-fence.h|  12 ++
>  3 files changed, 182 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/driver-api/dma-buf.rst 
> b/Documentation/driver-api/dma-buf.rst
> index 63dec76d1d8d..05d856131140 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -100,11 +100,11 @@ CPU Access to DMA Buffer Objects
>  .. kernel-doc:: drivers/dma-buf/dma-buf.c
> :doc: cpu access
>  
> -Fence Poll Support
> -~~
> +Implicit Fence Poll Support
> +~~~
>  
>  .. kernel-doc:: drivers/dma-buf/dma-buf.c
> -   :doc: fence polling
> +   :doc: implicit fence polling
>  
>  Kernel Functions and Structures Reference
>  ~
> @@ -133,6 +133,12 @@ DMA Fences
>  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> :doc: DMA fences overview
>  
> +DMA Fence Signalling Annotations
> +
> +
> +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> +   :doc: fence signalling annotation
> +
>  DMA Fences Functions Reference
>  ~~
>  
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 656e9ac2d028..0005bc002529 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,160 @@ u64 dma_fence_context_alloc(unsigned num)
>  }
>  EXPORT_SYMBOL(dma_fence_context_alloc);
>  
> +/**
> + * DOC: fence signalling annotation
> + *
> + * Proving correctness of all the kernel code around _fence through code
> + * review and testing is tricky for a few reasons:
> + *
> + * * It is a cross-driver contract, and therefore all drivers must follow the
> + *   same rules for lock nesting order, calling contexts for various 
> functions
> + *   and anything else significant for in-kernel interfaces. But it is also
> + *   impossible to test all drivers in a single machine, hence brute-force N 
> vs.
> + *   N testing of all combinations is impossible. Even just limiting to the
> + *   possible combinations is infeasible.
> + *
> + * * There is an enormous amount of driver code involved. For render drivers
> + *   there's the tail of command submission, after fences are published,
> + *   scheduler code, interrupt and workers to process job completion,
> + *   and timeout, gpu reset and gpu hang recovery code. Plus for integration
> + *   with core mm with have _notifier, respectively 
> _interval_notifier,
> + *   and  For modesetting drivers there's the commit tail functions
> + *   between when fences for an atomic modeset are published, and when the
> + *   corresponding vblank completes, including any interrupt processing and
&g

Re: [RFC 01/17] dma-fence: add might_sleep annotation to _wait()

[Maarten Lankhorst]

Op 12-05-2020 om 11:08 schreef Christian König:
> Am 12.05.20 um 10:59 schrieb Daniel Vetter:
>> But only for non-zero timeout, to avoid false positives.
>>
>> One question here is whether the might_sleep should be unconditional,
>> or only for real timeouts. I'm not sure, so went with the more
>> defensive option. But in the interest of locking down the cross-driver
>> dma_fence rules we might want to be more aggressive.
>>
>> Cc: linux-me...@vger.kernel.org
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: linux-r...@vger.kernel.org
>> Cc: amd-...@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: Chris Wilson 
>> Cc: Maarten Lankhorst 
>> Cc: Christian König 
>> Signed-off-by: Daniel Vetter 
>> ---
>>   drivers/dma-buf/dma-fence.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 052a41e2451c..6802125349fb 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -208,6 +208,9 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool 
>> intr, signed long timeout)
>>   if (WARN_ON(timeout < 0))
>>   return -EINVAL;
>>   +    if (timeout > 0)
>> +    might_sleep();
>> +
>
> I would rather like to see might_sleep() called here all the time even with 
> timeout==0.
>
> IIRC I removed the code in TTM abusing this in atomic context quite a while 
> ago, but could be that some leaked in again or it is called in atomic context 
> elsewhere as well. 


Same, glad I'm not the only one who wants it. :)

~Maarten

Re: [RFC 02/17] dma-fence: basic lockdep annotations

[Maarten Lankhorst]

Op 12-05-2020 om 10:59 schreef Daniel Vetter:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
>   this explicit annotation can be more liberally sprinkled around.
>   With read locks lockdep isn't going to complain if the read-side
>   isn't nested the same way under all circumstances, so ABBA deadlocks
>   are ok. Which they are, since this is an annotation only.
>
> - We're using non-recursive lockdep read lock mode, since in recursive
>   read lock mode lockdep does not catch read side hazards. And we
>   _very_ much want read side hazards to be caught. For full details of
>   this limitation see
>
>   commit e91498589746065e3ae95d9a00b068e525eec34f
>   Author: Peter Zijlstra 
>   Date:   Wed Aug 23 13:13:11 2017 +0200
>
>   locking/lockdep/selftests: Add mixed read-write ABBA tests
>
> - To allow nesting of the read-side explicit annotations we explicitly
>   keep track of the nesting. lock_is_held() allows us to do that.
>
> - The wait-side annotation is a write lock, and entirely done within
>   dma_fence_wait() for everyone by default.
>
> - To be able to freely annotate helper functions I want to make it ok
>   to call dma_fence_begin/end_signalling from soft/hardirq context.
>   First attempt was using the hardirq locking context for the write
>   side in lockdep, but this forces all normal spinlocks nested within
>   dma_fence_begin/end_signalling to be spinlocks. That bollocks.
>
>   The approach now is to simple check in_atomic(), and for these cases
>   entirely rely on the might_sleep() check in dma_fence_wait(). That
>   will catch any wrong nesting against spinlocks from soft/hardirq
>   contexts.
>
> The idea here is that every code path that's critical for eventually
> signalling a dma_fence should be annotated with
> dma_fence_begin/end_signalling. The annotation ideally starts right
> after a dma_fence is published (added to a dma_resv, exposed as a
> sync_file fd, attached to a drm_syncobj fd, or anything else that
> makes the dma_fence visible to other kernel threads), up to and
> including the dma_fence_wait(). Examples are irq handlers, the
> scheduler rt threads, the tail of execbuf (after the corresponding
> fences are visible), any workers that end up signalling dma_fences and
> really anything else. Not annotated should be code paths that only
> complete fences opportunistically as the gpu progresses, like e.g.
> shrinker/eviction code.
>
> The main class of deadlocks this is supposed to catch are:
>
> Thread A:
>
>   mutex_lock(A);
>   mutex_unlock(A);
>
>   dma_fence_signal();
>
> Thread B:
>
>   mutex_lock(A);
>   dma_fence_wait();
>   mutex_unlock(A);
>
> Thread B is blocked on A signalling the fence, but A never gets around
> to that because it cannot acquire the lock A.
>
> Note that dma_fence_wait() is allowed to be nested within
> dma_fence_begin/end_signalling sections. To allow this to happen the
> read lock needs to be upgraded to a write lock, which means that any
> other lock is acquired between the dma_fence_begin_signalling() call and
> the call to dma_fence_wait(), and still held, this will result in an
> immediate lockdep complaint. The only other option would be to not
> annotate such calls, defeating the point. Therefore these annotations
> cannot be sprinkled over the code entirely mindless to avoid false
> positives.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 
> ---

This is something we definitely need, all drivers need to follow the same 
rules, in order to put some light in the darkness. :)

Reviewed-by: Maarten Lankhorst 

>  drivers/dma-buf/dma-fence.c | 53 +
>  include/linux/dma-fence.h   | 12 +
>  2 files changed, 65 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 6802125349fb..d5c0fd2efc70 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
>  }
>  EXPORT_SYMBOL(dma_fence_context_alloc);
>  
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map   dma_fence_lockdep_map = {
> + .name = "dma_fence_map"
> +};
> +
> +bool dma_fence_begin_signalling(void)

Re: [PATCH 1/3] drm: Add some new format DRM_FORMAT_NVXX_10

[Maarten Lankhorst]

Op 25-09-2019 om 10:32 schreef sandy.huang:
>
> 在 2019/9/25 下午4:17, Maarten Lankhorst 写道:
>> Op 25-09-2019 om 10:06 schreef Sandy Huang:
>>> These new format is supported by some rockchip socs:
>>>
>>> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
>>> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
>>> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
>>>
>>> Signed-off-by: Sandy Huang 
>>> ---
>>>   drivers/gpu/drm/drm_fourcc.c  | 18 ++
>>>   include/uapi/drm/drm_fourcc.h | 14 ++
>>>   2 files changed, 32 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>>> index c630064..f25fa81 100644
>>> --- a/drivers/gpu/drm/drm_fourcc.c
>>> +++ b/drivers/gpu/drm/drm_fourcc.c
>>> @@ -274,6 +274,24 @@ const struct drm_format_info *__drm_format_info(u32 
>>> format)
>>>   { .format = DRM_FORMAT_YUV420_10BIT,    .depth = 0,
>>>     .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
>>>     .is_yuv = true },
>>> +    { .format = DRM_FORMAT_NV12_10,    .depth = 0,
>>> +  .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
>>> +  .is_yuv = true },
>>> +    { .format = DRM_FORMAT_NV21_10,    .depth = 0,
>>> +  .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
>>> +  .is_yuv = true },
>>> +    { .format = DRM_FORMAT_NV16_10,    .depth = 0,
>>> +  .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 1,
>>> +  .is_yuv = true },
>>> +    { .format = DRM_FORMAT_NV61_10,    .depth = 0,
>>> +  .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 1,
>>> +  .is_yuv = true },
>>> +    { .format = DRM_FORMAT_NV24_10,    .depth = 0,
>>> +  .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 1, .vsub = 1,
>>> +  .is_yuv = true },
>>> +    { .format = DRM_FORMAT_NV42_10,    .depth = 0,
>>> +  .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 1, .vsub = 1,
>>> +  .is_yuv = true },
>>>   };
>>>     unsigned int i;
>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>> index 3feeaa3..0479f47 100644
>>> --- a/include/uapi/drm/drm_fourcc.h
>>> +++ b/include/uapi/drm/drm_fourcc.h
>>> @@ -238,6 +238,20 @@ extern "C" {
>>>   #define DRM_FORMAT_NV42    fourcc_code('N', 'V', '4', '2') /* 
>>> non-subsampled Cb:Cr plane */
>>>     /*
>>> + * 2 plane YCbCr 10bit
>>> + * index 0 = Y plane, [9:0] Y
>>> + * index 1 = Cr:Cb plane, [19:0]
>>> + * or
>>> + * index 1 = Cb:Cr plane, [19:0]
>>> + */
>>> +#define DRM_FORMAT_NV12_10    fourcc_code('N', 'A', '1', '2') /* 2x2 
>>> subsampled Cr:Cb plane */
>>> +#define DRM_FORMAT_NV21_10    fourcc_code('N', 'A', '2', '1') /* 2x2 
>>> subsampled Cb:Cr plane */
>>> +#define DRM_FORMAT_NV16_10    fourcc_code('N', 'A', '1', '6') /* 2x1 
>>> subsampled Cr:Cb plane */
>>> +#define DRM_FORMAT_NV61_10    fourcc_code('N', 'A', '6', '1') /* 2x1 
>>> subsampled Cb:Cr plane */
>>> +#define DRM_FORMAT_NV24_10    fourcc_code('N', 'A', '2', '4') /* 
>>> non-subsampled Cr:Cb plane */
>>> +#define DRM_FORMAT_NV42_10    fourcc_code('N', 'A', '4', '2') /* 
>>> non-subsampled Cb:Cr plane */
>>> +
>>> +/*
>>>    * 2 plane YCbCr MSB aligned
>>>    * index 0 = Y plane, [15:0] Y:x [10:6] little endian
>>>    * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
>> What are the other bits, they are not mentioned?
>
> It's compact layout
>
> Yplane:
>
>     Y0[9:0]Y1[9:0]Y2[9:0]Y3[9:0]...
>
> UVplane:
>
>     U0[9:0]V0[9:0]U1[9:0]V1[9:0]... 

This should be put in the comment then, for clarity. :) Probably needs 4 pixels 
to describe how it fits in 5 (or 10 for cbcr) bytes.

Cheers,

Maarten

Re: [PATCH 32/33] fbcon: Document what I learned about fbcon locking

[Maarten Lankhorst]

Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> It's not pretty.
>
> Signed-off-by: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Hans de Goede 
> Cc: Yisheng Xie 
> ---
>  drivers/video/fbdev/core/fbcon.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c 
> b/drivers/video/fbdev/core/fbcon.c
> index b40b56702c61..cbbcf7a795f2 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -87,6 +87,25 @@
>  #  define DPRINTK(fmt, args...)
>  #endif
>  
> +/*
> + * FIXME: Locking
> + *
> + * - fbcon state itself is protected by the console_lock, and the code does a
> + *   pretty good job at making sure that lock is held everywhere it's needed.
> + *
> + * - access to the registered_fb array is entirely unprotected. This should 
> use
> + *   proper object lifetime handling, i.e. get/put_fb_info. This also means
> + *   switching from indices to proper pointers for fb_info everywhere.
> + *
> + * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> + *   means concurrent access to the same fbdev from both fbcon and userspace
> + *   will blow up. To fix this all fbcon calls from fbmem.c need to be moved 
> out
> + *   of fb_lock/unlock protected sections, since otherwise we'll recurse and
> + *   deadlock eventually. Aside: Due to these deadlock issues the fbdev code 
> in
> + *   fbmem.c cannot use locking asserts, and there's lots of callers which 
> get
> + *   the rules wrong, e.g. fbsysfs.c entirely missed fb_lock/unlock calls 
> too.
> + */
> +
>  enum {
>   FBCON_LOGO_CANSHOW  = -1,   /* the logo can be shown */
>   FBCON_LOGO_DRAW = -2,   /* draw the logo to a console */

I did a casual review, so for whole series with the small nitpicks I had, and 
any feedback by others, kbuild and the arm mess being fixed up:

Reviewed-by: Maarten Lankhorst 

However, according to reviewer's statement of oversight:

While I have reviewed the patch and believe it to be sound, I do not (unless 
explicitly stated elsewhere)
make any warranties or guarantees that it will achieve its stated purpose or 
function properly in any given situation.

:)

~Maarten

Re: [PATCH 19/33] fbdev: unify unlink_framebufer paths

[Maarten Lankhorst]

^Typo in subject.

Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> For some reasons the pm_vt_switch_unregister call was missing from the
> direct unregister_framebuffer path. Fix this.
>
> v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
> called already. I botched that in v1. Make this all clearer by
> inlining __unlink_framebuffer.
>
> Signed-off-by: Daniel Vetter 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Daniel Vetter 
> Cc: "Michał Mirosław" 
> Cc: Peter Rosin 
> Cc: Hans de Goede 
> Cc: Mikulas Patocka 
> ---
>  drivers/video/fbdev/core/fbmem.c | 47 ++--
>  1 file changed, 20 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index 032506576aa0..f059b0b1a030 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1714,15 +1714,30 @@ static void unbind_console(struct fb_info *fb_info)
>   console_unlock();
>  }
>  
> -static void __unlink_framebuffer(struct fb_info *fb_info);
> -
> -static void do_unregister_framebuffer(struct fb_info *fb_info)
> +void unlink_framebuffer(struct fb_info *fb_info)
>  {
> - unbind_console(fb_info);
> + int i;
> +
> + i = fb_info->node;
> + if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> + return;
> +
> + if (!fb_info->dev)
> + return;
> +
> + device_destroy(fb_class, MKDEV(FB_MAJOR, i));
>  
>   pm_vt_switch_unregister(fb_info->dev);
>  
> - __unlink_framebuffer(fb_info);
> + unbind_console(fb_info);
> +
> + fb_info->dev = NULL;
> +}
> +EXPORT_SYMBOL(unlink_framebuffer);
> +
> +static void do_unregister_framebuffer(struct fb_info *fb_info)
> +{
> + unlink_framebuffer(fb_info);
>   if (fb_info->pixmap.addr &&
>   (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
>   kfree(fb_info->pixmap.addr);
> @@ -1738,28 +1753,6 @@ static void do_unregister_framebuffer(struct fb_info 
> *fb_info)
>   put_fb_info(fb_info);
>  }
>  
> -static void __unlink_framebuffer(struct fb_info *fb_info)
> -{
> - int i;
> -
> - i = fb_info->node;
> - if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> - return;
> -
> - if (fb_info->dev) {
> - device_destroy(fb_class, MKDEV(FB_MAJOR, i));
> - fb_info->dev = NULL;
> - }
> -}
> -
> -void unlink_framebuffer(struct fb_info *fb_info)
> -{
> - __unlink_framebuffer(fb_info);
> -
> - unbind_console(fb_info);
> -}
> -EXPORT_SYMBOL(unlink_framebuffer);
> -
>  /**
>   * remove_conflicting_framebuffers - remove firmware-configured framebuffers
>   * @a: memory range, users of which are to be removed

Re: [PATCH v2] drm/drm_vblank: Change EINVAL by the correct errno

[Maarten Lankhorst]

Op 13-01-2019 om 21:23 schreef Rodrigo Siqueira:
> Hi,
>
> I resend this patch for CI via “intel-...@lists.freedesktop.org” as
> Daniel suggested, and I got a feedback that reported an issue as can be
> seen here:
>
>https://patchwork.freedesktop.org/series/51147/
>
> After a careful analysis of what happened, I concluded that the problem
> is related to the function “igt_wait_for_vblank_count()” in “igt_kms.c”.
> This function has the following assert:
>
>igt_assert(drmWaitVBlank(drm_fd, _vbl) == 0)
>
> This function only checks if everything went well with the
> drmWaitVBlank() operation and does not make any other validation. IMHO
> the patch is correct, and the problem pointed out by CI is not related
> to this change.

Hey,

Thanks for finding the root cause. Before upstreaming can you send a fix for 
i-g-t so we don't lose CI coverage after changing the behavior?

~Maarten

[PATCH] drm: Require PCI for selecting VGA_ARB.

[Maarten Lankhorst]

Op 08-01-2019 om 16:07 schreef Paul Menzel:
> Dear Linux folks,
>
>
> Building Linux 5.0-rc1 fails with the errors below. Please find the
> configuration file attached.
>
> ```
> $ make -j120
> […]
> drivers/gpu/vga/vgaarb.c: In function ‘__vga_tryget’:
> drivers/gpu/vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’ 
> undeclared (first use in this function); did you mean 
> ‘PCI_SUBTRACTIVE_DECODE’?
>  flags |= PCI_VGA_STATE_CHANGE_DECODES;
>   ^~~~
>   PCI_SUBTRACTIVE_DECODE
> drivers/gpu/vga/vgaarb.c:286:14: note: each undeclared identifier is reported 
> only once for each function it appears in
>   CC [M]  net/netfilter/xt_realm.o
>   CC  drivers/hid/hid-cherry.o
> drivers/gpu/vga/vga_switcheroo.c: In function 
> ‘vga_switcheroo_runtime_suspend’:
> drivers/gpu/vga/vga_switcheroo.c:1053:2: error: implicit declaration of 
> function ‘pci_bus_set_current_state’; did you mean ‘__set_current_state’? 
> [-Werror=implicit-function-declaration]
>   pci_bus_set_current_state(pdev->bus, PCI_D3cold);
>   ^
>   __set_current_state
> drivers/gpu/vga/vgaarb.c:291:13: error: ‘PCI_VGA_STATE_CHANGE_BRIDGE’ 
> undeclared (first use in this function); did you mean 
> ‘PCI_VGA_STATE_CHANGE_DECODES’?
> flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
>  ^~~
>  PCI_VGA_STATE_CHANGE_DECODES
>   CC  fs/reiserfs/dir.o
>   LD [M]  net/tipc/tipc.o
> drivers/gpu/vga/vga_switcheroo.c: In function ‘vga_switcheroo_runtime_resume’:
> drivers/gpu/vga/vga_switcheroo.c:1067:2: error: implicit declaration of 
> function ‘pci_wakeup_bus’; did you mean ‘__wake_up_bit’? 
> [-Werror=implicit-function-declaration]
>   pci_wakeup_bus(pdev->bus);
>   ^~
>   __wake_up_bit
> drivers/gpu/vga/vgaarb.c:293:3: error: implicit declaration of function 
> ‘pci_set_vga_state’; did you mean ‘pci_set_power_state’? 
> [-Werror=implicit-function-declaration]
>pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
>^
>pci_set_power_state
>   CC  fs/read_write.o
>   CC  drivers/hid/hid-chicony.o
>   CC  drivers/hid/hid-cypress.o
> drivers/gpu/vga/vgaarb.c: In function ‘vga_arb_device_init’:
> drivers/gpu/vga/vgaarb.c:1495:25: error: ‘pci_bus_type’ undeclared (first use 
> in this function); did you mean ‘pci_pcie_type’?
>   bus_register_notifier(_bus_type, _notifier);
>  ^~~~
>  pci_pcie_type
> cc1: some warnings being treated as errors
> make[3]: *** [scripts/Makefile.build:277: drivers/gpu/vga/vgaarb.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> […]
> ```
>
>
> Kind regards,
>
> Paul

WARNING: unmet direct dependencies detected for VGA_ARB
  Depends on [n]: HAS_IOMEM [=y] && PCI [=n] && !S390
  Selected by [y]:
  - VGA_SWITCHEROO [=y] && HAS_IOMEM [=y] && X86 [=y] && ACPI [=y]

So I guess you need to enable PCI, probably not a common config you're using. :)

Especially since you selected EXPERT.

Oh well, apply this with git am --scissors?
-8<
When configuring the kernel without PCI we can still enable VGA switcheroo,
which is not possible because VGA_ARB cannot be selected.

Remove this by depending on PCI for !S390.

Reported-by: Paul Menzel 
Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
index b677e5d524e6..ef5671475870 100644
--- a/drivers/gpu/vga/Kconfig
+++ b/drivers/gpu/vga/Kconfig
@@ -21,6 +21,7 @@ config VGA_SWITCHEROO
bool "Laptop Hybrid Graphics - GPU switching support"
depends on X86
depends on ACPI
+   depends on (PCI && !S390) # For VGA_ARB
select VGA_ARB
help
  Many laptops released in 2008/9/10 have two GPUs with a multiplexer

Re: WARNING: lock held when returning to user space in set_property_atomic

[Maarten Lankhorst]

Op 30-12-2018 om 07:21 schreef syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    903b77c63167 Merge tag 'linux-kselftest-4.21-rc1' of git:/..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12d0f55340
> kernel config:  https://syzkaller.appspot.com/x/.config?x=53a2f2aa0b1f7606
> dashboard link: https://syzkaller.appspot.com/bug?extid=6ea337c427f5083ebdf2
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=120d906f40
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1024673b40
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6ea337c427f5083eb...@syzkaller.appspotmail.com
>
> RBP: 7ffe369ca7a0 R08: 0001 R09: 004009ce
> R10:  R11: 0246 R12: 0005
> R13:  R14:  R15: 
>
> 
> WARNING: lock held when returning to user space!
> 4.20.0+ #174 Not tainted
> 
> syz-executor556/8153 is leaving the kernel with locks still held!
> 1 lock held by syz-executor556/8153:
>  #0: 5100c85c (crtc_ww_class_acquire){+.+.}, at: 
> set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches

Just guessing..

Does this help?
-
diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index cd9bc0ce9be0..004191d01772 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -459,11 +459,11 @@ static int set_property_atomic(struct drm_mode_object 
*obj,
struct drm_modeset_acquire_ctx ctx;
int ret;
 
-   drm_modeset_acquire_init(, 0);
-
state = drm_atomic_state_alloc(dev);
if (!state)
return -ENOMEM;
+
+   drm_modeset_acquire_init(, 0);
state->acquire_ctx = 
 retry:
if (prop == state->dev->mode_config.dpms_property) {

Re: [RFC PATCH] drm/atomic: add ASYNC_UPDATE flag to the Atomic IOCTL.

[Maarten Lankhorst]

Op 27-06-18 om 23:25 schreef Enric Balletbo i Serra:
> From: Gustavo Padovan 
>
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and update for the same plane is
> not queued.
>
> It uses the already in place infrastructure for async updates.
>
> It is useful for cursor updates and async PageFlips over the atomic
> ioctl, otherwise in some cases updates may be delayed to the point the
> user will notice it.
>
> DRM_MODE_ATOMIC_ASYNC_UPDATE should be passed to the Atomic IOCTL to use
> this feature.
>
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> Hi,
>
> This is an attempt to introduce the new ASYNC_UPDATE flag for atomic
> operations, see the commit message for a more detailed description.
>
> To test this patch we have created an IGT test that we plan to send to
> the ML but also was tested using a small program that exercises the uAPI
> for easy sanity testing. The program created by Alexandros can be found here
> [2]. To test, just build the program and use the --atomic flag to use the
> cursor plane in normal (blocking mode), and --atomic-async to use the cursor
> plane with the ASYNC_UPDATE flag.E.g.
>
>   drm_cursor --atomic
>
> or
>
>   drm_cursor --atomic-async
>
> The test worked on a Samsung Chromebook Plus on top of mainline plus
> the patch to update cursors asynchronously through atomic for the
> drm/rockchip driver [3].
>
> Alexandros also did a proof-of-concept to use this flag and draw cursors
> using atomic if possible on ozone [1].
>
> Best regards,
>  Enric
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711
> [2] https://gitlab.collabora.com/alf/drm-cursor
> [3] https://patchwork.kernel.org/patch/10492693/
>
>
>  drivers/gpu/drm/drm_atomic.c| 6 ++
>  drivers/gpu/drm/drm_atomic_helper.c | 9 ++---
>  include/uapi/drm/drm_mode.h | 4 +++-
>  3 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c825c76edc1d..15b799f46982 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -80,6 +80,7 @@ drm_atomic_state_init(struct drm_device *dev, struct 
> drm_atomic_state *state)
>* setting this appropriately?
>*/
>   state->allow_modeset = true;
> + state->async_update = true;
Do we really want this by default?

Wouldn't it make more sense to only enable it if userspace requests it?
>  
>   state->crtcs = kcalloc(dev->mode_config.num_crtc,
>  sizeof(*state->crtcs), GFP_KERNEL);
> @@ -2320,6 +2321,10 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>   return -EINVAL;
>  
> + if ((arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET) &&
> + (arg->flags & DRM_MODE_ATOMIC_ASYNC_UPDATE))
> + return -EINVAL;
> +
>   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>  
>   state = drm_atomic_state_alloc(dev);
We should probably move it to be a flag only enabled when requested, and reject 
with the error returned by drm_atomic_helper_async_check() when things fail.

~Maarten
> @@ -2328,6 +2333,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  
>   state->acquire_ctx = 
>   state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
> + state->async_update = !!(arg->flags & DRM_MODE_ATOMIC_ASYNC_UPDATE);
>  
>  retry:
>   plane_mask = 0;
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c35654591c12..aeb0523d3bcf 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -891,7 +891,7 @@ int drm_atomic_helper_check(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> - if (state->legacy_cursor_update)
> + if (state->async_update || state->legacy_cursor_update)
>   state->async_update = !drm_atomic_helper_async_check(dev, 
> state);
>  
>   return ret;
> @@ -1526,13 +1526,16 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>   if (new_plane_state->fence)
>   return -EINVAL;
>  
> + /* Only do an async update if there is a pending commit. */
> + if (!old_plane_state->commit)
> + return -EINVAL;
> +
>   /*
>* Don't do an async update if there is an outstanding commit modifying
>* the plane.  This prevents our async update's changes from getting
>* overridden by a previous synchronous update's state.
>*/
> - if (old_plane_state->commit &&
> - !try_wait_for_completion(_plane_state->commit->hw_done))
> + if (!try_wait_for_completion(_plane_state->commit->hw_done))
>   return -EBUSY;
>  
>   return 

Re: [RFC PATCH] drm/atomic: add ASYNC_UPDATE flag to the Atomic IOCTL.

[Maarten Lankhorst]

Op 27-06-18 om 23:25 schreef Enric Balletbo i Serra:
> From: Gustavo Padovan 
>
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and update for the same plane is
> not queued.
>
> It uses the already in place infrastructure for async updates.
>
> It is useful for cursor updates and async PageFlips over the atomic
> ioctl, otherwise in some cases updates may be delayed to the point the
> user will notice it.
>
> DRM_MODE_ATOMIC_ASYNC_UPDATE should be passed to the Atomic IOCTL to use
> this feature.
>
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> Hi,
>
> This is an attempt to introduce the new ASYNC_UPDATE flag for atomic
> operations, see the commit message for a more detailed description.
>
> To test this patch we have created an IGT test that we plan to send to
> the ML but also was tested using a small program that exercises the uAPI
> for easy sanity testing. The program created by Alexandros can be found here
> [2]. To test, just build the program and use the --atomic flag to use the
> cursor plane in normal (blocking mode), and --atomic-async to use the cursor
> plane with the ASYNC_UPDATE flag.E.g.
>
>   drm_cursor --atomic
>
> or
>
>   drm_cursor --atomic-async
>
> The test worked on a Samsung Chromebook Plus on top of mainline plus
> the patch to update cursors asynchronously through atomic for the
> drm/rockchip driver [3].
>
> Alexandros also did a proof-of-concept to use this flag and draw cursors
> using atomic if possible on ozone [1].
>
> Best regards,
>  Enric
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711
> [2] https://gitlab.collabora.com/alf/drm-cursor
> [3] https://patchwork.kernel.org/patch/10492693/
>
>
>  drivers/gpu/drm/drm_atomic.c| 6 ++
>  drivers/gpu/drm/drm_atomic_helper.c | 9 ++---
>  include/uapi/drm/drm_mode.h | 4 +++-
>  3 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c825c76edc1d..15b799f46982 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -80,6 +80,7 @@ drm_atomic_state_init(struct drm_device *dev, struct 
> drm_atomic_state *state)
>* setting this appropriately?
>*/
>   state->allow_modeset = true;
> + state->async_update = true;
Do we really want this by default?

Wouldn't it make more sense to only enable it if userspace requests it?
>  
>   state->crtcs = kcalloc(dev->mode_config.num_crtc,
>  sizeof(*state->crtcs), GFP_KERNEL);
> @@ -2320,6 +2321,10 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>   return -EINVAL;
>  
> + if ((arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET) &&
> + (arg->flags & DRM_MODE_ATOMIC_ASYNC_UPDATE))
> + return -EINVAL;
> +
>   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>  
>   state = drm_atomic_state_alloc(dev);
We should probably move it to be a flag only enabled when requested, and reject 
with the error returned by drm_atomic_helper_async_check() when things fail.

~Maarten
> @@ -2328,6 +2333,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  
>   state->acquire_ctx = 
>   state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
> + state->async_update = !!(arg->flags & DRM_MODE_ATOMIC_ASYNC_UPDATE);
>  
>  retry:
>   plane_mask = 0;
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c35654591c12..aeb0523d3bcf 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -891,7 +891,7 @@ int drm_atomic_helper_check(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> - if (state->legacy_cursor_update)
> + if (state->async_update || state->legacy_cursor_update)
>   state->async_update = !drm_atomic_helper_async_check(dev, 
> state);
>  
>   return ret;
> @@ -1526,13 +1526,16 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>   if (new_plane_state->fence)
>   return -EINVAL;
>  
> + /* Only do an async update if there is a pending commit. */
> + if (!old_plane_state->commit)
> + return -EINVAL;
> +
>   /*
>* Don't do an async update if there is an outstanding commit modifying
>* the plane.  This prevents our async update's changes from getting
>* overridden by a previous synchronous update's state.
>*/
> - if (old_plane_state->commit &&
> - !try_wait_for_completion(_plane_state->commit->hw_done))
> + if (!try_wait_for_completion(_plane_state->commit->hw_done))
>   return -EBUSY;
>  
>   return 

Re: [PATCH v8 3/3] drm: writeback: Add client capability for exposing writeback connectors

[Maarten Lankhorst]

Op 18-05-18 om 17:17 schreef Liviu Dudau:
> Due to the fact that writeback connectors behave in a special way
> in DRM (they always report being disconnected) we might confuse some
> userspace. Add a client capability for writeback connectors that will
> filter them out for clients that don't understand the capability.
>
> Re-requested-by: Sean Paul 
> Cc: Brian Starkey 
> Signed-off-by: Liviu Dudau 
> ---
>  drivers/gpu/drm/drm_ioctl.c   | 7 +++
>  drivers/gpu/drm/drm_mode_config.c | 5 +
>  include/drm/drm_file.h| 7 +++
>  include/uapi/drm/drm.h| 9 +
>  4 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index af782911c505d..59951ff3e3630 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -325,6 +325,13 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>   file_priv->atomic = req->value;
>   file_priv->universal_planes = req->value;
>   break;
> + case DRM_CLIENT_CAP_WRITEBACK_CONNECTORS:
> + if (!file_priv->atomic || !drm_core_check_feature(dev, 
> DRIVER_ATOMIC))
> + return -EINVAL;
Wondering how you can set the atomic cap without DRIVER_ATOMIC. :)

That part could be dropped I think. We should probably WARN when trying to 
create a writeback connector without the DRIVER_ATOMIC cap set.
> + if (req->value > 1)
> + return -EINVAL;
> + file_priv->writeback_connectors = req->value;
> + break;
>   default:
>   return -EINVAL;
>   }
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index e5c653357024d..21e353bd3948e 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -145,6 +145,11 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
>   count = 0;
>   connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
>   drm_for_each_connector_iter(connector, _iter) {
> + /* only expose writeback connectors if userspace understands 
> them */
> + if (!file_priv->writeback_connectors &&
> + (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
> + continue;
> +
>   if (drm_lease_held(file_priv, connector->base.id)) {
>   if (count < card_res->count_connectors &&
>   put_user(connector->base.id, connector_id + count)) 
> {
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 5176c3797680c..2a09b3c8965c6 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -181,6 +181,13 @@ struct drm_file {
>   /** @atomic: True if client understands atomic properties. */
>   unsigned atomic:1;
>  
> + /**
> +  * @writeback_connectors:
> +  *
> +  * True if client understands writeback connectors
> +  */
> + unsigned writeback_connectors:1;
> +
>   /**
>* @is_master:
>*
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 6fdff5945c8a0..59f27ea928b42 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -680,6 +680,15 @@ struct drm_get_cap {
>   */
>  #define DRM_CLIENT_CAP_ATOMIC3
>  
> +/**
> + * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
> + *
> + * If set to 1, the DRM core will expose special connectors to be used for
> + * writing back to memory the scene setup in the commit. Depends on client
> + * also supporting DRM_CLIENT_CAP_ATOMIC
> + */
> +#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS  4
> +
>  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
>  struct drm_set_client_cap {
>   __u64 capability;

~Maarten

Re: [PATCH v8 3/3] drm: writeback: Add client capability for exposing writeback connectors

[Maarten Lankhorst]

Op 18-05-18 om 17:17 schreef Liviu Dudau:
> Due to the fact that writeback connectors behave in a special way
> in DRM (they always report being disconnected) we might confuse some
> userspace. Add a client capability for writeback connectors that will
> filter them out for clients that don't understand the capability.
>
> Re-requested-by: Sean Paul 
> Cc: Brian Starkey 
> Signed-off-by: Liviu Dudau 
> ---
>  drivers/gpu/drm/drm_ioctl.c   | 7 +++
>  drivers/gpu/drm/drm_mode_config.c | 5 +
>  include/drm/drm_file.h| 7 +++
>  include/uapi/drm/drm.h| 9 +
>  4 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index af782911c505d..59951ff3e3630 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -325,6 +325,13 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>   file_priv->atomic = req->value;
>   file_priv->universal_planes = req->value;
>   break;
> + case DRM_CLIENT_CAP_WRITEBACK_CONNECTORS:
> + if (!file_priv->atomic || !drm_core_check_feature(dev, 
> DRIVER_ATOMIC))
> + return -EINVAL;
Wondering how you can set the atomic cap without DRIVER_ATOMIC. :)

That part could be dropped I think. We should probably WARN when trying to 
create a writeback connector without the DRIVER_ATOMIC cap set.
> + if (req->value > 1)
> + return -EINVAL;
> + file_priv->writeback_connectors = req->value;
> + break;
>   default:
>   return -EINVAL;
>   }
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index e5c653357024d..21e353bd3948e 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -145,6 +145,11 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
>   count = 0;
>   connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
>   drm_for_each_connector_iter(connector, _iter) {
> + /* only expose writeback connectors if userspace understands 
> them */
> + if (!file_priv->writeback_connectors &&
> + (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
> + continue;
> +
>   if (drm_lease_held(file_priv, connector->base.id)) {
>   if (count < card_res->count_connectors &&
>   put_user(connector->base.id, connector_id + count)) 
> {
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 5176c3797680c..2a09b3c8965c6 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -181,6 +181,13 @@ struct drm_file {
>   /** @atomic: True if client understands atomic properties. */
>   unsigned atomic:1;
>  
> + /**
> +  * @writeback_connectors:
> +  *
> +  * True if client understands writeback connectors
> +  */
> + unsigned writeback_connectors:1;
> +
>   /**
>* @is_master:
>*
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 6fdff5945c8a0..59f27ea928b42 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -680,6 +680,15 @@ struct drm_get_cap {
>   */
>  #define DRM_CLIENT_CAP_ATOMIC3
>  
> +/**
> + * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
> + *
> + * If set to 1, the DRM core will expose special connectors to be used for
> + * writing back to memory the scene setup in the commit. Depends on client
> + * also supporting DRM_CLIENT_CAP_ATOMIC
> + */
> +#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS  4
> +
>  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
>  struct drm_set_client_cap {
>   __u64 capability;

~Maarten

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

[Maarten Lankhorst]

Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li 
> ---
>  drivers/gpu/drm/drm_fourcc.c  | 1 +
>  include/uapi/drm/drm_fourcc.h | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395cd4d3..1f43967c4013 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,  
> .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
Hm, the cpp value might give problems because it rounds down, not sure how we 
should handle that? Set to zero?
>   };
>  
>   unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..8eabf01e966f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -140,6 +140,9 @@ extern "C" {
>  #define DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /* 
> non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +/* A fully packed variant of NV12_10LE32 */
> +#define DRM_FORMAT_NV12_10LE40   fourcc_code('R', 'K', '2', '0') /* 2x2 
> subsampled Cr:Cb plane */
> +
>  
>  /*
>   * 3 plane YCbCr

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

[Maarten Lankhorst]

Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li 
> ---
>  drivers/gpu/drm/drm_fourcc.c  | 1 +
>  include/uapi/drm/drm_fourcc.h | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395cd4d3..1f43967c4013 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,  
> .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
Hm, the cpp value might give problems because it rounds down, not sure how we 
should handle that? Set to zero?
>   };
>  
>   unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..8eabf01e966f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -140,6 +140,9 @@ extern "C" {
>  #define DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /* 
> non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +/* A fully packed variant of NV12_10LE32 */
> +#define DRM_FORMAT_NV12_10LE40   fourcc_code('R', 'K', '2', '0') /* 2x2 
> subsampled Cr:Cb plane */
> +
>  
>  /*
>   * 3 plane YCbCr

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

[Maarten Lankhorst]

Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li 
> ---
>  drivers/gpu/drm/drm_fourcc.c  | 1 +
>  include/uapi/drm/drm_fourcc.h | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395cd4d3..1f43967c4013 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,  
> .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
>   };
>  
>   unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..8eabf01e966f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -140,6 +140,9 @@ extern "C" {
>  #define DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /* 
> non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +/* A fully packed variant of NV12_10LE32 */
> +#define DRM_FORMAT_NV12_10LE40   fourcc_code('R', 'K', '2', '0') /* 2x2 
> subsampled Cr:Cb plane */
> +
>  
>  /*
>   * 3 plane YCbCr

I think the description here is slightly too terse for adding a new packed 
format. I think it would be better
to define a new category for 10-bit 2 plane formats.

~Maarten

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

[Maarten Lankhorst]

Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li 
> ---
>  drivers/gpu/drm/drm_fourcc.c  | 1 +
>  include/uapi/drm/drm_fourcc.h | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395cd4d3..1f43967c4013 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
>   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,  
> .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
>   };
>  
>   unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..8eabf01e966f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -140,6 +140,9 @@ extern "C" {
>  #define DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /* 
> non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +/* A fully packed variant of NV12_10LE32 */
> +#define DRM_FORMAT_NV12_10LE40   fourcc_code('R', 'K', '2', '0') /* 2x2 
> subsampled Cr:Cb plane */
> +
>  
>  /*
>   * 3 plane YCbCr

I think the description here is slightly too terse for adding a new packed 
format. I think it would be better
to define a new category for 10-bit 2 plane formats.

~Maarten

Re: [RFC PATCH] drm: Add per-plane pixel blend mode property

[Maarten Lankhorst]

Op 08-05-18 om 12:34 schreef Lowry Li:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Add a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related support
> functions.
>
> Defines three blend modes in drm_blend.h.
>
> Signed-off-by: Lowry Li 
> ---
>  drivers/gpu/drm/drm_atomic.c|  4 ++
>  drivers/gpu/drm/drm_atomic_helper.c |  1 +
>  drivers/gpu/drm/drm_blend.c | 95 
> +
>  include/drm/drm_blend.h |  6 +++
>  include/drm/drm_plane.h |  7 +++
>  5 files changed, 113 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..0bb6de1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -764,6 +764,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> + } else if (property == plane->blend_mode_property) {
> + state->pixel_blend_mode = val;
>   } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_ROTATE_MASK))
>   return -EINVAL;
> @@ -826,6 +828,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> + } else if (property == plane->blend_mode_property) {
> + *val = state->pixel_blend_mode;
>   } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 01d936b..e4377fd 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3133,6 +3133,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
> *plane)
>   if (plane->state) {
>   plane->state->plane = plane;
>   plane->state->rotation = DRM_ROTATE_0;
> + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>   }
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 665aafc..bb938de 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -98,6 +98,12 @@
>   *   planes. Without this property the primary plane is always below the 
> cursor
>   *   plane, and ordering between all other planes is undefined.
>   *
> + * pixel blend mode:
> + *   Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> + *   It adds a blend mode for alpha blending equation selection, describing
> + *   how the pixels from the current plane are composited with the
> + *   background.
> + *
>   * Note that all the property extensions described here apply either to the
>   * plane or the CRTC (e.g. for the background color, which currently is not
>   * exposed and assumed to be black).
> @@ -405,3 +411,92 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_normalize_zpos);
> +
> +/**
> + * drm_plane_create_blend_mode_property - create a new blend mode property
> + * @plane: drm plane
> + * @supported_modes: bitmask of supported modes, must include
> + *BIT(DRM_MODE_BLEND_PREMULTI)
> + *
> + * This creates a new property describing the blend mode.
> + *
> + * The property exposed to userspace is an enumeration property (see
> + * drm_property_create_enum()) called "pixel blend mode" and has the
> + * following enumeration values:
> + *
> + * DRM_MODE_BLEND_PIXEL_NONE: Blend formula that ignores the pixel alpha.
> + *   "None"
> + *   out.rgb = plane.alpha * pixel.rgb + (1 - plane.alpha) * bg.rgb
> + *
> + * DRM_MODE_BLEND_PREMULTI: Blend formula that assumes the pixel color values
> + *   have been already pre-multiplied with the alpha
> + *   channel values.
> + *   "Pre-multiplied"
> + *   out.rgb = plane.alpha * pixel.rgb +
> + * (1 - (plane.alpha * pixel.alpha)) * bg.rgb
> + *
> + * DRM_MODE_BLEND_COVERAGE: Blend formula that assumes the pixel color values
> + *   have not been pre-multiplied and will do so when
> + *   blending them to the background color values.
> + *   "Coverage"
> + *   out.rgb = plane.alpha * pixel.alpha * pixel.rgb +
> + * (1 - (plane.alpha * pixel.alpha)) * bg.rgb
> + *
> + * This property has no effect on formats with no pixel alpha, as pixel.alpha
> + * is assumed to be 1.0. If the plane does not expose the "alpha" property, 
> then
> + * plane.alpha is assumed to be 1.0, otherwise, it is the value of 

Re: [RFC PATCH] drm: Add per-plane pixel blend mode property

[Maarten Lankhorst]

Op 08-05-18 om 12:34 schreef Lowry Li:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Add a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related support
> functions.
>
> Defines three blend modes in drm_blend.h.
>
> Signed-off-by: Lowry Li 
> ---
>  drivers/gpu/drm/drm_atomic.c|  4 ++
>  drivers/gpu/drm/drm_atomic_helper.c |  1 +
>  drivers/gpu/drm/drm_blend.c | 95 
> +
>  include/drm/drm_blend.h |  6 +++
>  include/drm/drm_plane.h |  7 +++
>  5 files changed, 113 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..0bb6de1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -764,6 +764,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> + } else if (property == plane->blend_mode_property) {
> + state->pixel_blend_mode = val;
>   } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_ROTATE_MASK))
>   return -EINVAL;
> @@ -826,6 +828,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> + } else if (property == plane->blend_mode_property) {
> + *val = state->pixel_blend_mode;
>   } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 01d936b..e4377fd 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3133,6 +3133,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
> *plane)
>   if (plane->state) {
>   plane->state->plane = plane;
>   plane->state->rotation = DRM_ROTATE_0;
> + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>   }
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 665aafc..bb938de 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -98,6 +98,12 @@
>   *   planes. Without this property the primary plane is always below the 
> cursor
>   *   plane, and ordering between all other planes is undefined.
>   *
> + * pixel blend mode:
> + *   Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> + *   It adds a blend mode for alpha blending equation selection, describing
> + *   how the pixels from the current plane are composited with the
> + *   background.
> + *
>   * Note that all the property extensions described here apply either to the
>   * plane or the CRTC (e.g. for the background color, which currently is not
>   * exposed and assumed to be black).
> @@ -405,3 +411,92 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_normalize_zpos);
> +
> +/**
> + * drm_plane_create_blend_mode_property - create a new blend mode property
> + * @plane: drm plane
> + * @supported_modes: bitmask of supported modes, must include
> + *BIT(DRM_MODE_BLEND_PREMULTI)
> + *
> + * This creates a new property describing the blend mode.
> + *
> + * The property exposed to userspace is an enumeration property (see
> + * drm_property_create_enum()) called "pixel blend mode" and has the
> + * following enumeration values:
> + *
> + * DRM_MODE_BLEND_PIXEL_NONE: Blend formula that ignores the pixel alpha.
> + *   "None"
> + *   out.rgb = plane.alpha * pixel.rgb + (1 - plane.alpha) * bg.rgb
> + *
> + * DRM_MODE_BLEND_PREMULTI: Blend formula that assumes the pixel color values
> + *   have been already pre-multiplied with the alpha
> + *   channel values.
> + *   "Pre-multiplied"
> + *   out.rgb = plane.alpha * pixel.rgb +
> + * (1 - (plane.alpha * pixel.alpha)) * bg.rgb
> + *
> + * DRM_MODE_BLEND_COVERAGE: Blend formula that assumes the pixel color values
> + *   have not been pre-multiplied and will do so when
> + *   blending them to the background color values.
> + *   "Coverage"
> + *   out.rgb = plane.alpha * pixel.alpha * pixel.rgb +
> + * (1 - (plane.alpha * pixel.alpha)) * bg.rgb
> + *
> + * This property has no effect on formats with no pixel alpha, as pixel.alpha
> + * is assumed to be 1.0. If the plane does not expose the "alpha" property, 
> then
> + * plane.alpha is assumed to be 1.0, otherwise, it is the value of the 
> "alpha"
> + 

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

[Maarten Lankhorst]

Op 19-04-18 om 13:05 schreef Fengguang Wu:
> Hi Maarten,
>
>> What extra dmesg output do you get when you boot with drm.debug=0x1f ?
>
> Attached is the dmesg with drm.debug=0x1f.
>
> Thanks,
> Fengguang

Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768:

kern  :debug : [   74.880444] [drm:i9xx_get_initial_plane_config [i915]] pipe 
A/primary A with fb: size=1366x768@32, offset=61000, pitch 5504, size 0x408000
kern  :debug : [   74.881187] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x00408000
kern  :debug : [   74.882197] [drm:intel_alloc_initial_plane_obj.isra.126 
[i915]] initial plane fb obj 5efa24f9

kern  :debug : [   74.883532] [drm:i9xx_get_initial_plane_config [i915]] pipe 
B/primary B with fb: size=1280x1024@32, offset=61000, pitch 5504, size 0x56
kern  :debug : [   74.884260] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x0056
kern  :debug : [   74.885295] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] failed to allocate 
stolen space

Which of course fails, but should be an interesting case to handle right. :)

~Maarten

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

[Maarten Lankhorst]

Op 19-04-18 om 13:05 schreef Fengguang Wu:
> Hi Maarten,
>
>> What extra dmesg output do you get when you boot with drm.debug=0x1f ?
>
> Attached is the dmesg with drm.debug=0x1f.
>
> Thanks,
> Fengguang

Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768:

kern  :debug : [   74.880444] [drm:i9xx_get_initial_plane_config [i915]] pipe 
A/primary A with fb: size=1366x768@32, offset=61000, pitch 5504, size 0x408000
kern  :debug : [   74.881187] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x00408000
kern  :debug : [   74.882197] [drm:intel_alloc_initial_plane_obj.isra.126 
[i915]] initial plane fb obj 5efa24f9

kern  :debug : [   74.883532] [drm:i9xx_get_initial_plane_config [i915]] pipe 
B/primary B with fb: size=1280x1024@32, offset=61000, pitch 5504, size 0x56
kern  :debug : [   74.884260] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x0056
kern  :debug : [   74.885295] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] failed to allocate 
stolen space

Which of course fails, but should be an interesting case to handle right. :)

~Maarten

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

[Maarten Lankhorst]

Hey,

Op 19-04-18 om 04:52 schreef Fengguang Wu:
> Hello,
>
> FYI this happens in mainline kernel and at least dates back to v4.13 .
>
> [   75.245840]
> [   75.247783] /opt/deb/gawk_1%3a4.1.4+dfsg-1_amd64.deb
> [   75.247785]
> [   75.248145] [ cut here ]
> [   75.248446] Could not determine valid watermarks for inherited state
> [   75.248889] WARNING: CPU: 2 PID: 183 at 
> drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060 
> [i915]
> [   75.249372] /opt/deb/sysstat_11.6.0-1_amd64.deb
> [   75.249617] Modules linked in:
> [   75.249619]
> [   75.249883]  crc32c_intel(+) ghash_clmulni_intel pcbc wmi_bmof ahci 
> libahci snd_hda_intel i915(+) uvcvideo videobuf2_vmalloc aesni_intel 
> crypto_simd cryptd videobuf2_memops glue_helper snd_hda_codec videobuf2_v4l2 
> pcspkr videobuf2_common serio_raw drm_kms_helper snd_hda_core snd_hwdep 
> libata snd_pcm syscopyarea sysfillrect sysimgblt fb_sys_fops bcma snd_timer 
> snd soundcore drm videodev shpchp ideapad_laptop wmi sparse_keymap rfkill 
> video ip_tables
> [   75.252346] CPU: 2 PID: 183 Comm: systemd-udevd Not tainted 4.17.0-rc1 #1
> [   75.252718] Hardware name: LENOVO IdeaPad U410/Lenovo  , BIOS 
> 65CN15WW 06/05/2012
> [   75.253140] (Reading database ... 2202 files and directories currently 
> installed.)
> [   75.253229] RIP: 0010:intel_modeset_init+0x3be/0x1060 [i915]
> [   75.253230]
> [   75.254044] RSP: 0018:c99f7af0 EFLAGS: 00010282
> [   75.254339] RAX: 0038 RBX: 88011bfc RCX: 
> 0006
> [   75.254731] RDX: 0007 RSI: 0082 RDI: 
> 88011f296910
> [   75.255121] RBP: 88011933e400 R08: 0363 R09: 
> 000a
> [   75.255512] R10: c99f7988 R11: 82d4e10d R12: 
> 88011933fc00
> [   75.255898] R13: ffea R14:  R15: 
> 88011bfc0358
> [   75.256290] FS:  7f0b39a7d8c0() GS:88011f28() 
> knlGS:
> [   75.256731] CS:  0010 DS:  ES:  CR0: 80050033
> [   75.257050] CR2: 7f599dcec750 CR3: 00011bdcc004 CR4: 
> 001606e0
> [   75.257111] Preparing to unpack .../opt/deb/debconf_1.5.66_all.deb ...
> [   75.257449] Call Trace:
> [   75.257450]
> [   75.258115]  i915_driver_load+0xa99/0xee0 [i915]
> [   75.258388]  ? acpi_dev_found+0x5f/0x70:
>   acpi_dev_found at 
> drivers/acpi/utils.c:737
> [   75.258616]  local_pci_probe+0x42/0xa0:
>   local_pci_probe at 
> drivers/pci/pci-driver.c:304
> [   75.258835]  ? _cond_resched+0x19/0x30:
>   _cond_resched at 
> kernel/sched/core.c:4982
> [   75.259055]  pci_device_probe+0x11d/0x180:
>   pci_call_probe at 
> drivers/pci/pci-driver.c:358
>(inlined by) 
> __pci_device_probe at drivers/pci/pci-driver.c:383
>(inlined by) pci_device_probe 
> at drivers/pci/pci-driver.c:423
> [   75.259287]  driver_probe_device+0x30b/0x480:
>   really_probe at 
> drivers/base/dd.c:449
>(inlined by) 
> driver_probe_device at drivers/base/dd.c:590
> [   75.259531]  __driver_attach+0xb8/0xe0:
>   __driver_attach at 
> drivers/base/dd.c:824
> [   75.259661] Unpacking debconf (1.5.66) over (1.5.59) ...
> [   75.259748]  ? driver_probe_device+0x480/0x480:
>   __driver_attach at 
> drivers/base/dd.c:794
> [   75.259749]
> [   75.260394]  bus_for_each_dev+0x65/0x90:
>   bus_for_each_dev at 
> drivers/base/bus.c:310
> [   75.260624]  bus_add_driver+0x161/0x260:
>   bus_add_driver at 
> drivers/base/bus.c:668
> [   75.260849]  ? 0xa0553000
> [   75.261042]  driver_register+0x57/0xc0:
>   driver_register at 
> drivers/base/driver.c:167
> [   75.261259]  ? 0xa0553000
> [   75.261451]  do_one_initcall+0x36/0x1bb:
>   do_one_initcall at 
> init/main.c:883
> [   75.261676]  ? _cond_resched+0x19/0x30:
>   _cond_resched at 
> kernel/sched/core.c:4982
> [   75.261898]  ? kmem_cache_alloc_trace+0x3e/0x1e0:
>   slab_pre_alloc_hook at 
> mm/slab.h:423
>(inlined by) slab_alloc_node 
> at mm/slub.c:2667
>(inlined by) slab_alloc at 
> mm/slub.c:2749
>(inlined by) 
> kmem_cache_alloc_trace at mm/slub.c:2766
> [   75.262166]  

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

[Maarten Lankhorst]

Hey,

Op 19-04-18 om 04:52 schreef Fengguang Wu:
> Hello,
>
> FYI this happens in mainline kernel and at least dates back to v4.13 .
>
> [   75.245840]
> [   75.247783] /opt/deb/gawk_1%3a4.1.4+dfsg-1_amd64.deb
> [   75.247785]
> [   75.248145] [ cut here ]
> [   75.248446] Could not determine valid watermarks for inherited state
> [   75.248889] WARNING: CPU: 2 PID: 183 at 
> drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060 
> [i915]
> [   75.249372] /opt/deb/sysstat_11.6.0-1_amd64.deb
> [   75.249617] Modules linked in:
> [   75.249619]
> [   75.249883]  crc32c_intel(+) ghash_clmulni_intel pcbc wmi_bmof ahci 
> libahci snd_hda_intel i915(+) uvcvideo videobuf2_vmalloc aesni_intel 
> crypto_simd cryptd videobuf2_memops glue_helper snd_hda_codec videobuf2_v4l2 
> pcspkr videobuf2_common serio_raw drm_kms_helper snd_hda_core snd_hwdep 
> libata snd_pcm syscopyarea sysfillrect sysimgblt fb_sys_fops bcma snd_timer 
> snd soundcore drm videodev shpchp ideapad_laptop wmi sparse_keymap rfkill 
> video ip_tables
> [   75.252346] CPU: 2 PID: 183 Comm: systemd-udevd Not tainted 4.17.0-rc1 #1
> [   75.252718] Hardware name: LENOVO IdeaPad U410/Lenovo  , BIOS 
> 65CN15WW 06/05/2012
> [   75.253140] (Reading database ... 2202 files and directories currently 
> installed.)
> [   75.253229] RIP: 0010:intel_modeset_init+0x3be/0x1060 [i915]
> [   75.253230]
> [   75.254044] RSP: 0018:c99f7af0 EFLAGS: 00010282
> [   75.254339] RAX: 0038 RBX: 88011bfc RCX: 
> 0006
> [   75.254731] RDX: 0007 RSI: 0082 RDI: 
> 88011f296910
> [   75.255121] RBP: 88011933e400 R08: 0363 R09: 
> 000a
> [   75.255512] R10: c99f7988 R11: 82d4e10d R12: 
> 88011933fc00
> [   75.255898] R13: ffea R14:  R15: 
> 88011bfc0358
> [   75.256290] FS:  7f0b39a7d8c0() GS:88011f28() 
> knlGS:
> [   75.256731] CS:  0010 DS:  ES:  CR0: 80050033
> [   75.257050] CR2: 7f599dcec750 CR3: 00011bdcc004 CR4: 
> 001606e0
> [   75.257111] Preparing to unpack .../opt/deb/debconf_1.5.66_all.deb ...
> [   75.257449] Call Trace:
> [   75.257450]
> [   75.258115]  i915_driver_load+0xa99/0xee0 [i915]
> [   75.258388]  ? acpi_dev_found+0x5f/0x70:
>   acpi_dev_found at 
> drivers/acpi/utils.c:737
> [   75.258616]  local_pci_probe+0x42/0xa0:
>   local_pci_probe at 
> drivers/pci/pci-driver.c:304
> [   75.258835]  ? _cond_resched+0x19/0x30:
>   _cond_resched at 
> kernel/sched/core.c:4982
> [   75.259055]  pci_device_probe+0x11d/0x180:
>   pci_call_probe at 
> drivers/pci/pci-driver.c:358
>(inlined by) 
> __pci_device_probe at drivers/pci/pci-driver.c:383
>(inlined by) pci_device_probe 
> at drivers/pci/pci-driver.c:423
> [   75.259287]  driver_probe_device+0x30b/0x480:
>   really_probe at 
> drivers/base/dd.c:449
>(inlined by) 
> driver_probe_device at drivers/base/dd.c:590
> [   75.259531]  __driver_attach+0xb8/0xe0:
>   __driver_attach at 
> drivers/base/dd.c:824
> [   75.259661] Unpacking debconf (1.5.66) over (1.5.59) ...
> [   75.259748]  ? driver_probe_device+0x480/0x480:
>   __driver_attach at 
> drivers/base/dd.c:794
> [   75.259749]
> [   75.260394]  bus_for_each_dev+0x65/0x90:
>   bus_for_each_dev at 
> drivers/base/bus.c:310
> [   75.260624]  bus_add_driver+0x161/0x260:
>   bus_add_driver at 
> drivers/base/bus.c:668
> [   75.260849]  ? 0xa0553000
> [   75.261042]  driver_register+0x57/0xc0:
>   driver_register at 
> drivers/base/driver.c:167
> [   75.261259]  ? 0xa0553000
> [   75.261451]  do_one_initcall+0x36/0x1bb:
>   do_one_initcall at 
> init/main.c:883
> [   75.261676]  ? _cond_resched+0x19/0x30:
>   _cond_resched at 
> kernel/sched/core.c:4982
> [   75.261898]  ? kmem_cache_alloc_trace+0x3e/0x1e0:
>   slab_pre_alloc_hook at 
> mm/slab.h:423
>(inlined by) slab_alloc_node 
> at mm/slub.c:2667
>(inlined by) slab_alloc at 
> mm/slub.c:2749
>(inlined by) 
> kmem_cache_alloc_trace at mm/slub.c:2766
> [   75.262166]  

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 14:26 schreef Daniel Vetter:
> On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark <robdcl...@gmail.com> wrote:
>> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst
>> <maarten.lankho...@linux.intel.com> wrote:
>>> Op 04-04-18 om 13:37 schreef Rob Clark:
>>>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
>>>> <maarten.lankho...@linux.intel.com> wrote:
>>>>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>>>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>>>>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>>>>>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>>>>>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>>>>>>> rely on pageflips to trigger a flush to the panel).
>>>>>>>>
>>>>>>>> To signal to the driver that the async atomic update needs to
>>>>>>>> synchronize with fences, even though the fb didn't change, the
>>>>>>>> drm_atomic_state::dirty flag is added.
>>>>>>>>
>>>>>>>> Signed-off-by: Rob Clark <robdcl...@gmail.com>
>>>>>>>> ---
>>>>>>>> Background: there are a number of different folks working on getting
>>>>>>>> upstream kernel working on various different phones/tablets with qcom
>>>>>>>> SoC's.. many of them have command mode panels, so we kind of need a
>>>>>>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>>>>>>
>>>>>>>> I know there is work on a proprer non-legacy atomic property for
>>>>>>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>>>>>>> be improved from triggering a full-frame flush once that is in
>>>>>>>> place.  But we kinda needa a stop-gap solution.
>>>>>>>>
>>>>>>>> I had considered an in-driver solution for this, but things get a
>>>>>>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>>>>>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>>>>>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>>>>>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>>>>>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>>>>>>> is to wrap this up as an atomic commit and rely on the worker to
>>>>>>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>>>>>>
>>>>>>>> I guess at least the helper, with some small addition to translate
>>>>>>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>>>>>>> rect property solution.  Depending on how far off that is, a stop-
>>>>>>>> gap solution could be useful.
>>>>>>>>
>>>>>>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>>>>>>> +
>>>>>>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>>>>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>>>>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>>>>>>  include/drm/drm_plane.h |  9 +
>>>>>>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>>> index c35654591c12..a578dc681b27 100644
>>>>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>>> @@ -3504,6 +3504,7 @@ void 
>>>>>>>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>>>>>>> if (state->fb)
>>>>>>>> drm_framebuffer_get(state->fb);
>>>>>>>>
>>>>>>>> +   state->dirty = false;
>>>>>>>> state->fence = NULL;
>>>>>>>> state->commit = NULL;
>>>>>>>>  }
>&g

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 14:26 schreef Daniel Vetter:
> On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark  wrote:
>> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst
>>  wrote:
>>> Op 04-04-18 om 13:37 schreef Rob Clark:
>>>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
>>>>  wrote:
>>>>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>>>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>>>>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>>>>>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>>>>>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>>>>>>> rely on pageflips to trigger a flush to the panel).
>>>>>>>>
>>>>>>>> To signal to the driver that the async atomic update needs to
>>>>>>>> synchronize with fences, even though the fb didn't change, the
>>>>>>>> drm_atomic_state::dirty flag is added.
>>>>>>>>
>>>>>>>> Signed-off-by: Rob Clark 
>>>>>>>> ---
>>>>>>>> Background: there are a number of different folks working on getting
>>>>>>>> upstream kernel working on various different phones/tablets with qcom
>>>>>>>> SoC's.. many of them have command mode panels, so we kind of need a
>>>>>>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>>>>>>
>>>>>>>> I know there is work on a proprer non-legacy atomic property for
>>>>>>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>>>>>>> be improved from triggering a full-frame flush once that is in
>>>>>>>> place.  But we kinda needa a stop-gap solution.
>>>>>>>>
>>>>>>>> I had considered an in-driver solution for this, but things get a
>>>>>>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>>>>>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>>>>>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>>>>>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>>>>>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>>>>>>> is to wrap this up as an atomic commit and rely on the worker to
>>>>>>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>>>>>>
>>>>>>>> I guess at least the helper, with some small addition to translate
>>>>>>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>>>>>>> rect property solution.  Depending on how far off that is, a stop-
>>>>>>>> gap solution could be useful.
>>>>>>>>
>>>>>>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>>>>>>> +
>>>>>>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>>>>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>>>>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>>>>>>  include/drm/drm_plane.h |  9 +
>>>>>>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>>> index c35654591c12..a578dc681b27 100644
>>>>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>>> @@ -3504,6 +3504,7 @@ void 
>>>>>>>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>>>>>>> if (state->fb)
>>>>>>>> drm_framebuffer_get(state->fb);
>>>>>>>>
>>>>>>>> +   state->dirty = false;
>>>>>>>> state->fence = NULL;
>>>>>>>> state->commit = NULL;
>>>>>>>>  }
>>>>>>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct 
>>>>>>>> drm_crtc *crtc,
>

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 14:05 schreef Rob Clark:
> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst
> <maarten.lankho...@linux.intel.com> wrote:
>> Op 04-04-18 om 13:37 schreef Rob Clark:
>>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
>>> <maarten.lankho...@linux.intel.com> wrote:
>>>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>>>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>>>>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>>>>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>>>>>> rely on pageflips to trigger a flush to the panel).
>>>>>>>
>>>>>>> To signal to the driver that the async atomic update needs to
>>>>>>> synchronize with fences, even though the fb didn't change, the
>>>>>>> drm_atomic_state::dirty flag is added.
>>>>>>>
>>>>>>> Signed-off-by: Rob Clark <robdcl...@gmail.com>
>>>>>>> ---
>>>>>>> Background: there are a number of different folks working on getting
>>>>>>> upstream kernel working on various different phones/tablets with qcom
>>>>>>> SoC's.. many of them have command mode panels, so we kind of need a
>>>>>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>>>>>
>>>>>>> I know there is work on a proprer non-legacy atomic property for
>>>>>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>>>>>> be improved from triggering a full-frame flush once that is in
>>>>>>> place.  But we kinda needa a stop-gap solution.
>>>>>>>
>>>>>>> I had considered an in-driver solution for this, but things get a
>>>>>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>>>>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>>>>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>>>>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>>>>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>>>>>> is to wrap this up as an atomic commit and rely on the worker to
>>>>>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>>>>>
>>>>>>> I guess at least the helper, with some small addition to translate
>>>>>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>>>>>> rect property solution.  Depending on how far off that is, a stop-
>>>>>>> gap solution could be useful.
>>>>>>>
>>>>>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>>>>>> +
>>>>>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>>>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>>>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>>>>>  include/drm/drm_plane.h |  9 +
>>>>>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>> index c35654591c12..a578dc681b27 100644
>>>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>> @@ -3504,6 +3504,7 @@ void 
>>>>>>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>>>>>> if (state->fb)
>>>>>>> drm_framebuffer_get(state->fb);
>>>>>>>
>>>>>>> +   state->dirty = false;
>>>>>>> state->fence = NULL;
>>>>>>> state->commit = NULL;
>>>>>>>  }
>>>>>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct 
>>>>>>> drm_crtc *crtc,
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>>>>>>>
>>>>>>> +/**
>>>>

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 14:05 schreef Rob Clark:
> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst
>  wrote:
>> Op 04-04-18 om 13:37 schreef Rob Clark:
>>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
>>>  wrote:
>>>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>>>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>>>>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>>>>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>>>>>> rely on pageflips to trigger a flush to the panel).
>>>>>>>
>>>>>>> To signal to the driver that the async atomic update needs to
>>>>>>> synchronize with fences, even though the fb didn't change, the
>>>>>>> drm_atomic_state::dirty flag is added.
>>>>>>>
>>>>>>> Signed-off-by: Rob Clark 
>>>>>>> ---
>>>>>>> Background: there are a number of different folks working on getting
>>>>>>> upstream kernel working on various different phones/tablets with qcom
>>>>>>> SoC's.. many of them have command mode panels, so we kind of need a
>>>>>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>>>>>
>>>>>>> I know there is work on a proprer non-legacy atomic property for
>>>>>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>>>>>> be improved from triggering a full-frame flush once that is in
>>>>>>> place.  But we kinda needa a stop-gap solution.
>>>>>>>
>>>>>>> I had considered an in-driver solution for this, but things get a
>>>>>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>>>>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>>>>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>>>>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>>>>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>>>>>> is to wrap this up as an atomic commit and rely on the worker to
>>>>>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>>>>>
>>>>>>> I guess at least the helper, with some small addition to translate
>>>>>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>>>>>> rect property solution.  Depending on how far off that is, a stop-
>>>>>>> gap solution could be useful.
>>>>>>>
>>>>>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>>>>>> +
>>>>>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>>>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>>>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>>>>>  include/drm/drm_plane.h |  9 +
>>>>>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>> index c35654591c12..a578dc681b27 100644
>>>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>>> @@ -3504,6 +3504,7 @@ void 
>>>>>>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>>>>>> if (state->fb)
>>>>>>> drm_framebuffer_get(state->fb);
>>>>>>>
>>>>>>> +   state->dirty = false;
>>>>>>> state->fence = NULL;
>>>>>>> state->commit = NULL;
>>>>>>>  }
>>>>>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct 
>>>>>>> drm_crtc *crtc,
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>>>>>>>
>>>>>>> +/**
>>>>>>> + * drm_atomic_helper_dirtyfb - helper for dirtyfb
>>>>>>> + *
>>>>&g

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 13:37 schreef Rob Clark:
> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
> <maarten.lankho...@linux.intel.com> wrote:
>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>>>> rely on pageflips to trigger a flush to the panel).
>>>>>
>>>>> To signal to the driver that the async atomic update needs to
>>>>> synchronize with fences, even though the fb didn't change, the
>>>>> drm_atomic_state::dirty flag is added.
>>>>>
>>>>> Signed-off-by: Rob Clark <robdcl...@gmail.com>
>>>>> ---
>>>>> Background: there are a number of different folks working on getting
>>>>> upstream kernel working on various different phones/tablets with qcom
>>>>> SoC's.. many of them have command mode panels, so we kind of need a
>>>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>>>
>>>>> I know there is work on a proprer non-legacy atomic property for
>>>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>>>> be improved from triggering a full-frame flush once that is in
>>>>> place.  But we kinda needa a stop-gap solution.
>>>>>
>>>>> I had considered an in-driver solution for this, but things get a
>>>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>>>> is to wrap this up as an atomic commit and rely on the worker to
>>>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>>>
>>>>> I guess at least the helper, with some small addition to translate
>>>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>>>> rect property solution.  Depending on how far off that is, a stop-
>>>>> gap solution could be useful.
>>>>>
>>>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>>>> +
>>>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>>>  include/drm/drm_plane.h |  9 +
>>>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>>> index c35654591c12..a578dc681b27 100644
>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>> @@ -3504,6 +3504,7 @@ void 
>>>>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>>>> if (state->fb)
>>>>> drm_framebuffer_get(state->fb);
>>>>>
>>>>> +   state->dirty = false;
>>>>> state->fence = NULL;
>>>>> state->commit = NULL;
>>>>>  }
>>>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct 
>>>>> drm_crtc *crtc,
>>>>>  }
>>>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>>>>>
>>>>> +/**
>>>>> + * drm_atomic_helper_dirtyfb - helper for dirtyfb
>>>>> + *
>>>>> + * A helper to implement drm_framebuffer_funcs::dirty
>>>>> + */
>>>>> +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
>>>>> + struct drm_file *file_priv, unsigned flags,
>>>>> + unsigned color, struct drm_clip_rect *clips,
>>>>> + unsigned num_clips)
>>>>> +{
>>>>> +   struct drm_modeset_acquire_ctx ctx;
>>>>> +   struct drm_atomic_state *state;
>>>>> +   struct drm_plane *plane;
>&g

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 13:37 schreef Rob Clark:
> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
>  wrote:
>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>>>> rely on pageflips to trigger a flush to the panel).
>>>>>
>>>>> To signal to the driver that the async atomic update needs to
>>>>> synchronize with fences, even though the fb didn't change, the
>>>>> drm_atomic_state::dirty flag is added.
>>>>>
>>>>> Signed-off-by: Rob Clark 
>>>>> ---
>>>>> Background: there are a number of different folks working on getting
>>>>> upstream kernel working on various different phones/tablets with qcom
>>>>> SoC's.. many of them have command mode panels, so we kind of need a
>>>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>>>
>>>>> I know there is work on a proprer non-legacy atomic property for
>>>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>>>> be improved from triggering a full-frame flush once that is in
>>>>> place.  But we kinda needa a stop-gap solution.
>>>>>
>>>>> I had considered an in-driver solution for this, but things get a
>>>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>>>> is to wrap this up as an atomic commit and rely on the worker to
>>>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>>>
>>>>> I guess at least the helper, with some small addition to translate
>>>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>>>> rect property solution.  Depending on how far off that is, a stop-
>>>>> gap solution could be useful.
>>>>>
>>>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>>>> +
>>>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>>>  include/drm/drm_plane.h |  9 +
>>>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>>>> index c35654591c12..a578dc681b27 100644
>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>> @@ -3504,6 +3504,7 @@ void 
>>>>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>>>> if (state->fb)
>>>>> drm_framebuffer_get(state->fb);
>>>>>
>>>>> +   state->dirty = false;
>>>>> state->fence = NULL;
>>>>> state->commit = NULL;
>>>>>  }
>>>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct 
>>>>> drm_crtc *crtc,
>>>>>  }
>>>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>>>>>
>>>>> +/**
>>>>> + * drm_atomic_helper_dirtyfb - helper for dirtyfb
>>>>> + *
>>>>> + * A helper to implement drm_framebuffer_funcs::dirty
>>>>> + */
>>>>> +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
>>>>> + struct drm_file *file_priv, unsigned flags,
>>>>> + unsigned color, struct drm_clip_rect *clips,
>>>>> + unsigned num_clips)
>>>>> +{
>>>>> +   struct drm_modeset_acquire_ctx ctx;
>>>>> +   struct drm_atomic_state *state;
>>>>> +   struct drm_plane *plane;
>>>>> +   int ret = 0;
>>>>> +
>>&

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 12:21 schreef Daniel Vetter:
> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>> rely on pageflips to trigger a flush to the panel).
>>>
>>> To signal to the driver that the async atomic update needs to
>>> synchronize with fences, even though the fb didn't change, the
>>> drm_atomic_state::dirty flag is added.
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>> Background: there are a number of different folks working on getting
>>> upstream kernel working on various different phones/tablets with qcom
>>> SoC's.. many of them have command mode panels, so we kind of need a
>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>
>>> I know there is work on a proprer non-legacy atomic property for
>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>> be improved from triggering a full-frame flush once that is in
>>> place.  But we kinda needa a stop-gap solution.
>>>
>>> I had considered an in-driver solution for this, but things get a
>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>> is to wrap this up as an atomic commit and rely on the worker to
>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>
>>> I guess at least the helper, with some small addition to translate
>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>> rect property solution.  Depending on how far off that is, a stop-
>>> gap solution could be useful.
>>>
>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>> +
>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>  include/drm/drm_plane.h |  9 +
>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>> index c35654591c12..a578dc681b27 100644
>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>> @@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
>>> drm_plane *plane,
>>> if (state->fb)
>>> drm_framebuffer_get(state->fb);
>>>  
>>> +   state->dirty = false;
>>> state->fence = NULL;
>>> state->commit = NULL;
>>>  }
>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct 
>>> drm_crtc *crtc,
>>>  }
>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>>>  
>>> +/**
>>> + * drm_atomic_helper_dirtyfb - helper for dirtyfb
>>> + *
>>> + * A helper to implement drm_framebuffer_funcs::dirty
>>> + */
>>> +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
>>> + struct drm_file *file_priv, unsigned flags,
>>> + unsigned color, struct drm_clip_rect *clips,
>>> + unsigned num_clips)
>>> +{
>>> +   struct drm_modeset_acquire_ctx ctx;
>>> +   struct drm_atomic_state *state;
>>> +   struct drm_plane *plane;
>>> +   int ret = 0;
>>> +
>>> +   /*
>>> +* When called from ioctl, we are interruptable, but not when
>>> +* called internally (ie. defio worker)
>>> +*/
>>> +   drm_modeset_acquire_init(,
>>> +   file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
>>> +
>>> +   state = drm_atomic_state_alloc(fb->dev);
>>> +   if (!state) {
>>> +   ret = -ENOMEM;
>>> +   goto out;
>>> +   }
>>> +   state->acquire_ctx = 
>>> +
>>> +retry:
>>> +   drm_for_each_plane(plane, fb->dev) {
>>> +   struct drm_plane_state *plane_state;
>>> +
>>> +   if (plane->state->fb != fb)
>>> +   continue;
>>> +
>>> +   plane_state = drm_atomic_get_plane_state(state, plane);
>>> +   if (IS_ERR(plane_state)) {
>>> +   ret = PTR_ERR(plane_state);
>>> +   goto out;
>>> +   }
>>> +
>>> +   plane_state->dirty = true;
>>> +   }
>>> +
>>> +   ret = drm_atomic_nonblocking_commit(state);
>>> +
>>> +out:
>>> +   if (ret == -EDEADLK) {
>>> +   drm_atomic_state_clear(state);
>>> +   ret = drm_modeset_backoff();
>>> +   if (!ret)
>>> +   goto retry;
>>> +   }
>>> +
>>> +   drm_atomic_state_put(state);
>>> +
>>> +   drm_modeset_drop_locks();
>>> +   drm_modeset_acquire_fini();
>>> +
>>> +   return ret;
>>> +
>>> +}
>>> +EXPORT_SYMBOL(drm_atomic_helper_dirtyfb);
>>> +
>>>  /**
>>>   * __drm_atomic_helper_private_duplicate_state - 

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Maarten Lankhorst]

Op 04-04-18 om 12:21 schreef Daniel Vetter:
> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>> rely on pageflips to trigger a flush to the panel).
>>>
>>> To signal to the driver that the async atomic update needs to
>>> synchronize with fences, even though the fb didn't change, the
>>> drm_atomic_state::dirty flag is added.
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>> Background: there are a number of different folks working on getting
>>> upstream kernel working on various different phones/tablets with qcom
>>> SoC's.. many of them have command mode panels, so we kind of need a
>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>
>>> I know there is work on a proprer non-legacy atomic property for
>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>> be improved from triggering a full-frame flush once that is in
>>> place.  But we kinda needa a stop-gap solution.
>>>
>>> I had considered an in-driver solution for this, but things get a
>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>> is to wrap this up as an atomic commit and rely on the worker to
>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>
>>> I guess at least the helper, with some small addition to translate
>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>> rect property solution.  Depending on how far off that is, a stop-
>>> gap solution could be useful.
>>>
>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 
>>> +
>>>  drivers/gpu/drm/msm/msm_atomic.c|  5 ++-
>>>  drivers/gpu/drm/msm/msm_fb.c|  1 +
>>>  include/drm/drm_atomic_helper.h |  4 +++
>>>  include/drm/drm_plane.h |  9 +
>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>> index c35654591c12..a578dc681b27 100644
>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>> @@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
>>> drm_plane *plane,
>>> if (state->fb)
>>> drm_framebuffer_get(state->fb);
>>>  
>>> +   state->dirty = false;
>>> state->fence = NULL;
>>> state->commit = NULL;
>>>  }
>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct 
>>> drm_crtc *crtc,
>>>  }
>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>>>  
>>> +/**
>>> + * drm_atomic_helper_dirtyfb - helper for dirtyfb
>>> + *
>>> + * A helper to implement drm_framebuffer_funcs::dirty
>>> + */
>>> +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
>>> + struct drm_file *file_priv, unsigned flags,
>>> + unsigned color, struct drm_clip_rect *clips,
>>> + unsigned num_clips)
>>> +{
>>> +   struct drm_modeset_acquire_ctx ctx;
>>> +   struct drm_atomic_state *state;
>>> +   struct drm_plane *plane;
>>> +   int ret = 0;
>>> +
>>> +   /*
>>> +* When called from ioctl, we are interruptable, but not when
>>> +* called internally (ie. defio worker)
>>> +*/
>>> +   drm_modeset_acquire_init(,
>>> +   file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
>>> +
>>> +   state = drm_atomic_state_alloc(fb->dev);
>>> +   if (!state) {
>>> +   ret = -ENOMEM;
>>> +   goto out;
>>> +   }
>>> +   state->acquire_ctx = 
>>> +
>>> +retry:
>>> +   drm_for_each_plane(plane, fb->dev) {
>>> +   struct drm_plane_state *plane_state;
>>> +
>>> +   if (plane->state->fb != fb)
>>> +   continue;
>>> +
>>> +   plane_state = drm_atomic_get_plane_state(state, plane);
>>> +   if (IS_ERR(plane_state)) {
>>> +   ret = PTR_ERR(plane_state);
>>> +   goto out;
>>> +   }
>>> +
>>> +   plane_state->dirty = true;
>>> +   }
>>> +
>>> +   ret = drm_atomic_nonblocking_commit(state);
>>> +
>>> +out:
>>> +   if (ret == -EDEADLK) {
>>> +   drm_atomic_state_clear(state);
>>> +   ret = drm_modeset_backoff();
>>> +   if (!ret)
>>> +   goto retry;
>>> +   }
>>> +
>>> +   drm_atomic_state_put(state);
>>> +
>>> +   drm_modeset_drop_locks();
>>> +   drm_modeset_acquire_fini();
>>> +
>>> +   return ret;
>>> +
>>> +}
>>> +EXPORT_SYMBOL(drm_atomic_helper_dirtyfb);
>>> +
>>>  /**
>>>   * __drm_atomic_helper_private_duplicate_state - copy atomic private 

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Maarten Lankhorst]

Op 15-03-18 om 14:30 schreef Ville Syrjälä:
> On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
>> drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
>> arguments that can be removed by creating separate functins.
>>
>> Create specific functions for these calls to reduce x86/64 defconfig
>> size by ~20k.
>>
>> Modify the existing macros to use the specific calls.
>>
>> new:
>> $ size -t drivers/gpu/drm/built-in.a | tail -1
>> 187656244542 995 1922099  1d5433 (TOTALS)
>>
>> old:
>> $ size -t drivers/gpu/drm/built-in.a | tail -1
>> 189756544542 995 1943102  1da63e (TOTALS)
>>
>> Miscellanea:
>>
>> o intel_display requires a change to use the specific calls.
> How much would we lose if we move the (drm_debug) outside the
> functions again? I'm somewhat concerned about all the function call
> overhead when debugs aren't even enabled.

Upstream:
   textdata bss dec hex filename
 37714356894352  387184   5e870 drivers/gpu/drm/drm.ko

With this patch:
 37383156894352  383872   5db80 drivers/gpu/drm/drm.ko

Moving the if outside (below):
 37762956894352  387670   5ea56 drivers/gpu/drm/drm.ko

Bye savings..

I don't think there are any places in which the debug output is performance 
sensitive,
so I'm ok with not inlining.
---
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 79abf6d5b4db..928822403a59 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -89,14 +89,11 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
 }
 EXPORT_SYMBOL(drm_dev_printk);
 
-void drm_dbg(unsigned int category, const char *format, ...)
+void __drm_dbg(const char *format, ...)
 {
struct va_format vaf;
va_list args;
 
-   if (!(drm_debug & category))
-   return;
-
va_start(args, format);
vaf.fmt = format;
vaf.va = 
@@ -106,7 +103,7 @@ void drm_dbg(unsigned int category, const char *format, ...)
 
va_end(args);
 }
-EXPORT_SYMBOL(drm_dbg);
+EXPORT_SYMBOL(__drm_dbg);
 
 void drm_err(const char *format, ...)
 {
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 3a40c5a3a5fa..2a145b97bdfc 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -200,8 +200,17 @@ __printf(6, 7)
 void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
-__printf(2, 3)
-void drm_dbg(unsigned int category, const char *format, ...);
+
+__printf(1, 2)
+void __drm_dbg(const char *format, ...);
+
+
+#define drm_dbg(category, format, ...) \
+   do {\
+   if (drm_debug & category)   \
+   __drm_dbg(format, ## __VA_ARGS__);  \
+   } while (0)
+
 __printf(1, 2)
 void drm_err(const char *format, ...);
 

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Maarten Lankhorst]

Op 15-03-18 om 14:30 schreef Ville Syrjälä:
> On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
>> drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
>> arguments that can be removed by creating separate functins.
>>
>> Create specific functions for these calls to reduce x86/64 defconfig
>> size by ~20k.
>>
>> Modify the existing macros to use the specific calls.
>>
>> new:
>> $ size -t drivers/gpu/drm/built-in.a | tail -1
>> 187656244542 995 1922099  1d5433 (TOTALS)
>>
>> old:
>> $ size -t drivers/gpu/drm/built-in.a | tail -1
>> 189756544542 995 1943102  1da63e (TOTALS)
>>
>> Miscellanea:
>>
>> o intel_display requires a change to use the specific calls.
> How much would we lose if we move the (drm_debug) outside the
> functions again? I'm somewhat concerned about all the function call
> overhead when debugs aren't even enabled.

Upstream:
   textdata bss dec hex filename
 37714356894352  387184   5e870 drivers/gpu/drm/drm.ko

With this patch:
 37383156894352  383872   5db80 drivers/gpu/drm/drm.ko

Moving the if outside (below):
 37762956894352  387670   5ea56 drivers/gpu/drm/drm.ko

Bye savings..

I don't think there are any places in which the debug output is performance 
sensitive,
so I'm ok with not inlining.
---
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 79abf6d5b4db..928822403a59 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -89,14 +89,11 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
 }
 EXPORT_SYMBOL(drm_dev_printk);
 
-void drm_dbg(unsigned int category, const char *format, ...)
+void __drm_dbg(const char *format, ...)
 {
struct va_format vaf;
va_list args;
 
-   if (!(drm_debug & category))
-   return;
-
va_start(args, format);
vaf.fmt = format;
vaf.va = 
@@ -106,7 +103,7 @@ void drm_dbg(unsigned int category, const char *format, ...)
 
va_end(args);
 }
-EXPORT_SYMBOL(drm_dbg);
+EXPORT_SYMBOL(__drm_dbg);
 
 void drm_err(const char *format, ...)
 {
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 3a40c5a3a5fa..2a145b97bdfc 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -200,8 +200,17 @@ __printf(6, 7)
 void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
-__printf(2, 3)
-void drm_dbg(unsigned int category, const char *format, ...);
+
+__printf(1, 2)
+void __drm_dbg(const char *format, ...);
+
+
+#define drm_dbg(category, format, ...) \
+   do {\
+   if (drm_debug & category)   \
+   __drm_dbg(format, ## __VA_ARGS__);  \
+   } while (0)
+
 __printf(1, 2)
 void drm_err(const char *format, ...);
 

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Maarten Lankhorst]

Op 13-03-18 om 23:02 schreef Joe Perches:
> drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> arguments that can be removed by creating separate functins.
>
> Create specific functions for these calls to reduce x86/64 defconfig
> size by ~20k.
>
> Modify the existing macros to use the specific calls.
>
> new:
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 1876562 44542 995 1922099  1d5433 (TOTALS)
>
> old:
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 1897565 44542 995 1943102  1da63e (TOTALS)
>
> Miscellanea:
>
> o intel_display requires a change to use the specific calls.
>
> Signed-off-by: Joe Perches 
> ---
I guess this adds up. Nice reduction. :)


>  drivers/gpu/drm/drm_print.c  | 28 +---
>  drivers/gpu/drm/i915/intel_display.c | 15 ---
>  include/drm/drm_print.h  | 27 ++-
>  3 files changed, 39 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 781518fd88e3..79abf6d5b4db 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -89,23 +89,37 @@ void drm_dev_printk(const struct device *dev, const char 
> *level,
>  }
>  EXPORT_SYMBOL(drm_dev_printk);
>  
> -void drm_printk(const char *level, unsigned int category,
> - const char *format, ...)
> +void drm_dbg(unsigned int category, const char *format, ...)
>  {
>   struct va_format vaf;
>   va_list args;
>  
> - if (category != DRM_UT_NONE && !(drm_debug & category))
> + if (!(drm_debug & category))
>   return;
>  
>   va_start(args, format);
>   vaf.fmt = format;
>   vaf.va = 
>  
> - printk("%s" "[" DRM_NAME ":%ps]%s %pV",
> -level, __builtin_return_address(0),
> -strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", );
> + printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
> +__builtin_return_address(0), );
> +
> + va_end(args);
> +}
> +EXPORT_SYMBOL(drm_dbg);
> +
> +void drm_err(const char *format, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, format);
> + vaf.fmt = format;
> + vaf.va = 
> +
> + printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
> +__builtin_return_address(0), );
>  
>   va_end(args);
>  }
> -EXPORT_SYMBOL(drm_printk);
> +EXPORT_SYMBOL(drm_err);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2933ad38094f..d8e522e3cd39 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11059,24 +11059,17 @@ intel_compare_link_m_n(const struct intel_link_m_n 
> *m_n,
>  static void __printf(3, 4)
>  pipe_config_err(bool adjust, const char *name, const char *format, ...)
>  {
> - char *level;
> - unsigned int category;
>   struct va_format vaf;
>   va_list args;
>  
> - if (adjust) {
> - level = KERN_DEBUG;
> - category = DRM_UT_KMS;
> - } else {
> - level = KERN_ERR;
> - category = DRM_UT_NONE;
> - }
> -
>   va_start(args, format);
>   vaf.fmt = format;
>   vaf.va = 
>  
> - drm_printk(level, category, "mismatch in %s %pV", name, );
> + if (adjust)
> + drm_dbg(DRM_UT_KMS, "mismatch in %s %pV", name, );
> + else
> + drm_err("mismatch in %s %pV", name, );
Could this use DRM_DEBUG_KMS/DRM_ERROR?

Rest looks good, so I can fix up if you want.

~Maarten

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Maarten Lankhorst]

Op 13-03-18 om 23:02 schreef Joe Perches:
> drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> arguments that can be removed by creating separate functins.
>
> Create specific functions for these calls to reduce x86/64 defconfig
> size by ~20k.
>
> Modify the existing macros to use the specific calls.
>
> new:
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 1876562 44542 995 1922099  1d5433 (TOTALS)
>
> old:
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 1897565 44542 995 1943102  1da63e (TOTALS)
>
> Miscellanea:
>
> o intel_display requires a change to use the specific calls.
>
> Signed-off-by: Joe Perches 
> ---
I guess this adds up. Nice reduction. :)


>  drivers/gpu/drm/drm_print.c  | 28 +---
>  drivers/gpu/drm/i915/intel_display.c | 15 ---
>  include/drm/drm_print.h  | 27 ++-
>  3 files changed, 39 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 781518fd88e3..79abf6d5b4db 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -89,23 +89,37 @@ void drm_dev_printk(const struct device *dev, const char 
> *level,
>  }
>  EXPORT_SYMBOL(drm_dev_printk);
>  
> -void drm_printk(const char *level, unsigned int category,
> - const char *format, ...)
> +void drm_dbg(unsigned int category, const char *format, ...)
>  {
>   struct va_format vaf;
>   va_list args;
>  
> - if (category != DRM_UT_NONE && !(drm_debug & category))
> + if (!(drm_debug & category))
>   return;
>  
>   va_start(args, format);
>   vaf.fmt = format;
>   vaf.va = 
>  
> - printk("%s" "[" DRM_NAME ":%ps]%s %pV",
> -level, __builtin_return_address(0),
> -strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", );
> + printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
> +__builtin_return_address(0), );
> +
> + va_end(args);
> +}
> +EXPORT_SYMBOL(drm_dbg);
> +
> +void drm_err(const char *format, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, format);
> + vaf.fmt = format;
> + vaf.va = 
> +
> + printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
> +__builtin_return_address(0), );
>  
>   va_end(args);
>  }
> -EXPORT_SYMBOL(drm_printk);
> +EXPORT_SYMBOL(drm_err);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2933ad38094f..d8e522e3cd39 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11059,24 +11059,17 @@ intel_compare_link_m_n(const struct intel_link_m_n 
> *m_n,
>  static void __printf(3, 4)
>  pipe_config_err(bool adjust, const char *name, const char *format, ...)
>  {
> - char *level;
> - unsigned int category;
>   struct va_format vaf;
>   va_list args;
>  
> - if (adjust) {
> - level = KERN_DEBUG;
> - category = DRM_UT_KMS;
> - } else {
> - level = KERN_ERR;
> - category = DRM_UT_NONE;
> - }
> -
>   va_start(args, format);
>   vaf.fmt = format;
>   vaf.va = 
>  
> - drm_printk(level, category, "mismatch in %s %pV", name, );
> + if (adjust)
> + drm_dbg(DRM_UT_KMS, "mismatch in %s %pV", name, );
> + else
> + drm_err("mismatch in %s %pV", name, );
Could this use DRM_DEBUG_KMS/DRM_ERROR?

Rest looks good, so I can fix up if you want.

~Maarten

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Maarten Lankhorst]

Hey,

Op 21-02-18 om 15:37 schreef Rob Clark:
> Follow the same pattern of locking as with other state objects.  This
> avoids boilerplate in the driver.
I'm afraid this will prohibit any uses of this on i915, since it still uses 
legacy lock_all().

Oh well, afaict nothing in i915 uses private objects, so I don't think it's 
harmful. :)

Could you cc intel-gfx just in case?
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_atomic.c | 9 -
>  include/drm/drm_atomic.h | 5 +
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index fc8c4da409ff..004e621ab307 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct drm_private_obj *obj,
>  {
>   memset(obj, 0, sizeof(*obj));
>  
> + drm_modeset_lock_init(>lock);
> +
>   obj->state = state;
>   obj->funcs = funcs;
>  }
> @@ -1093,6 +1095,7 @@ void
>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
>  {
>   obj->funcs->atomic_destroy_state(obj, obj->state);
> + drm_modeset_lock_fini(>lock);
>  }
>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
>  
> @@ -1113,7 +1116,7 @@ struct drm_private_state *
>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
>struct drm_private_obj *obj)
>  {
> - int index, num_objs, i;
> + int index, num_objs, i, ret;
>   size_t size;
>   struct __drm_private_objs_state *arr;
>   struct drm_private_state *obj_state;
> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
> drm_atomic_state *state,
>   if (obj == state->private_objs[i].ptr)
>   return state->private_objs[i].state;
>  
> + ret = drm_modeset_lock(>lock, state->acquire_ctx);
> + if (ret)
> + return ERR_PTR(ret);
> +
>   num_objs = state->num_private_objs + 1;
>   size = sizeof(*state->private_objs) * num_objs;
>   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 09076a625637..9ae53b73c9d2 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
>   * _modeset_lock is required to duplicate and update this object's state.
>   */
>  struct drm_private_obj {
> + /**
> +  * @lock: Modeset lock to protect the state object.
> +  */
> + struct drm_modeset_lock lock;
> +
>   /**
>* @state: Current atomic state for this driver private object.
>*/

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Maarten Lankhorst]

Hey,

Op 21-02-18 om 15:37 schreef Rob Clark:
> Follow the same pattern of locking as with other state objects.  This
> avoids boilerplate in the driver.
I'm afraid this will prohibit any uses of this on i915, since it still uses 
legacy lock_all().

Oh well, afaict nothing in i915 uses private objects, so I don't think it's 
harmful. :)

Could you cc intel-gfx just in case?
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_atomic.c | 9 -
>  include/drm/drm_atomic.h | 5 +
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index fc8c4da409ff..004e621ab307 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct drm_private_obj *obj,
>  {
>   memset(obj, 0, sizeof(*obj));
>  
> + drm_modeset_lock_init(>lock);
> +
>   obj->state = state;
>   obj->funcs = funcs;
>  }
> @@ -1093,6 +1095,7 @@ void
>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
>  {
>   obj->funcs->atomic_destroy_state(obj, obj->state);
> + drm_modeset_lock_fini(>lock);
>  }
>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
>  
> @@ -1113,7 +1116,7 @@ struct drm_private_state *
>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
>struct drm_private_obj *obj)
>  {
> - int index, num_objs, i;
> + int index, num_objs, i, ret;
>   size_t size;
>   struct __drm_private_objs_state *arr;
>   struct drm_private_state *obj_state;
> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
> drm_atomic_state *state,
>   if (obj == state->private_objs[i].ptr)
>   return state->private_objs[i].state;
>  
> + ret = drm_modeset_lock(>lock, state->acquire_ctx);
> + if (ret)
> + return ERR_PTR(ret);
> +
>   num_objs = state->num_private_objs + 1;
>   size = sizeof(*state->private_objs) * num_objs;
>   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 09076a625637..9ae53b73c9d2 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
>   * _modeset_lock is required to duplicate and update this object's state.
>   */
>  struct drm_private_obj {
> + /**
> +  * @lock: Modeset lock to protect the state object.
> +  */
> + struct drm_modeset_lock lock;
> +
>   /**
>* @state: Current atomic state for this driver private object.
>*/

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

[Maarten Lankhorst]

Op 21-02-18 om 00:56 schreef Daniel Vetter:
> On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:
>> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:
>>> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
 On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
>> OK, but neither case would in fact need the !ctx case right? That's just
>> there for completeness sake?
> Unfortunately not. TTM uses trylock to lock BOs which are about to be
> evicted to make room for all the BOs locked with a ctx.
>
> I need to be able to distinct between the BOs which are trylocked and 
> those
> which are locked with a ctx.
>
> Writing this I actually noticed the current version is buggy, cause even
> when we check the mutex owner we still need to make sure that the ctx in 
> the
> lock is NULL.
 Hurm... I can't remember why trylocks behave like that, and it seems
 rather unfortunate / inconsistent.
>>> Actually for me that is rather fortunate, cause I need to distinct between
>>> the locks acquired through trylock and lock.
>> I suppose that would always be possible using:
>> ww_mutex_trylock(.ctx=NULL), and it could be that there simply weren't
>> any immediate uses for a !NULL trylock and it was thus not implemented.
>>
>> But that is all very long ago..
> I think we simple never had a use-case for interleaving ww_mutex_lock(ctx)
> and ww_mutex_trylock(ctx). Nesting multiple trylocks in ctx-locks happens
> plenty, but not further:
>
> The common use-case for that is locking a bunch of buffers you need (for
> command submission or whatever), and then trylocking other buffers to make
> space for the buffers you need to move into VRAM. I guess if only
> trylocking buffers doesn't succeed in freeing up enough VRAM then we could
> go into blocking ww_mutex_locks which need the ctx (and which would need
> all the trylock-acquired buffers to be annotated with the ctx too). TTM
> currently tries to be far enough away from that corner case (using a
> defensive "never use more than 50% of all memory for gfx" approach) that
> it doesn't seem to need that.
>
> Once we get there it should indeed be simply to add a ctx parameter to
> ww_mutex_trylock to fix this case. The TTM side rework is definitely going
> to be the much bigger issue here ...
> -Daniel

Yes, I think fixing trylock to take a ctx parameter would be a better fix than 
ww_mutex_is_owned_by..

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

[Maarten Lankhorst]

Op 21-02-18 om 00:56 schreef Daniel Vetter:
> On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:
>> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:
>>> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
 On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
>> OK, but neither case would in fact need the !ctx case right? That's just
>> there for completeness sake?
> Unfortunately not. TTM uses trylock to lock BOs which are about to be
> evicted to make room for all the BOs locked with a ctx.
>
> I need to be able to distinct between the BOs which are trylocked and 
> those
> which are locked with a ctx.
>
> Writing this I actually noticed the current version is buggy, cause even
> when we check the mutex owner we still need to make sure that the ctx in 
> the
> lock is NULL.
 Hurm... I can't remember why trylocks behave like that, and it seems
 rather unfortunate / inconsistent.
>>> Actually for me that is rather fortunate, cause I need to distinct between
>>> the locks acquired through trylock and lock.
>> I suppose that would always be possible using:
>> ww_mutex_trylock(.ctx=NULL), and it could be that there simply weren't
>> any immediate uses for a !NULL trylock and it was thus not implemented.
>>
>> But that is all very long ago..
> I think we simple never had a use-case for interleaving ww_mutex_lock(ctx)
> and ww_mutex_trylock(ctx). Nesting multiple trylocks in ctx-locks happens
> plenty, but not further:
>
> The common use-case for that is locking a bunch of buffers you need (for
> command submission or whatever), and then trylocking other buffers to make
> space for the buffers you need to move into VRAM. I guess if only
> trylocking buffers doesn't succeed in freeing up enough VRAM then we could
> go into blocking ww_mutex_locks which need the ctx (and which would need
> all the trylock-acquired buffers to be annotated with the ctx too). TTM
> currently tries to be far enough away from that corner case (using a
> defensive "never use more than 50% of all memory for gfx" approach) that
> it doesn't seem to need that.
>
> Once we get there it should indeed be simply to add a ctx parameter to
> ww_mutex_trylock to fix this case. The TTM side rework is definitely going
> to be the much bigger issue here ...
> -Daniel

Yes, I think fixing trylock to take a ctx parameter would be a better fix than 
ww_mutex_is_owned_by..

Re: 995d11c4c0 ("drm: rework delayed connector cleanup in .."): WARNING: possible circular locking dependency detected

[Maarten Lankhorst]

Op 18-12-17 om 08:08 schreef Daniel Vetter:
> Hm, the bisect looks funny. Only way I can explain that is that my
> patch fixed a pre-existing lockdep splat, and uncovered the issue in
> the ww-mutex self tests. That one is uncovered by the new
> cross-release lockdep checks in 4.15.
>
> Anyway I think this is an issue with the ww-mutex tests, not my patch
> (none of the code I touched is anywhere in the backtraces), adding
> relevant people.
> -Daniel
>
>
> On Sat, Dec 16, 2017 at 11:42 AM, kernel test robot
>  wrote:
>> Greetings,
>>
>> 0day kernel testing robot got the below dmesg and the first bad commit is
>>
>> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-rework-delayed-connector-cleanup-in-connector_iter/20171216-120456
>>
>> commit 995d11c4c0f1aa99d0f97fb747a4e0d04121cde2
>> Author: Daniel Vetter 
>> AuthorDate: Wed Dec 13 11:45:53 2017 +0100
>> Commit: 0day robot 
>> CommitDate: Sat Dec 16 12:04:58 2017 +0800
>>
>> drm: rework delayed connector cleanup in connector_iter
>>
>> PROBE_DEFER also uses system_wq to reprobe drivers, which means when
>> that again fails, and we try to flush the overall system_wq (to get
>> all the delayed connectore cleanup work_struct completed), we
>> deadlock.
>>
>> Fix this by using just a single cleanup work, so that we can only
>> flush that one and don't block on anything else. That means a free
>> list plus locking, a standard pattern.
>>
>> Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter")
>> Fixes: 613051dac40d ("drm: locking iterators for connector_list")
>> Cc: Ben Widawsky 
>> Cc: Dave Airlie 
>> Cc: Chris Wilson 
>> Cc: Sean Paul 
>> Cc:  # v4.11+: 613051dac40d ("drm: locking 
>> iterators for connector_list"
>> Cc:  # v4.11+
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Gustavo Padovan 
>> Cc: David Airlie 
>> Cc: Javier Martinez Canillas 
>> Cc: Shuah Khan 
>> Cc: Guillaume Tucker 
>> Cc: Mark Brown 
>> Cc: Kevin Hilman 
>> Cc: Matt Hart 
>> Cc: Thierry Escande 
>> Cc: Tomeu Vizoso 
>> Cc: Enric Balletbo i Serra 
>> Signed-off-by: Daniel Vetter 
>>
>> 50c4c4e268  Linux 4.15-rc3
>> 995d11c4c0  drm: rework delayed connector cleanup in connector_iter
>> +---+---++
>> |   | v4.15-rc3 | 
>> 995d11c4c0 |
>> +---+---++
>> | boot_successes| 1 | 0  
>> |
>> | boot_failures | 82| 15 
>> |
>> | WARNING:possible_circular_locking_dependency_detected | 82| 15 
>> |
>> | kernel_BUG_at_lib/list_debug.c| 0 | 15 
>> |
>> | invalid_opcode:#[##]  | 0 | 15 
>> |
>> | RIP:__list_add_valid  | 0 | 15 
>> |
>> | Kernel_panic-not_syncing:Fatal_exception  | 0 | 15 
>> |
>> +---+---++
>>
>> [3.252870] CPU feature 'AVX registers' is not supported.
>> [3.261404] AVX2 or AES-NI instructions are not detected.
>> [3.262708] AVX2 instructions are not detected.
>> [3.770347]
>> [3.773471] ==
>> [3.773471] WARNING: possible circular locking dependency detected
>> [3.773471] 4.15.0-rc3-1-g995d11c #1 Not tainted
>> [3.773471] --
>> [3.773471] swapper/0/1 is trying to acquire lock:
>> [3.773471]  (ww_class_mutex){+.+.}, at: [<134bc923>] 
>> test_abba+0x120/0x21e
>> [3.773471]
>> [3.773471] but now in release context of a crosslock acquired at the 
>> following:
>> [3.773471]  ((completion)_ready){+.+.}, at: [] 
>> test_abba_work+0x43/0xab
>> [3.773471]
>> [3.773471] which lock already depends on the new lock.
>> [3.773471]
>> [3.773471] the existing dependency chain (in reverse order) is:
>> [3.773471]
>> [3.773471] -> #1 ((completion)_ready){+.+.}:
>> [3.773471]__wait_for_common+0x55/0x1fe
>> [3.773471]  

Re: 995d11c4c0 ("drm: rework delayed connector cleanup in .."): WARNING: possible circular locking dependency detected

[Maarten Lankhorst]

Op 18-12-17 om 08:08 schreef Daniel Vetter:
> Hm, the bisect looks funny. Only way I can explain that is that my
> patch fixed a pre-existing lockdep splat, and uncovered the issue in
> the ww-mutex self tests. That one is uncovered by the new
> cross-release lockdep checks in 4.15.
>
> Anyway I think this is an issue with the ww-mutex tests, not my patch
> (none of the code I touched is anywhere in the backtraces), adding
> relevant people.
> -Daniel
>
>
> On Sat, Dec 16, 2017 at 11:42 AM, kernel test robot
>  wrote:
>> Greetings,
>>
>> 0day kernel testing robot got the below dmesg and the first bad commit is
>>
>> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-rework-delayed-connector-cleanup-in-connector_iter/20171216-120456
>>
>> commit 995d11c4c0f1aa99d0f97fb747a4e0d04121cde2
>> Author: Daniel Vetter 
>> AuthorDate: Wed Dec 13 11:45:53 2017 +0100
>> Commit: 0day robot 
>> CommitDate: Sat Dec 16 12:04:58 2017 +0800
>>
>> drm: rework delayed connector cleanup in connector_iter
>>
>> PROBE_DEFER also uses system_wq to reprobe drivers, which means when
>> that again fails, and we try to flush the overall system_wq (to get
>> all the delayed connectore cleanup work_struct completed), we
>> deadlock.
>>
>> Fix this by using just a single cleanup work, so that we can only
>> flush that one and don't block on anything else. That means a free
>> list plus locking, a standard pattern.
>>
>> Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter")
>> Fixes: 613051dac40d ("drm: locking iterators for connector_list")
>> Cc: Ben Widawsky 
>> Cc: Dave Airlie 
>> Cc: Chris Wilson 
>> Cc: Sean Paul 
>> Cc:  # v4.11+: 613051dac40d ("drm: locking 
>> iterators for connector_list"
>> Cc:  # v4.11+
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Gustavo Padovan 
>> Cc: David Airlie 
>> Cc: Javier Martinez Canillas 
>> Cc: Shuah Khan 
>> Cc: Guillaume Tucker 
>> Cc: Mark Brown 
>> Cc: Kevin Hilman 
>> Cc: Matt Hart 
>> Cc: Thierry Escande 
>> Cc: Tomeu Vizoso 
>> Cc: Enric Balletbo i Serra 
>> Signed-off-by: Daniel Vetter 
>>
>> 50c4c4e268  Linux 4.15-rc3
>> 995d11c4c0  drm: rework delayed connector cleanup in connector_iter
>> +---+---++
>> |   | v4.15-rc3 | 
>> 995d11c4c0 |
>> +---+---++
>> | boot_successes| 1 | 0  
>> |
>> | boot_failures | 82| 15 
>> |
>> | WARNING:possible_circular_locking_dependency_detected | 82| 15 
>> |
>> | kernel_BUG_at_lib/list_debug.c| 0 | 15 
>> |
>> | invalid_opcode:#[##]  | 0 | 15 
>> |
>> | RIP:__list_add_valid  | 0 | 15 
>> |
>> | Kernel_panic-not_syncing:Fatal_exception  | 0 | 15 
>> |
>> +---+---++
>>
>> [3.252870] CPU feature 'AVX registers' is not supported.
>> [3.261404] AVX2 or AES-NI instructions are not detected.
>> [3.262708] AVX2 instructions are not detected.
>> [3.770347]
>> [3.773471] ==
>> [3.773471] WARNING: possible circular locking dependency detected
>> [3.773471] 4.15.0-rc3-1-g995d11c #1 Not tainted
>> [3.773471] --
>> [3.773471] swapper/0/1 is trying to acquire lock:
>> [3.773471]  (ww_class_mutex){+.+.}, at: [<134bc923>] 
>> test_abba+0x120/0x21e
>> [3.773471]
>> [3.773471] but now in release context of a crosslock acquired at the 
>> following:
>> [3.773471]  ((completion)_ready){+.+.}, at: [] 
>> test_abba_work+0x43/0xab
>> [3.773471]
>> [3.773471] which lock already depends on the new lock.
>> [3.773471]
>> [3.773471] the existing dependency chain (in reverse order) is:
>> [3.773471]
>> [3.773471] -> #1 ((completion)_ready){+.+.}:
>> [3.773471]__wait_for_common+0x55/0x1fe
>> [3.773471]test_abba_work+0x43/0xab
>> [3.773471]process_one_work+0x1d4/0x310
>> [3.773471]worker_thread+0x1aa/0x25d
>> [3.773471]kthread+0x120/0x128
>> [3.773471]ret_from_fork+0x24/0x30
>> [3.773471]
>> [3.773471] -> #0 (ww_class_mutex){+.+.}:
>> [3.773471]test_abba+0x120/0x21e
>> [3.773471]test_ww_mutex_init+0x88/0x2fd
>> [3.773471]do_one_initcall+0x94/0x149
>> [3.773471]kernel_init_freeable+0x12a/0x1a6
>> [3.773471]kernel_init+0x5/0xe1
>> [

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 14-12-17 om 16:54 schreef Rafael J. Wysocki:
> On Thursday, December 14, 2017 4:52:22 PM CET Thomas Gleixner wrote:
>> On Thu, 14 Dec 2017, Rafael J. Wysocki wrote:
>>> The problem here is that pci_pm_thaw_noirq() calls pci_restore_state() which
>>> in fact requires the device to be in D0, so the caller should put it into
>>> D0 instead of trying to "update" its power state.
>>>
>>> [Note that the PCI layer doesn't put devices into low-power states during 
>>> the
>>> hibernation's "freeze" transition, but drivers can legitimately do that in
>>> their "freeze" callbacks which was overlooked in that code and that's what
>>> i915 does.]
>>>
>>> So IMO what we need is the change below.  I'm going to test it shortly,
>>> but please give it a go too.
>> So now this looks more reasonable:
>>
>>   irq_migrate_all_off_this_cpu: Mask 125 pci_msi_mask_irq+0x0/0x10
>>   __pci_write_msi_msg: :00:02.0 fee0100c 412a 
>>   __pci_write_msi_msg: Not written
>>   ...
>>   device_pm_callback_start: i915 :00:02.0, parent: pci:00, noirq bus 
>> [thaw]
>>   pci_pm_thaw_noirq <-dpm_run_callback
>>   __pci_write_msi_msg: :00:02.0 fee0100c 412a 
>>   device_pm_callback_end: i915 :00:02.0, err=0
>>   ...
>>   resume_irqs: Resume 125
>>   ...
>>   irq_handler_entry: irq=125 name=i915
> Cool.
>
> Let me respin it with a changelog etc then.
>
> Thanks,
> Rafael
>
>
The machine I was using for reproducing the bug appears to be fixed with this 
patch, so I now sent
it to intel's trybot for results.

https://patchwork.freedesktop.org/series/35367/

Thanks for looking at the bug!

~Maarten

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 14-12-17 om 16:54 schreef Rafael J. Wysocki:
> On Thursday, December 14, 2017 4:52:22 PM CET Thomas Gleixner wrote:
>> On Thu, 14 Dec 2017, Rafael J. Wysocki wrote:
>>> The problem here is that pci_pm_thaw_noirq() calls pci_restore_state() which
>>> in fact requires the device to be in D0, so the caller should put it into
>>> D0 instead of trying to "update" its power state.
>>>
>>> [Note that the PCI layer doesn't put devices into low-power states during 
>>> the
>>> hibernation's "freeze" transition, but drivers can legitimately do that in
>>> their "freeze" callbacks which was overlooked in that code and that's what
>>> i915 does.]
>>>
>>> So IMO what we need is the change below.  I'm going to test it shortly,
>>> but please give it a go too.
>> So now this looks more reasonable:
>>
>>   irq_migrate_all_off_this_cpu: Mask 125 pci_msi_mask_irq+0x0/0x10
>>   __pci_write_msi_msg: :00:02.0 fee0100c 412a 
>>   __pci_write_msi_msg: Not written
>>   ...
>>   device_pm_callback_start: i915 :00:02.0, parent: pci:00, noirq bus 
>> [thaw]
>>   pci_pm_thaw_noirq <-dpm_run_callback
>>   __pci_write_msi_msg: :00:02.0 fee0100c 412a 
>>   device_pm_callback_end: i915 :00:02.0, err=0
>>   ...
>>   resume_irqs: Resume 125
>>   ...
>>   irq_handler_entry: irq=125 name=i915
> Cool.
>
> Let me respin it with a changelog etc then.
>
> Thanks,
> Rafael
>
>
The machine I was using for reproducing the bug appears to be fixed with this 
patch, so I now sent
it to intel's trybot for results.

https://patchwork.freedesktop.org/series/35367/

Thanks for looking at the bug!

~Maarten

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Op 11-12-17 om 12:06 schreef Thomas Gleixner:
> On Mon, 11 Dec 2017, Thomas Gleixner wrote:
>
>> On Mon, 11 Dec 2017, Daniel Vetter wrote:
>>> Anything else we can do to move this? I just had to resolve a small
>>> conflict when moving forward to -rc3. Carrying a revert for the entire
>>> apic pull (too many deps to just revert the bisected patch) is a bit
>>> annoying.
>>   https://lkml.kernel.org/r/alpine.DEB.2.20.1712081129450.1840@nanos
> Another question. Is this broken on mainline or just with your new bits
> targeted for next?
>
> Thanks,
>
>   tglx

I'm on mainline, I can reproduce the do_IRQ: no irq handler for vector 4.33 
during a
normal suspend/resume cycle, but afaict dead irqs only showed up on hibernation 
fail. Not all
platforms supported on i915 seem affected, though I've sometimes also seen it 
affect
other drivers.. MEI iirc

Previous attempt with single s/r:

https://lkml.org/lkml/2017/12/6/215

swapoff -a
swapon /swapfile
echo disk > /sys/power/state

root@snb-2600:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq 


#|| / _--=> preempt-depth   


#||| / delay


#   TASK-PID   CPU#  TIMESTAMP  FUNCTION


#  | |   |      | | 


  -0 [000] d.h3  1240.663032: irq_matrix_alloc: bit=33 cpu=1 
online=1 avl=202 alloc=1 managed=0 online_maps=8 global_avl=1611, 
global_rsvd=15, total_alloc=13  
   
  -0 [000] d.h3  1240.663035: vector_update: irq=29 vector=33 
cpu=1 prev_vector=42 prev_cpu=0 

  -0 [000] d.h3  1240.663036: vector_alloc: irq=29 vector=33 
reserved=1 ret=0
 
  -0 [000] d.h3  1240.663037: vector_config: irq=29 vector=33 
cpu=1 apicdest=0x0002   

  -0 [000] d.H3  1240.663095: vector_free_moved: irq=29 cpu=0 
vector=42 is_managed=0  

  -0 [000] d.H3  1240.663096: irq_matrix_free: bit=42 cpu=0 
online=1 avl=196 alloc=7 managed=0 online_maps=8 global_avl=1612, 
global_rsvd=15, total_alloc=12  

  kworker/u16:21-1945  [005] d..1  1240.668553: vector_deactivate: irq=27 
is_managed=0 can_reserve=1 early=0  

  
  kworker/u16:21-1945  [005] d..2  1240.668560: vector_clear: irq=27 vector=40 
cpu=0 prev_vector=0 prev_cpu=0  
 
  kworker/u16:21-1945  [005] d..2  1240.668561: irq_matrix_free: bit=40 cpu=0 
online=1 avl=197 alloc=6 managed=0 online_maps=8 global_avl=1613, 
global_rsvd=15, total_alloc=11  

  kworker/u16:21-1945  [005] d..2  1240.668562: irq_matrix_reserve: 
online_maps=8 global_avl=1613, global_rsvd=16, total_alloc=11   


  kworker/u16:21-1945  [005] d..2  1240.668562: vector_reserve: irq=27 ret=0


  kworker/u16:21-1945  [005] d..2  

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Op 11-12-17 om 12:06 schreef Thomas Gleixner:
> On Mon, 11 Dec 2017, Thomas Gleixner wrote:
>
>> On Mon, 11 Dec 2017, Daniel Vetter wrote:
>>> Anything else we can do to move this? I just had to resolve a small
>>> conflict when moving forward to -rc3. Carrying a revert for the entire
>>> apic pull (too many deps to just revert the bisected patch) is a bit
>>> annoying.
>>   https://lkml.kernel.org/r/alpine.DEB.2.20.1712081129450.1840@nanos
> Another question. Is this broken on mainline or just with your new bits
> targeted for next?
>
> Thanks,
>
>   tglx

I'm on mainline, I can reproduce the do_IRQ: no irq handler for vector 4.33 
during a
normal suspend/resume cycle, but afaict dead irqs only showed up on hibernation 
fail. Not all
platforms supported on i915 seem affected, though I've sometimes also seen it 
affect
other drivers.. MEI iirc

Previous attempt with single s/r:

https://lkml.org/lkml/2017/12/6/215

swapoff -a
swapon /swapfile
echo disk > /sys/power/state

root@snb-2600:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq 


#|| / _--=> preempt-depth   


#||| / delay


#   TASK-PID   CPU#  TIMESTAMP  FUNCTION


#  | |   |      | | 


  -0 [000] d.h3  1240.663032: irq_matrix_alloc: bit=33 cpu=1 
online=1 avl=202 alloc=1 managed=0 online_maps=8 global_avl=1611, 
global_rsvd=15, total_alloc=13  
   
  -0 [000] d.h3  1240.663035: vector_update: irq=29 vector=33 
cpu=1 prev_vector=42 prev_cpu=0 

  -0 [000] d.h3  1240.663036: vector_alloc: irq=29 vector=33 
reserved=1 ret=0
 
  -0 [000] d.h3  1240.663037: vector_config: irq=29 vector=33 
cpu=1 apicdest=0x0002   

  -0 [000] d.H3  1240.663095: vector_free_moved: irq=29 cpu=0 
vector=42 is_managed=0  

  -0 [000] d.H3  1240.663096: irq_matrix_free: bit=42 cpu=0 
online=1 avl=196 alloc=7 managed=0 online_maps=8 global_avl=1612, 
global_rsvd=15, total_alloc=12  

  kworker/u16:21-1945  [005] d..1  1240.668553: vector_deactivate: irq=27 
is_managed=0 can_reserve=1 early=0  

  
  kworker/u16:21-1945  [005] d..2  1240.668560: vector_clear: irq=27 vector=40 
cpu=0 prev_vector=0 prev_cpu=0  
 
  kworker/u16:21-1945  [005] d..2  1240.668561: irq_matrix_free: bit=40 cpu=0 
online=1 avl=197 alloc=6 managed=0 online_maps=8 global_avl=1613, 
global_rsvd=15, total_alloc=11  

  kworker/u16:21-1945  [005] d..2  1240.668562: irq_matrix_reserve: 
online_maps=8 global_avl=1613, global_rsvd=16, total_alloc=11   


  kworker/u16:21-1945  [005] d..2  1240.668562: vector_reserve: irq=27 ret=0


  kworker/u16:21-1945  [005] d..2  

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 06-12-17 om 15:15 schreef Thomas Gleixner:
> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>> Op 06-12-17 om 13:46 schreef Thomas Gleixner:
>>> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>>>> Op 06-12-17 om 13:15 schreef Michal Hocko:
>>>>> "No irq handler" part looks a bit scary (maybe related to lost affinity
>>>>> messages?) but the following messages look quite as well. Is this
>>>>> something known? The system seems to be up and running without any
>>>>> visible issues.
>>>> Another reproducer for https://bugzilla.kernel.org/show_bug.cgi?id=198033 ?
>>>> Symptoms are similar..
>>> Well, the spurious interrupt is one thing, but you obviously lose
>>> interrupts for some reason.
>>>
>>> Did you ever manage to get the data out which I asked for?
>>>
>>> Thanks,
>>>
>>> tglx
>>>
>> Yes, sent this out about an hour ago
>>
>> https://lkml.org/lkml/2017/12/6/215
> Weird. Did not reach me
>
But do you have any idea?

~Maarten

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 06-12-17 om 15:15 schreef Thomas Gleixner:
> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>> Op 06-12-17 om 13:46 schreef Thomas Gleixner:
>>> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>>>> Op 06-12-17 om 13:15 schreef Michal Hocko:
>>>>> "No irq handler" part looks a bit scary (maybe related to lost affinity
>>>>> messages?) but the following messages look quite as well. Is this
>>>>> something known? The system seems to be up and running without any
>>>>> visible issues.
>>>> Another reproducer for https://bugzilla.kernel.org/show_bug.cgi?id=198033 ?
>>>> Symptoms are similar..
>>> Well, the spurious interrupt is one thing, but you obviously lose
>>> interrupts for some reason.
>>>
>>> Did you ever manage to get the data out which I asked for?
>>>
>>> Thanks,
>>>
>>> tglx
>>>
>> Yes, sent this out about an hour ago
>>
>> https://lkml.org/lkml/2017/12/6/215
> Weird. Did not reach me
>
But do you have any idea?

~Maarten

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 06-12-17 om 13:46 schreef Thomas Gleixner:
> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>> Op 06-12-17 om 13:15 schreef Michal Hocko:
>>> "No irq handler" part looks a bit scary (maybe related to lost affinity
>>> messages?) but the following messages look quite as well. Is this
>>> something known? The system seems to be up and running without any
>>> visible issues.
>> Another reproducer for https://bugzilla.kernel.org/show_bug.cgi?id=198033 ?
>> Symptoms are similar..
> Well, the spurious interrupt is one thing, but you obviously lose
> interrupts for some reason.
>
> Did you ever manage to get the data out which I asked for?
>
> Thanks,
>
>   tglx
>
Yes, sent this out about an hour ago

https://lkml.org/lkml/2017/12/6/215

Cheers,

Maarten

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 06-12-17 om 13:46 schreef Thomas Gleixner:
> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>> Op 06-12-17 om 13:15 schreef Michal Hocko:
>>> "No irq handler" part looks a bit scary (maybe related to lost affinity
>>> messages?) but the following messages look quite as well. Is this
>>> something known? The system seems to be up and running without any
>>> visible issues.
>> Another reproducer for https://bugzilla.kernel.org/show_bug.cgi?id=198033 ?
>> Symptoms are similar..
> Well, the spurious interrupt is one thing, but you obviously lose
> interrupts for some reason.
>
> Did you ever manage to get the data out which I asked for?
>
> Thanks,
>
>   tglx
>
Yes, sent this out about an hour ago

https://lkml.org/lkml/2017/12/6/215

Cheers,

Maarten

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 06-12-17 om 13:15 schreef Michal Hocko:
> On Mon 04-12-17 14:36:20, Linus Torvalds wrote:
>> On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki  wrote:
>>> So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the
>>> systems I have tested, so it is probably safe to assume it to be
>>> broken everywhere.
>> Oh, it's definitely not broken everywhere, because I use it myself,
>> and was traveling last week due to my mom's bday.
>>
>> HOWEVER.
>>
>> Some of the x86 work seems to have broken it for some configurations.
>> In particular, do you have a big "everything enabled" kernel config -
>> particularly lockdep and irqflags tracing enabled?
>>
>> Andy has a patch, but it hasn't made it to me yet (probably because
>> the x86 people are very busy with the kaiser work):
>>
>> https://lkml.org/lkml/2017/11/30/546
>>
>> (also note his follow-up "fix the commit message" note, but that one
>> doesn't actually affect the code itself).
> merging tip/x86/urgent on top of your tree fixed this problem for me,
> but I am seeing something else
> [  131.711412] ACPI: Preparing to enter system sleep state S3
> [  131.755328] ACPI: EC: event blocked
> [  131.755328] ACPI: EC: EC stopped
> [  131.755328] PM: Saving platform NVS memory
> [  131.755344] Disabling non-boot CPUs ...
> [  131.779330] IRQ 124: no longer affine to CPU1
> [  131.780334] smpboot: CPU 1 is now offline
> [  131.804465] smpboot: CPU 2 is now offline
> [  131.827291] IRQ 122: no longer affine to CPU3
> [  131.827292] IRQ 123: no longer affine to CPU3
> [  131.828293] smpboot: CPU 3 is now offline
> [  131.830991] ACPI: Low-level resume complete
> [  131.831092] ACPI: EC: EC started
> [  131.831093] PM: Restoring platform NVS memory
> [  131.831864] do_IRQ: 0.55 No irq handler for vector
> [  131.831884] Enabling non-boot CPUs ...
> [  131.831909] x86: Booting SMP configuration:
> [  131.831910] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [  131.832913]  cache: parent cpu1 should not be sleeping
> [  131.833058] CPU1 is up
> [  131.833067] smpboot: Booting Node 0 Processor 2 APIC 0x1
> [  131.833864]  cache: parent cpu2 should not be sleeping
> [  131.833983] CPU2 is up
> [  131.833995] smpboot: Booting Node 0 Processor 3 APIC 0x3
> [  131.834776]  cache: parent cpu3 should not be sleeping
> [  131.834923] CPU3 is up
>
> "No irq handler" part looks a bit scary (maybe related to lost affinity
> messages?) but the following messages look quite as well. Is this
> something known? The system seems to be up and running without any
> visible issues.

Another reproducer for https://bugzilla.kernel.org/show_bug.cgi?id=198033 ?
Symptoms are similar..

~Maarten

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Maarten Lankhorst]

Op 06-12-17 om 13:15 schreef Michal Hocko:
> On Mon 04-12-17 14:36:20, Linus Torvalds wrote:
>> On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki  wrote:
>>> So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the
>>> systems I have tested, so it is probably safe to assume it to be
>>> broken everywhere.
>> Oh, it's definitely not broken everywhere, because I use it myself,
>> and was traveling last week due to my mom's bday.
>>
>> HOWEVER.
>>
>> Some of the x86 work seems to have broken it for some configurations.
>> In particular, do you have a big "everything enabled" kernel config -
>> particularly lockdep and irqflags tracing enabled?
>>
>> Andy has a patch, but it hasn't made it to me yet (probably because
>> the x86 people are very busy with the kaiser work):
>>
>> https://lkml.org/lkml/2017/11/30/546
>>
>> (also note his follow-up "fix the commit message" note, but that one
>> doesn't actually affect the code itself).
> merging tip/x86/urgent on top of your tree fixed this problem for me,
> but I am seeing something else
> [  131.711412] ACPI: Preparing to enter system sleep state S3
> [  131.755328] ACPI: EC: event blocked
> [  131.755328] ACPI: EC: EC stopped
> [  131.755328] PM: Saving platform NVS memory
> [  131.755344] Disabling non-boot CPUs ...
> [  131.779330] IRQ 124: no longer affine to CPU1
> [  131.780334] smpboot: CPU 1 is now offline
> [  131.804465] smpboot: CPU 2 is now offline
> [  131.827291] IRQ 122: no longer affine to CPU3
> [  131.827292] IRQ 123: no longer affine to CPU3
> [  131.828293] smpboot: CPU 3 is now offline
> [  131.830991] ACPI: Low-level resume complete
> [  131.831092] ACPI: EC: EC started
> [  131.831093] PM: Restoring platform NVS memory
> [  131.831864] do_IRQ: 0.55 No irq handler for vector
> [  131.831884] Enabling non-boot CPUs ...
> [  131.831909] x86: Booting SMP configuration:
> [  131.831910] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [  131.832913]  cache: parent cpu1 should not be sleeping
> [  131.833058] CPU1 is up
> [  131.833067] smpboot: Booting Node 0 Processor 2 APIC 0x1
> [  131.833864]  cache: parent cpu2 should not be sleeping
> [  131.833983] CPU2 is up
> [  131.833995] smpboot: Booting Node 0 Processor 3 APIC 0x3
> [  131.834776]  cache: parent cpu3 should not be sleeping
> [  131.834923] CPU3 is up
>
> "No irq handler" part looks a bit scary (maybe related to lost affinity
> messages?) but the following messages look quite as well. Is this
> something known? The system seems to be up and running without any
> visible issues.

Another reproducer for https://bugzilla.kernel.org/show_bug.cgi?id=198033 ?
Symptoms are similar..

~Maarten

Re: [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Hey,

Op 30-11-17 om 23:47 schreef Thomas Gleixner:
> On Thu, 30 Nov 2017, Maarten Lankhorst wrote:
>> Op 30-11-17 om 10:18 schreef Thomas Gleixner:
>> # cat /sys/kernel/debug/irq/irqs/28 
>> handler:  handle_edge_irq
>> device:   :00:02.0
>> status:   0x
>> istate:   0x
>> ddepth:   0
>> wdepth:   0
>> dstate:   0x01401200
>> IRQD_ACTIVATED
>> IRQD_IRQ_STARTED
>> IRQD_SINGLE_TARGET
>> IRQD_AFFINITY_SET
>> node: 0
>> affinity: 4
>> effectiv: 4
>> pending:  
>> domain:  PCI-MSI-2
>>  hwirq:   0x8000
>>  chip:PCI-MSI
>>   flags:   0x10
>>  IRQCHIP_SKIP_SET_WAKE
>>  parent:
>> domain:  VECTOR
>>  hwirq:   0x1c
>>  chip:APIC
>>   flags:   0x0
> Ok. Fine. At that point the interrupt is assigned to CPU4
>
>> # cat /sys/kernel/debug/irq/irqs/28 
>> handler:  handle_edge_irq
>> device:   :00:02.0
>> status:   0x0400
>> _IRQ_NOPROBE
>> istate:   0x
>> ddepth:   0
>> wdepth:   0
>> dstate:   0x01401300
>> IRQD_ACTIVATED
>> IRQD_IRQ_STARTED
>> IRQD_SINGLE_TARGET
>> IRQD_AFFINITY_SET
>> IRQD_SETAFFINITY_PENDING
>> node: 0
>> affinity: 0,5-7
>> effectiv: 0
>> pending:  4
>> domain:  PCI-MSI-2
>>  hwirq:   0x8000
>>  chip:PCI-MSI
>>   flags:   0x10
>>  IRQCHIP_SKIP_SET_WAKE
>>  parent:
>> domain:  VECTOR
>>  hwirq:   0x1c
>>  chip:APIC
>>   flags:   0x0
> Now after suspend/resume it's affine to CPU 0 and a request to move it back
> to CPU4 is pending.
>
> That looks halfways sane, but:
>
>> affinity: 0,5-7
>> effectiv: 0
>> pending:  4
> does not make sense because 4 is not in 0,5-7
>
> Can you please enable the tracepoints:
>
> /sys/kernel/debug/tracing/events/irq_vectors/vector*
>
> and
>
> /sys/kernel/debug/tracing/events/irq_matrix/*
>
> and collect the trace from
>
> /sys/kernel/debug/trace
>
> right after resume or maybe after the timeout hit.
>
> That might not give us all required info, but at least it will allow me to
> come up with the necessary extras required. Right now I'm tapping in the
> dark

The problem happens during hibernate, but seems might happen during s/r too, 
just not necessarily dying..
Maybe a irq at the right moment is causing the unexpected "No irq handler for 
vector" ?

echo core > /sys/power/pm_test
echo mem > /sys/power/state

cat /sys/kernel/debug/irq/irqs/28:
affinity: 0,5-7
effectiv: 0
pending:  4

Same issue, just didn't cause the death yet.. interrupts still working as 
expected..

cat /sys/kernel/debug
  -0 [000] d.h3   862.035000: irq_matrix_alloc: bit=33 cpu=1 
online=1 avl=202 alloc=1 managed=0 online_maps=8 global_avl=1611, 
global_rsvd=15, total_alloc=13
  -0 [000] d.h3   862.035003: vector_update: irq=30 vector=33 
cpu=1 prev_vector=43 prev_cpu=0
  -0 [000] d.h3   862.035004: vector_alloc: irq=30 vector=33 
reserved=1 ret=0
  -0 [000] d.h3   862.035005: vector_config: irq=30 vector=33 
cpu=1 apicdest=0x0002
  -0 [000] d.h2   862.035065: vector_free_moved: irq=30 cpu=0 
vector=43 is_managed=0
  -0 [000] d.h2   862.035066: irq_matrix_free: bit=43 cpu=0 
online=1 avl=196 alloc=7 managed=0 online_maps=8 global_avl=1612, 
global_rsvd=15, total_alloc=12
   kworker/u16:2-149   [000] d..1   862.043955: vector_deactivate: irq=27 
is_managed=0 can_reserve=1 early=0
   kworker/u16:2-149   [000] d..2   862.043962: vector_clear: irq=27 vector=40 
cpu=0 prev_vector=0 prev_cpu=0
   kworker/u16:2-149   [000] d..2   862.043963: irq_matrix_free: bit=40 cpu=0 
online=1 avl=197 alloc=6 managed=0 online_maps=8 global_avl=1613, 
global_rsvd=15, total_alloc=11
   kworker/u16:2-149   [000] d..2   862.043964: irq_matrix_reserve: 
online_maps=8 global_avl=1613, global_rsvd=16, total_alloc=11
   kworker/u16:2-149   [000] d..2   862.043964: vector_reserve: irq=27 ret=0
   kworker/u16:2-149   [000] d..2   862.043965: vector_config: irq=27 
vector=239 cpu=0 apicdest=0x0001
   kworker/u16:2-149   [000] d..1   862.044428: vector_teardown: irq=27 
is_managed=0 has_reserved=1
   kworker/u16:2-149   [000] d..1   862.044429: irq_matrix_remove_reserved: 
online_maps=8 global_avl=1613, global_rsvd=15, total_alloc=11
   kworker/u16:5-1922  [001] d..1   862.049683: vector_deactivate: irq=30 
is_managed=0 can_reserve=1 early=0
   kworker/u16:5-1922  [001] d..2   862.049684: vector_clear: irq=30 vector=33 
cpu=1 prev_vector=0 prev_cpu=0
   kworker/u16:5-1922  [001

Re: [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Hey,

Op 30-11-17 om 23:47 schreef Thomas Gleixner:
> On Thu, 30 Nov 2017, Maarten Lankhorst wrote:
>> Op 30-11-17 om 10:18 schreef Thomas Gleixner:
>> # cat /sys/kernel/debug/irq/irqs/28 
>> handler:  handle_edge_irq
>> device:   :00:02.0
>> status:   0x
>> istate:   0x
>> ddepth:   0
>> wdepth:   0
>> dstate:   0x01401200
>> IRQD_ACTIVATED
>> IRQD_IRQ_STARTED
>> IRQD_SINGLE_TARGET
>> IRQD_AFFINITY_SET
>> node: 0
>> affinity: 4
>> effectiv: 4
>> pending:  
>> domain:  PCI-MSI-2
>>  hwirq:   0x8000
>>  chip:PCI-MSI
>>   flags:   0x10
>>  IRQCHIP_SKIP_SET_WAKE
>>  parent:
>> domain:  VECTOR
>>  hwirq:   0x1c
>>  chip:APIC
>>   flags:   0x0
> Ok. Fine. At that point the interrupt is assigned to CPU4
>
>> # cat /sys/kernel/debug/irq/irqs/28 
>> handler:  handle_edge_irq
>> device:   :00:02.0
>> status:   0x0400
>> _IRQ_NOPROBE
>> istate:   0x
>> ddepth:   0
>> wdepth:   0
>> dstate:   0x01401300
>> IRQD_ACTIVATED
>> IRQD_IRQ_STARTED
>> IRQD_SINGLE_TARGET
>> IRQD_AFFINITY_SET
>> IRQD_SETAFFINITY_PENDING
>> node: 0
>> affinity: 0,5-7
>> effectiv: 0
>> pending:  4
>> domain:  PCI-MSI-2
>>  hwirq:   0x8000
>>  chip:PCI-MSI
>>   flags:   0x10
>>  IRQCHIP_SKIP_SET_WAKE
>>  parent:
>> domain:  VECTOR
>>  hwirq:   0x1c
>>  chip:APIC
>>   flags:   0x0
> Now after suspend/resume it's affine to CPU 0 and a request to move it back
> to CPU4 is pending.
>
> That looks halfways sane, but:
>
>> affinity: 0,5-7
>> effectiv: 0
>> pending:  4
> does not make sense because 4 is not in 0,5-7
>
> Can you please enable the tracepoints:
>
> /sys/kernel/debug/tracing/events/irq_vectors/vector*
>
> and
>
> /sys/kernel/debug/tracing/events/irq_matrix/*
>
> and collect the trace from
>
> /sys/kernel/debug/trace
>
> right after resume or maybe after the timeout hit.
>
> That might not give us all required info, but at least it will allow me to
> come up with the necessary extras required. Right now I'm tapping in the
> dark

The problem happens during hibernate, but seems might happen during s/r too, 
just not necessarily dying..
Maybe a irq at the right moment is causing the unexpected "No irq handler for 
vector" ?

echo core > /sys/power/pm_test
echo mem > /sys/power/state

cat /sys/kernel/debug/irq/irqs/28:
affinity: 0,5-7
effectiv: 0
pending:  4

Same issue, just didn't cause the death yet.. interrupts still working as 
expected..

cat /sys/kernel/debug
  -0 [000] d.h3   862.035000: irq_matrix_alloc: bit=33 cpu=1 
online=1 avl=202 alloc=1 managed=0 online_maps=8 global_avl=1611, 
global_rsvd=15, total_alloc=13
  -0 [000] d.h3   862.035003: vector_update: irq=30 vector=33 
cpu=1 prev_vector=43 prev_cpu=0
  -0 [000] d.h3   862.035004: vector_alloc: irq=30 vector=33 
reserved=1 ret=0
  -0 [000] d.h3   862.035005: vector_config: irq=30 vector=33 
cpu=1 apicdest=0x0002
  -0 [000] d.h2   862.035065: vector_free_moved: irq=30 cpu=0 
vector=43 is_managed=0
  -0 [000] d.h2   862.035066: irq_matrix_free: bit=43 cpu=0 
online=1 avl=196 alloc=7 managed=0 online_maps=8 global_avl=1612, 
global_rsvd=15, total_alloc=12
   kworker/u16:2-149   [000] d..1   862.043955: vector_deactivate: irq=27 
is_managed=0 can_reserve=1 early=0
   kworker/u16:2-149   [000] d..2   862.043962: vector_clear: irq=27 vector=40 
cpu=0 prev_vector=0 prev_cpu=0
   kworker/u16:2-149   [000] d..2   862.043963: irq_matrix_free: bit=40 cpu=0 
online=1 avl=197 alloc=6 managed=0 online_maps=8 global_avl=1613, 
global_rsvd=15, total_alloc=11
   kworker/u16:2-149   [000] d..2   862.043964: irq_matrix_reserve: 
online_maps=8 global_avl=1613, global_rsvd=16, total_alloc=11
   kworker/u16:2-149   [000] d..2   862.043964: vector_reserve: irq=27 ret=0
   kworker/u16:2-149   [000] d..2   862.043965: vector_config: irq=27 
vector=239 cpu=0 apicdest=0x0001
   kworker/u16:2-149   [000] d..1   862.044428: vector_teardown: irq=27 
is_managed=0 has_reserved=1
   kworker/u16:2-149   [000] d..1   862.044429: irq_matrix_remove_reserved: 
online_maps=8 global_avl=1613, global_rsvd=15, total_alloc=11
   kworker/u16:5-1922  [001] d..1   862.049683: vector_deactivate: irq=30 
is_managed=0 can_reserve=1 early=0
   kworker/u16:5-1922  [001] d..2   862.049684: vector_clear: irq=30 vector=33 
cpu=1 prev_vector=0 prev_cpu=0
   kworker/u16:5-1922  [001

Re: WARNING: CPU: 1 PID: 185 at drivers/gpu/drm/i915/intel_display.c:14422 intel_modeset_init+0x3dc/0xf60 [i915]

[Maarten Lankhorst]

Op 30-11-17 om 14:15 schreef Fengguang Wu:
> Hello,
>
> This happens in mainline kernel v4.15-rc1 on LENOVO IdeaPad U410.
> It at least dates back to v4.11 .
>
> It occurs in 72 out of 72 boots.
Can I get a boot log with drm.debug=0x1f? I don't have enough information to 
see what's going on. :)

~Maarten

Re: WARNING: CPU: 1 PID: 185 at drivers/gpu/drm/i915/intel_display.c:14422 intel_modeset_init+0x3dc/0xf60 [i915]

[Maarten Lankhorst]

Op 30-11-17 om 14:15 schreef Fengguang Wu:
> Hello,
>
> This happens in mainline kernel v4.15-rc1 on LENOVO IdeaPad U410.
> It at least dates back to v4.11 .
>
> It occurs in 72 out of 72 boots.
Can I get a boot log with drm.debug=0x1f? I don't have enough information to 
see what's going on. :)

~Maarten

Re: [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Op 30-11-17 om 10:18 schreef Thomas Gleixner:
> Maarten,
>
> On Wed, 29 Nov 2017, Maarten Lankhorst wrote:
>> The changes to interrupts bring down our CI during hibernate, see:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=103712
>>
>> I created a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=198033
>>
>> Short reproducer:
>>
>> Create a swapfile on a snb 2600, attempt to hibernate to it with echo
>> disk > /sys/power/state, this will fail in the end, but will go through
>> most of the steps.
>>
>> After the almost complete hibernate, i915 will not receive irqs any more,
>> which kills our entire integration testing.
>>
>> Kernel config is available at
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3402/kernel.config.bz2
>> Results with pull request reverted at
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7333/shards.html
>>
>> First bad commit:
>>
>> commit fdba46ffb4c203b6e6794163493fd310f98bb4be (HEAD, refs/bisect/bad)
>> Author: Thomas Gleixner <t...@linutronix.de>
>> Date:   Wed Sep 13 23:29:27 2017 +0200
>>
>> x86/apic: Get rid of multi CPU affinity
>>
> < SNIP >
>> Could you have a look at it please?
> I had a look at it. Do I need to do anything else? :)
>
> Seriously. Can you please do the following:
>
> 1) Enable CONFIG_GENERIC_IRQ_DEBUGFS
>
> 2) mount debugfs
>
> 3) Before suspend collect information from there
>
>cat /sys/kernel/debug/irq/domains/*
>
>and
>
>cat /sys/kernel/debug/irq/irqs/$N
>
>where $N is the interrupt which does not fire anymore
>
> 4) suspend/resume
>
> 5) Collect the same data as in #3

/proc/interrupts:
   CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   
CPU6   CPU7   
 28:999  0  0  0 29  0  
0  0   PCI-MSI 32768-edge  i915

# grep . /sys/kernel/debug/irq/domains/*
/sys/kernel/debug/irq/domains/default:name:   VECTOR
/sys/kernel/debug/irq/domains/default: size:   0
/sys/kernel/debug/irq/domains/default: mapped: 27
/sys/kernel/debug/irq/domains/default: flags:  0x0041
/sys/kernel/debug/irq/domains/IO-APIC-0:name:   IO-APIC-0
/sys/kernel/debug/irq/domains/IO-APIC-0: size:   24
/sys/kernel/debug/irq/domains/IO-APIC-0: mapped: 20
/sys/kernel/debug/irq/domains/IO-APIC-0: flags:  0x0041
/sys/kernel/debug/irq/domains/IO-APIC-0: parent: VECTOR
/sys/kernel/debug/irq/domains/IO-APIC-0:name:   VECTOR
/sys/kernel/debug/irq/domains/IO-APIC-0: size:   0
/sys/kernel/debug/irq/domains/IO-APIC-0: mapped: 27
/sys/kernel/debug/irq/domains/IO-APIC-0: flags:  0x0041
/sys/kernel/debug/irq/domains/PCI-HT:name:   PCI-HT
/sys/kernel/debug/irq/domains/PCI-HT: size:   0
/sys/kernel/debug/irq/domains/PCI-HT: mapped: 0
/sys/kernel/debug/irq/domains/PCI-HT: flags:  0x0041
/sys/kernel/debug/irq/domains/PCI-HT: parent: VECTOR
/sys/kernel/debug/irq/domains/PCI-HT:name:   VECTOR
/sys/kernel/debug/irq/domains/PCI-HT: size:   0
/sys/kernel/debug/irq/domains/PCI-HT: mapped: 27
/sys/kernel/debug/irq/domains/PCI-HT: flags:  0x0041
/sys/kernel/debug/irq/domains/PCI-MSI-2:name:   PCI-MSI-2
/sys/kernel/debug/irq/domains/PCI-MSI-2: size:   0
/sys/kernel/debug/irq/domains/PCI-MSI-2: mapped: 7
/sys/kernel/debug/irq/domains/PCI-MSI-2: flags:  0x0051
/sys/kernel/debug/irq/domains/PCI-MSI-2: parent: VECTOR
/sys/kernel/debug/irq/domains/PCI-MSI-2:name:   VECTOR
/sys/kernel/debug/irq/domains/PCI-MSI-2: size:   0
/sys/kernel/debug/irq/domains/PCI-MSI-2: mapped: 27
/sys/kernel/debug/irq/domains/PCI-MSI-2: flags:  0x0041
/sys/kernel/debug/irq/domains/VECTOR:name:   VECTOR
/sys/kernel/debug/irq/domains/VECTOR: size:   0
/sys/kernel/debug/irq/domains/VECTOR: mapped: 27
/sys/kernel/debug/irq/domains/VECTOR: flags:  0x0041


# cat /sys/kernel/debug/irq/irqs/28 
handler:  handle_edge_irq
device:   :00:02.0
status:   0x
istate:   0x
ddepth:   0
wdepth:   0
dstate:   0x01401200
IRQD_ACTIVATED
IRQD_IRQ_STARTED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_SET
node: 0
affinity: 4
effectiv: 4
pending:  
domain:  PCI-MSI-2
 hwirq:   0x8000
 chip:PCI-MSI
  flags:   0x10
 IRQCHIP_SKIP_SET_WAKE
 parent:
domain:  VECTOR
 hwirq:   0x1c
 chip:APIC
  flags:   0x0



# grep . /sys/kernel/debug/irq/domains/*
/sys/kernel/debug/irq/domains/default:name:   VECTOR
/sys/kernel/debug/irq/domains/default: size:   0
/sys/kernel/debug/irq/domains/default: mapped: 27
/sys/kernel/debug/irq/domains/default: flags:  0x0041
/sys/kernel/debug/irq/domains/IO-APIC-0:name:   IO-APIC-0
/sys/kernel/debug/irq/domains/IO-APIC-0: size:   24
/sys/kernel/debug/irq/domains/IO-APIC-0

Re: [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Op 30-11-17 om 10:18 schreef Thomas Gleixner:
> Maarten,
>
> On Wed, 29 Nov 2017, Maarten Lankhorst wrote:
>> The changes to interrupts bring down our CI during hibernate, see:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=103712
>>
>> I created a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=198033
>>
>> Short reproducer:
>>
>> Create a swapfile on a snb 2600, attempt to hibernate to it with echo
>> disk > /sys/power/state, this will fail in the end, but will go through
>> most of the steps.
>>
>> After the almost complete hibernate, i915 will not receive irqs any more,
>> which kills our entire integration testing.
>>
>> Kernel config is available at
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3402/kernel.config.bz2
>> Results with pull request reverted at
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7333/shards.html
>>
>> First bad commit:
>>
>> commit fdba46ffb4c203b6e6794163493fd310f98bb4be (HEAD, refs/bisect/bad)
>> Author: Thomas Gleixner 
>> Date:   Wed Sep 13 23:29:27 2017 +0200
>>
>> x86/apic: Get rid of multi CPU affinity
>>
> < SNIP >
>> Could you have a look at it please?
> I had a look at it. Do I need to do anything else? :)
>
> Seriously. Can you please do the following:
>
> 1) Enable CONFIG_GENERIC_IRQ_DEBUGFS
>
> 2) mount debugfs
>
> 3) Before suspend collect information from there
>
>cat /sys/kernel/debug/irq/domains/*
>
>and
>
>cat /sys/kernel/debug/irq/irqs/$N
>
>where $N is the interrupt which does not fire anymore
>
> 4) suspend/resume
>
> 5) Collect the same data as in #3

/proc/interrupts:
   CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   
CPU6   CPU7   
 28:999  0  0  0 29  0  
0  0   PCI-MSI 32768-edge  i915

# grep . /sys/kernel/debug/irq/domains/*
/sys/kernel/debug/irq/domains/default:name:   VECTOR
/sys/kernel/debug/irq/domains/default: size:   0
/sys/kernel/debug/irq/domains/default: mapped: 27
/sys/kernel/debug/irq/domains/default: flags:  0x0041
/sys/kernel/debug/irq/domains/IO-APIC-0:name:   IO-APIC-0
/sys/kernel/debug/irq/domains/IO-APIC-0: size:   24
/sys/kernel/debug/irq/domains/IO-APIC-0: mapped: 20
/sys/kernel/debug/irq/domains/IO-APIC-0: flags:  0x0041
/sys/kernel/debug/irq/domains/IO-APIC-0: parent: VECTOR
/sys/kernel/debug/irq/domains/IO-APIC-0:name:   VECTOR
/sys/kernel/debug/irq/domains/IO-APIC-0: size:   0
/sys/kernel/debug/irq/domains/IO-APIC-0: mapped: 27
/sys/kernel/debug/irq/domains/IO-APIC-0: flags:  0x0041
/sys/kernel/debug/irq/domains/PCI-HT:name:   PCI-HT
/sys/kernel/debug/irq/domains/PCI-HT: size:   0
/sys/kernel/debug/irq/domains/PCI-HT: mapped: 0
/sys/kernel/debug/irq/domains/PCI-HT: flags:  0x0041
/sys/kernel/debug/irq/domains/PCI-HT: parent: VECTOR
/sys/kernel/debug/irq/domains/PCI-HT:name:   VECTOR
/sys/kernel/debug/irq/domains/PCI-HT: size:   0
/sys/kernel/debug/irq/domains/PCI-HT: mapped: 27
/sys/kernel/debug/irq/domains/PCI-HT: flags:  0x0041
/sys/kernel/debug/irq/domains/PCI-MSI-2:name:   PCI-MSI-2
/sys/kernel/debug/irq/domains/PCI-MSI-2: size:   0
/sys/kernel/debug/irq/domains/PCI-MSI-2: mapped: 7
/sys/kernel/debug/irq/domains/PCI-MSI-2: flags:  0x0051
/sys/kernel/debug/irq/domains/PCI-MSI-2: parent: VECTOR
/sys/kernel/debug/irq/domains/PCI-MSI-2:name:   VECTOR
/sys/kernel/debug/irq/domains/PCI-MSI-2: size:   0
/sys/kernel/debug/irq/domains/PCI-MSI-2: mapped: 27
/sys/kernel/debug/irq/domains/PCI-MSI-2: flags:  0x0041
/sys/kernel/debug/irq/domains/VECTOR:name:   VECTOR
/sys/kernel/debug/irq/domains/VECTOR: size:   0
/sys/kernel/debug/irq/domains/VECTOR: mapped: 27
/sys/kernel/debug/irq/domains/VECTOR: flags:  0x0041


# cat /sys/kernel/debug/irq/irqs/28 
handler:  handle_edge_irq
device:   :00:02.0
status:   0x
istate:   0x
ddepth:   0
wdepth:   0
dstate:   0x01401200
IRQD_ACTIVATED
IRQD_IRQ_STARTED
IRQD_SINGLE_TARGET
IRQD_AFFINITY_SET
node: 0
affinity: 4
effectiv: 4
pending:  
domain:  PCI-MSI-2
 hwirq:   0x8000
 chip:PCI-MSI
  flags:   0x10
 IRQCHIP_SKIP_SET_WAKE
 parent:
domain:  VECTOR
 hwirq:   0x1c
 chip:APIC
  flags:   0x0



# grep . /sys/kernel/debug/irq/domains/*
/sys/kernel/debug/irq/domains/default:name:   VECTOR
/sys/kernel/debug/irq/domains/default: size:   0
/sys/kernel/debug/irq/domains/default: mapped: 27
/sys/kernel/debug/irq/domains/default: flags:  0x0041
/sys/kernel/debug/irq/domains/IO-APIC-0:name:   IO-APIC-0
/sys/kernel/debug/irq/domains/IO-APIC-0: size:   24
/sys/kernel/debug/irq/domains/IO-APIC-0: mapped: 20
/sys/kernel

Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

[Maarten Lankhorst]

Op 28-11-17 om 16:13 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Daniel Vetter wrote:
>
>> On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
>>> Some drivers like i915 start with crtc's enabled, but with deferred
>>> fbcon setup they were no longer disabled as part of fbdev setup.
>>> Headless units could no longer enter pc3 state because the crtc was
>>> still enabled.
>>>
>>> Fix this by calling restore_fbdev_mode when we would have called
>>> it otherwise once during initial fbdev setup.
>>>
>>> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
>>> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
>>
>> Please use dim fixes to get a more complete Cc: list for regression fixes.
>>
>>> Cc: <sta...@vger.kernel.org> # v4.14+
>>> Reported-by: Thomas Voegtle <t...@lio96.de>
>>
>> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>>
>> But please confirm with the reporter that it indeed fixes the issue before
>> pushing.
>> -Daniel
>
> I re-checked the latest version of the patch and it indeed fixes the problem.
>
> Thanks,
>
>    Thomas
>
Pushed, thanks for the report. :)

~Maarten

Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

[Maarten Lankhorst]

Op 28-11-17 om 16:13 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Daniel Vetter wrote:
>
>> On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
>>> Some drivers like i915 start with crtc's enabled, but with deferred
>>> fbcon setup they were no longer disabled as part of fbdev setup.
>>> Headless units could no longer enter pc3 state because the crtc was
>>> still enabled.
>>>
>>> Fix this by calling restore_fbdev_mode when we would have called
>>> it otherwise once during initial fbdev setup.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
>>
>> Please use dim fixes to get a more complete Cc: list for regression fixes.
>>
>>> Cc:  # v4.14+
>>> Reported-by: Thomas Voegtle 
>>
>> Reviewed-by: Daniel Vetter 
>>
>> But please confirm with the reporter that it indeed fixes the issue before
>> pushing.
>> -Daniel
>
> I re-checked the latest version of the patch and it indeed fixes the problem.
>
> Thanks,
>
>    Thomas
>
Pushed, thanks for the report. :)

~Maarten

Re: [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Hey,

Op 13-11-17 om 13:05 schreef Thomas Gleixner:
> Linus,
>
> please pull the latest x86-apic-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> x86-apic-for-linus
>
> This update provides a major overhaul of the APIC initialization and vector
> allocation code:
>
>   - Unification of the APIC and interrupt mode setup which was scattered
> all over the place and was hard to follow. This also distangles the
> timer setup from the APIC initialization which brings a clear
> separation of functionality.
>
> Great detective work from Dou Lyiang!
>
>   - Refactoring of the x86 vector allocation mechanism. The existing code
> was based on nested loops and rather convoluted APIC callbacks which
> had a horrible worst case behaviour and tried to serve all different
> use cases in one go. This led to quite odd hacks when supporting the
> new managed interupt facility for multiqueue devices and made it more
> or less impossible to deal with the vector space exhaustion which was a
> major roadblock for server hibernation.
>
> Aside of that the code dealing with cpu hotplug and the system vectors
> was disconnected from the actual vector management and allocation code,
> which made it hard to follow and maintain.
>
> Utilizing the new bitmap matrix allocator core mechanism, the new
> allocator and management code consolidates the handling of system
> vectors, legacy vectors, cpu hotplug mechanisms and the actual
> allocation which needs to be aware of system and legacy vectors and
> hotplug constraints into a single consistent entity.
>
> This has one visible change: The support for multi CPU targets of
> interrupts, which is only available on a certain subset of CPUs/APIC
> variants has been removed in favour of single interrupt targets. A
> proper analysis of the multi CPU target feature revealed that there is
> no real advantage as the vast majority of interrupts end up on the CPU
> with the lowest APIC id in the set of target CPUs anyway. That change
> was agreed on by the relevant folks and allowed to simplify the
> implementation significantly and to replace rather fragile constructs
> like the vector cleanup IPI with straight forward and solid code.
> 
> Furthermore this allowed to cleanly separate the allocation details for
> legacy, normal and managed interrupts.
>
>  - Legacy interrupts are not longer wasting 16 vectors unconditionally
>
>  - Managed interrupts have now a guaranteed vector reservation, but the
>actual vector assignment happens when the interrupt is
>requested. It's guaranteed not to fail.
>
>  - Normal interrupts no longer allocate vectors unconditionally when
>the interrupt is set up (IO/APIC init or MSI(X) enable). The
>mechanism has been switched to a best effort reservation mode. The
>actual allocation happens when the interrupt is requested. Contrary
>to managed interrupts the request can fail due to vector space
>exhaustion, but drivers must handle a fail of request_irq()
>anyway. When the interrupt is freed, the vector is handed back as
>well.
>
>This solves a long standing problem with large unconditional
>vector allocations for a certain class of enterprise devices which
>prevented server hibernation due to vector space exhaustion when the
>unused allocated vectors had to be migrated to CPU0 while unplugging
>all non boot CPUs.
>
> The code has been equipped with trace points and detailed debugfs
> information to aid analysis of the vector space.
>
The changes to interrupts bring down our CI during hibernate, see:

https://bugs.freedesktop.org/show_bug.cgi?id=103712

I created a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=198033

Short reproducer:

Create a swapfile on a snb 2600, attempt to hibernate to it with echo disk > 
/sys/power/state, this will fail in the end, but will go through most of the 
steps.

After the almost complete hibernate, i915 will not receive irqs any more, which 
kills our entire integration testing.

Kernel config is available at 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3402/kernel.config.bz2
Results with pull request reverted at 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7333/shards.html

First bad commit:

commit fdba46ffb4c203b6e6794163493fd310f98bb4be (HEAD, refs/bisect/bad)
Author: Thomas Gleixner 
Date:   Wed Sep 13 23:29:27 2017 +0200

x86/apic: Get rid of multi CPU affinity

dmesg:
[   25.419245] PM: hibernation entry
[   25.420957] PM: Syncing filesystems ... 
[   25.464097] PM: done.
[   25.464150] Freezing user space processes ... (elapsed 0.006 seconds) done.
[   25.470453] OOM killer disabled.
[   25.470822] PM: Marking nosave pages: [mem 0x-0x0fff]
[   25.470844] PM: Marking nosave 

Re: [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Hey,

Op 13-11-17 om 13:05 schreef Thomas Gleixner:
> Linus,
>
> please pull the latest x86-apic-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> x86-apic-for-linus
>
> This update provides a major overhaul of the APIC initialization and vector
> allocation code:
>
>   - Unification of the APIC and interrupt mode setup which was scattered
> all over the place and was hard to follow. This also distangles the
> timer setup from the APIC initialization which brings a clear
> separation of functionality.
>
> Great detective work from Dou Lyiang!
>
>   - Refactoring of the x86 vector allocation mechanism. The existing code
> was based on nested loops and rather convoluted APIC callbacks which
> had a horrible worst case behaviour and tried to serve all different
> use cases in one go. This led to quite odd hacks when supporting the
> new managed interupt facility for multiqueue devices and made it more
> or less impossible to deal with the vector space exhaustion which was a
> major roadblock for server hibernation.
>
> Aside of that the code dealing with cpu hotplug and the system vectors
> was disconnected from the actual vector management and allocation code,
> which made it hard to follow and maintain.
>
> Utilizing the new bitmap matrix allocator core mechanism, the new
> allocator and management code consolidates the handling of system
> vectors, legacy vectors, cpu hotplug mechanisms and the actual
> allocation which needs to be aware of system and legacy vectors and
> hotplug constraints into a single consistent entity.
>
> This has one visible change: The support for multi CPU targets of
> interrupts, which is only available on a certain subset of CPUs/APIC
> variants has been removed in favour of single interrupt targets. A
> proper analysis of the multi CPU target feature revealed that there is
> no real advantage as the vast majority of interrupts end up on the CPU
> with the lowest APIC id in the set of target CPUs anyway. That change
> was agreed on by the relevant folks and allowed to simplify the
> implementation significantly and to replace rather fragile constructs
> like the vector cleanup IPI with straight forward and solid code.
> 
> Furthermore this allowed to cleanly separate the allocation details for
> legacy, normal and managed interrupts.
>
>  - Legacy interrupts are not longer wasting 16 vectors unconditionally
>
>  - Managed interrupts have now a guaranteed vector reservation, but the
>actual vector assignment happens when the interrupt is
>requested. It's guaranteed not to fail.
>
>  - Normal interrupts no longer allocate vectors unconditionally when
>the interrupt is set up (IO/APIC init or MSI(X) enable). The
>mechanism has been switched to a best effort reservation mode. The
>actual allocation happens when the interrupt is requested. Contrary
>to managed interrupts the request can fail due to vector space
>exhaustion, but drivers must handle a fail of request_irq()
>anyway. When the interrupt is freed, the vector is handed back as
>well.
>
>This solves a long standing problem with large unconditional
>vector allocations for a certain class of enterprise devices which
>prevented server hibernation due to vector space exhaustion when the
>unused allocated vectors had to be migrated to CPU0 while unplugging
>all non boot CPUs.
>
> The code has been equipped with trace points and detailed debugfs
> information to aid analysis of the vector space.
>
The changes to interrupts bring down our CI during hibernate, see:

https://bugs.freedesktop.org/show_bug.cgi?id=103712

I created a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=198033

Short reproducer:

Create a swapfile on a snb 2600, attempt to hibernate to it with echo disk > 
/sys/power/state, this will fail in the end, but will go through most of the 
steps.

After the almost complete hibernate, i915 will not receive irqs any more, which 
kills our entire integration testing.

Kernel config is available at 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3402/kernel.config.bz2
Results with pull request reverted at 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7333/shards.html

First bad commit:

commit fdba46ffb4c203b6e6794163493fd310f98bb4be (HEAD, refs/bisect/bad)
Author: Thomas Gleixner 
Date:   Wed Sep 13 23:29:27 2017 +0200

x86/apic: Get rid of multi CPU affinity

dmesg:
[   25.419245] PM: hibernation entry
[   25.420957] PM: Syncing filesystems ... 
[   25.464097] PM: done.
[   25.464150] Freezing user space processes ... (elapsed 0.006 seconds) done.
[   25.470453] OOM killer disabled.
[   25.470822] PM: Marking nosave pages: [mem 0x-0x0fff]
[   25.470844] PM: Marking nosave pages: [mem 

[PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

[Maarten Lankhorst]

Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.

Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.

Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Cc: <sta...@vger.kernel.org> # v4.14+
Reported-by: Thomas Voegtle <t...@lio96.de>
---
 drivers/gpu/drm/drm_fb_helper.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 07374008f146..e56166334455 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
 
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+
+   /* First time: disable all crtc's.. */
+   if (!fb_helper->deferred_setup && 
!READ_ONCE(fb_helper->dev->master))
+   restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
 
-- 
2.15.0

[PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

[Maarten Lankhorst]

Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.

Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.

Signed-off-by: Maarten Lankhorst 
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Cc:  # v4.14+
Reported-by: Thomas Voegtle 
---
 drivers/gpu/drm/drm_fb_helper.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 07374008f146..e56166334455 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
 
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+
+   /* First time: disable all crtc's.. */
+   if (!fb_helper->deferred_setup && 
!READ_ONCE(fb_helper->dev->master))
+   restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
 
-- 
2.15.0

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

[Maarten Lankhorst]

Op 28-11-17 om 10:30 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Maarten Lankhorst wrote:
>
>> Op 27-11-17 om 19:09 schreef Thomas Voegtle:
>>>
>>> Hello,
>>>
>>> with v4.14 I recognized that my file server (headless haswell system)
>>> doesn't enter packages pc3 anymore and only enters pc2 according to
>>> powertop.
>>> In v4.13 the system used pc2 and pc3.
>>>
>>> So I bisected that down to:
>>>
>>> ca91a2758fcef6635626993557dd51cfbb6dd134 is the first bad commit
>>> commit ca91a2758fcef6635626993557dd51cfbb6dd134
>>> Author: Daniel Vetter <daniel.vet...@ffwll.ch>
>>> Date:   Thu Jul 6 15:00:21 2017 +0200
>>>
>>>     drm/fb-helper: Support deferred setup
>>>
>>>
>>> Reverting this commit on top of v4.14 and v4.15-rc1 fixes the problem and
>>> the system uses package states pc2 and pc3 again.
>>>
>>> Nothing is connected to the VGA and DVI port.
>>> I'm using a kernel without modules on openSUSE 42.3.
>>> I have no "vga=xxx" or something like that on the cmdline.
>>>
>>>
>>> Thanks,
>>>
>>>   Thomas
>>>
>> Could you send some logs with drm.debug=0x1f ?
>>
>> ~Maarten
>
> dmesg attached.

Does this work? A log of a working config (4.14 or with revert) would be nice 
regardless. :)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 07374008f146..6d71ced16f6e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
 
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+   restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
 

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

[Maarten Lankhorst]

Op 28-11-17 om 10:30 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Maarten Lankhorst wrote:
>
>> Op 27-11-17 om 19:09 schreef Thomas Voegtle:
>>>
>>> Hello,
>>>
>>> with v4.14 I recognized that my file server (headless haswell system)
>>> doesn't enter packages pc3 anymore and only enters pc2 according to
>>> powertop.
>>> In v4.13 the system used pc2 and pc3.
>>>
>>> So I bisected that down to:
>>>
>>> ca91a2758fcef6635626993557dd51cfbb6dd134 is the first bad commit
>>> commit ca91a2758fcef6635626993557dd51cfbb6dd134
>>> Author: Daniel Vetter 
>>> Date:   Thu Jul 6 15:00:21 2017 +0200
>>>
>>>     drm/fb-helper: Support deferred setup
>>>
>>>
>>> Reverting this commit on top of v4.14 and v4.15-rc1 fixes the problem and
>>> the system uses package states pc2 and pc3 again.
>>>
>>> Nothing is connected to the VGA and DVI port.
>>> I'm using a kernel without modules on openSUSE 42.3.
>>> I have no "vga=xxx" or something like that on the cmdline.
>>>
>>>
>>> Thanks,
>>>
>>>   Thomas
>>>
>> Could you send some logs with drm.debug=0x1f ?
>>
>> ~Maarten
>
> dmesg attached.

Does this work? A log of a working config (4.14 or with revert) would be nice 
regardless. :)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 07374008f146..6d71ced16f6e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
 
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+   restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
 

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

[Maarten Lankhorst]

Op 27-11-17 om 19:09 schreef Thomas Voegtle:
>
> Hello,
>
> with v4.14 I recognized that my file server (headless haswell system)
> doesn't enter packages pc3 anymore and only enters pc2 according to
> powertop.
> In v4.13 the system used pc2 and pc3.
>
> So I bisected that down to:
>
> ca91a2758fcef6635626993557dd51cfbb6dd134 is the first bad commit
> commit ca91a2758fcef6635626993557dd51cfbb6dd134
> Author: Daniel Vetter 
> Date:   Thu Jul 6 15:00:21 2017 +0200
>
>     drm/fb-helper: Support deferred setup
>
>
> Reverting this commit on top of v4.14 and v4.15-rc1 fixes the problem and
> the system uses package states pc2 and pc3 again.
>
> Nothing is connected to the VGA and DVI port.
> I'm using a kernel without modules on openSUSE 42.3.
> I have no "vga=xxx" or something like that on the cmdline.
>
>
> Thanks,
>
>   Thomas
>
Could you send some logs with drm.debug=0x1f ?

~Maarten

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

[Maarten Lankhorst]

Op 27-11-17 om 19:09 schreef Thomas Voegtle:
>
> Hello,
>
> with v4.14 I recognized that my file server (headless haswell system)
> doesn't enter packages pc3 anymore and only enters pc2 according to
> powertop.
> In v4.13 the system used pc2 and pc3.
>
> So I bisected that down to:
>
> ca91a2758fcef6635626993557dd51cfbb6dd134 is the first bad commit
> commit ca91a2758fcef6635626993557dd51cfbb6dd134
> Author: Daniel Vetter 
> Date:   Thu Jul 6 15:00:21 2017 +0200
>
>     drm/fb-helper: Support deferred setup
>
>
> Reverting this commit on top of v4.14 and v4.15-rc1 fixes the problem and
> the system uses package states pc2 and pc3 again.
>
> Nothing is connected to the VGA and DVI port.
> I'm using a kernel without modules on openSUSE 42.3.
> I have no "vga=xxx" or something like that on the cmdline.
>
>
> Thanks,
>
>   Thomas
>
Could you send some logs with drm.debug=0x1f ?

~Maarten

Re: [PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()

[Maarten Lankhorst]

Op 09-10-17 om 08:46 schreef Jeffy Chen:
> Kmemleak reported memory leak after suspend and resume:
> unreferenced object 0xffc0e31d8880 (size 128):
>   comm "bash", pid 181, jiffies 4294763583 (age 24.694s)
>   hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 00 20 a2 eb c0 ff ff ff  . ..
> 01 00 00 00 00 00 00 00 80 87 1d e3 c0 ff ff ff  
>   backtrace:
> [] __save_stack_trace+0x48/0x6c
> [] create_object+0x138/0x254
> [] kmemleak_alloc+0x58/0x8c
> [] kmem_cache_alloc_trace+0x188/0x254
> [] drm_atomic_state_alloc+0x3c/0x88
> [] drm_atomic_helper_duplicate_state+0x28/0x158
> [] drm_atomic_helper_suspend+0x5c/0xf0
>
> Problem here is that we are duplicating the drm_atomic_state in
> drm_atomic_helper_suspend(), but not unreference it in the resume path.
>
> Fixes: 1494276000db ("drm/atomic-helper: Implement subsystem-level 
> suspend/resume")
> Signed-off-by: Jeffy Chen <jeffy.c...@rock-chips.com>
> ---
>
> Changes in v2:
> Unref duplicated drm_atomic_state in drm_atomic_helper_resume() instead
> of specific drivers.
>
>  drivers/gpu/drm/drm_atomic_helper.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 01c34bc5b5b0..4a262380c631 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>   drm_modeset_backoff();
>   }
>  
> + drm_atomic_state_put(state);
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
>  

Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Cc: <sta...@vger.kernel.org> # v4.10+

and pushed, thanks for finding it. :)

The bug is probably older than that commit, but only happened on failure paths 
before. If resume fails we probably have bigger issues than leaking some memory.

Re: [PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()

[Maarten Lankhorst]

Op 09-10-17 om 08:46 schreef Jeffy Chen:
> Kmemleak reported memory leak after suspend and resume:
> unreferenced object 0xffc0e31d8880 (size 128):
>   comm "bash", pid 181, jiffies 4294763583 (age 24.694s)
>   hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 00 20 a2 eb c0 ff ff ff  . ..
> 01 00 00 00 00 00 00 00 80 87 1d e3 c0 ff ff ff  
>   backtrace:
> [] __save_stack_trace+0x48/0x6c
> [] create_object+0x138/0x254
> [] kmemleak_alloc+0x58/0x8c
> [] kmem_cache_alloc_trace+0x188/0x254
> [] drm_atomic_state_alloc+0x3c/0x88
> [] drm_atomic_helper_duplicate_state+0x28/0x158
> [] drm_atomic_helper_suspend+0x5c/0xf0
>
> Problem here is that we are duplicating the drm_atomic_state in
> drm_atomic_helper_suspend(), but not unreference it in the resume path.
>
> Fixes: 1494276000db ("drm/atomic-helper: Implement subsystem-level 
> suspend/resume")
> Signed-off-by: Jeffy Chen 
> ---
>
> Changes in v2:
> Unref duplicated drm_atomic_state in drm_atomic_helper_resume() instead
> of specific drivers.
>
>  drivers/gpu/drm/drm_atomic_helper.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 01c34bc5b5b0..4a262380c631 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>   drm_modeset_backoff();
>   }
>  
> + drm_atomic_state_put(state);
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
>  

Reviewed-by: Maarten Lankhorst 
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Cc:  # v4.10+

and pushed, thanks for finding it. :)

The bug is probably older than that commit, but only happened on failure paths 
before. If resume fails we probably have bigger issues than leaking some memory.

[PATCH 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver.

Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-3-maarten.lankho...@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
[mlankhorst: Fix typos in swap_state documentation (seanpaul)]
Reviewed-by: Sean Paul <seanp...@chromium.org>]
---
 drivers/gpu/drm/drm_atomic_helper.c | 26 ++
 include/drm/drm_atomic_helper.h |  3 +--
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 2f675112e225..8d8221a128d0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1510,10 +1510,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
+   if (ret)
+   goto err;
}
 
/*
@@ -1522,7 +1520,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 * the software side now.
 */
 
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err;
 
/*
 * Everything below can be run asynchronously without the need to grab
@@ -1551,6 +1551,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
commit_tail(state);
 
return 0;
+
+err:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);
 
@@ -2228,14 +2232,14 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
 /**
  * drm_atomic_helper_swap_state - store atomic state into current sw state
  * @state: atomic state
- * @stall: stall for proceeding commits
+ * @stall: stall for preceeding commits
  *
  * This function stores the atomic state into the current state pointers in all
  * driver objects. It should be called after all failing steps have been done
  * and succeeded, but before the actual hardware state is committed.
  *
  * For cleanup and error recovery the current state for all changed objects 
will
- * be swaped into @state.
+ * be swapped into @state.
  *
  * With that sequence it fits perfectly into the plane prepare/cleanup 
sequence:
  *
@@ -2254,8 +2258,12 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
  * the _plane.state, _crtc.state or _connector.state pointer. With
  * the current atomic helpers this is almost always the case, since the helpers
  * don't pass the right state structures to the callbacks.
+ *
+ * Returns:
+ *
+ * Always returns 0, cannot fail yet.
  */
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
int i;
@@ -2339,6 +2347,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
state->private_objs[i].state = old_obj_state;
obj->state = new_obj_state;
}
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_swap_state);
 
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 7db3438ff735..547480692470 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -86,8 +86,7 @@ void
 drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
 bool atomic);
 
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
- bool stall);
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state, bool stall);
 
 /* nonblocking commit helpers */
 int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
-- 
2.11.0

[PATCH 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver.

Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-3-maarten.lankho...@linux.intel.com
Reviewed-by: Daniel Vetter 
[mlankhorst: Fix typos in swap_state documentation (seanpaul)]
Reviewed-by: Sean Paul ]
---
 drivers/gpu/drm/drm_atomic_helper.c | 26 ++
 include/drm/drm_atomic_helper.h |  3 +--
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 2f675112e225..8d8221a128d0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1510,10 +1510,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
+   if (ret)
+   goto err;
}
 
/*
@@ -1522,7 +1520,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 * the software side now.
 */
 
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err;
 
/*
 * Everything below can be run asynchronously without the need to grab
@@ -1551,6 +1551,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
commit_tail(state);
 
return 0;
+
+err:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);
 
@@ -2228,14 +2232,14 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
 /**
  * drm_atomic_helper_swap_state - store atomic state into current sw state
  * @state: atomic state
- * @stall: stall for proceeding commits
+ * @stall: stall for preceeding commits
  *
  * This function stores the atomic state into the current state pointers in all
  * driver objects. It should be called after all failing steps have been done
  * and succeeded, but before the actual hardware state is committed.
  *
  * For cleanup and error recovery the current state for all changed objects 
will
- * be swaped into @state.
+ * be swapped into @state.
  *
  * With that sequence it fits perfectly into the plane prepare/cleanup 
sequence:
  *
@@ -2254,8 +2258,12 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
  * the _plane.state, _crtc.state or _connector.state pointer. With
  * the current atomic helpers this is almost always the case, since the helpers
  * don't pass the right state structures to the callbacks.
+ *
+ * Returns:
+ *
+ * Always returns 0, cannot fail yet.
  */
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
int i;
@@ -2339,6 +2347,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
state->private_objs[i].state = old_obj_state;
obj->state = new_obj_state;
}
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_swap_state);
 
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 7db3438ff735..547480692470 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -86,8 +86,7 @@ void
 drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
 bool atomic);
 
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
- bool stall);
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state, bool stall);
 
 /* nonblocking commit helpers */
 int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
-- 
2.11.0

scripts/get_maintainer.pl misses maintainers sometimes

[Maarten Lankhorst]

Hello Joe Perches,

I created a script for drm's maintainer-tools that pipes the output of 
get_maintainer.pl
to add the appropriate cc's to the commit message. It also ignores duplicates, 
so running
the script twice on the same commit doesn't add everyone twice.

When testing, I found out that sometimes maintainers were added on the second 
patch, and
that made me notice a bug in get_maintainer.pl.

On the below patch, I get up to 39 maintainers from get_maintainer.pl, but the 
actual amount 
differs randomly on each invocation:

~/linux$ git show | scripts/get_maintainer.pl | wc -l
39
~/linux$ git show | scripts/get_maintainer.pl | wc -l
37
~/linux$ git show | scripts/get_maintainer.pl | wc -l
38

Any idea why this happens?

The commit I used for testing is pasted below.

Kind regards,
Maarten Lankhorst

--8<--
commit 94273dc6f6e3ab77948dddc6e0572ca7ea890520
Author: Daniel Vetter <daniel.vet...@ffwll.ch>
Date:   Wed Jun 28 14:11:49 2017 +0200

drm/: Drop fbdev info flags

 - FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed
  the entire panic handling code in our fbdev emulation. We might
  restore kms panic output, but not through the bazillion of legacy
  code layers called fbdev/fbcon, there's just no way to make that
  work safely.

- With the module check change FBINFO_DEFAULT is always 0, so can be
  removed too.

That removes another change to cargo-cult stuff in kms drivers, yay!

Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index c0d8c6ff6380..1c57fefc364c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -245,7 +245,6 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
 
-   info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = _ops;
 
tmp = amdgpu_bo_gpu_offset(abo) - adev->mc.vram_start;
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 602dfead8eef..5b479b0ed06c 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -81,7 +81,6 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
 
strlcpy(info->fix.id, "armada-drmfb", sizeof(info->fix.id));
info->par = fbh;
-   info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = _fb_ops;
info->fix.smem_start = obj->phys_addr;
info->fix.smem_len = obj->obj.size;
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 4ad4acd0ccab..53ca6d099234 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -231,7 +231,6 @@ static int astfb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "astdrmfb");
 
-   info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = _ops;
 
info->apertures->ranges[0].base = pci_resource_start(dev->pdev, 0);
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 49d5a2b7d630..14eb8d0d5a00 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -118,7 +118,6 @@ static int bochsfb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "bochsdrmfb");
 
-   info->flags = FBINFO_DEFAULT;
info->fbops = _ops;
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 7fa58eeadc9d..c69586163d92 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -215,7 +215,6 @@ static int cirrusfb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "cirrusdrmfb");
 
-   info->flags = FBINFO_DEFAULT;
info->fbops = _ops;
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index f5ac80daeef2..9740eed9231a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -131,7 +131,6 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "hibmcdrmfb");
 
-   info->flags = FBINFO_DEFAULT;
info->fbops = _drm_fb_ops;
 
drm_fb_helper_fill_fix(info, hi_fbdev->fb->fb.pitches[0],
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index f11ee039ff45..b5fee2b59d67 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/

scripts/get_maintainer.pl misses maintainers sometimes

[Maarten Lankhorst]

Hello Joe Perches,

I created a script for drm's maintainer-tools that pipes the output of 
get_maintainer.pl
to add the appropriate cc's to the commit message. It also ignores duplicates, 
so running
the script twice on the same commit doesn't add everyone twice.

When testing, I found out that sometimes maintainers were added on the second 
patch, and
that made me notice a bug in get_maintainer.pl.

On the below patch, I get up to 39 maintainers from get_maintainer.pl, but the 
actual amount 
differs randomly on each invocation:

~/linux$ git show | scripts/get_maintainer.pl | wc -l
39
~/linux$ git show | scripts/get_maintainer.pl | wc -l
37
~/linux$ git show | scripts/get_maintainer.pl | wc -l
38

Any idea why this happens?

The commit I used for testing is pasted below.

Kind regards,
Maarten Lankhorst

--8<--
commit 94273dc6f6e3ab77948dddc6e0572ca7ea890520
Author: Daniel Vetter 
Date:   Wed Jun 28 14:11:49 2017 +0200

drm/: Drop fbdev info flags

 - FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed
  the entire panic handling code in our fbdev emulation. We might
  restore kms panic output, but not through the bazillion of legacy
  code layers called fbdev/fbcon, there's just no way to make that
  work safely.

- With the module check change FBINFO_DEFAULT is always 0, so can be
  removed too.

That removes another change to cargo-cult stuff in kms drivers, yay!

Signed-off-by: Daniel Vetter 

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index c0d8c6ff6380..1c57fefc364c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -245,7 +245,6 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
 
-   info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = _ops;
 
tmp = amdgpu_bo_gpu_offset(abo) - adev->mc.vram_start;
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 602dfead8eef..5b479b0ed06c 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -81,7 +81,6 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
 
strlcpy(info->fix.id, "armada-drmfb", sizeof(info->fix.id));
info->par = fbh;
-   info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = _fb_ops;
info->fix.smem_start = obj->phys_addr;
info->fix.smem_len = obj->obj.size;
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 4ad4acd0ccab..53ca6d099234 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -231,7 +231,6 @@ static int astfb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "astdrmfb");
 
-   info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = _ops;
 
info->apertures->ranges[0].base = pci_resource_start(dev->pdev, 0);
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 49d5a2b7d630..14eb8d0d5a00 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -118,7 +118,6 @@ static int bochsfb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "bochsdrmfb");
 
-   info->flags = FBINFO_DEFAULT;
info->fbops = _ops;
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 7fa58eeadc9d..c69586163d92 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -215,7 +215,6 @@ static int cirrusfb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "cirrusdrmfb");
 
-   info->flags = FBINFO_DEFAULT;
info->fbops = _ops;
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index f5ac80daeef2..9740eed9231a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -131,7 +131,6 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
 
strcpy(info->fix.id, "hibmcdrmfb");
 
-   info->flags = FBINFO_DEFAULT;
info->fbops = _drm_fb_ops;
 
drm_fb_helper_fill_fix(info, hi_fbdev->fb->fb.pitches[0],
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index f11ee039ff45..b5fee2b59d67 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -232,7 +232,6 @@ static int intelfb_create(s

[PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver.

Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
---
 drivers/gpu/drm/drm_atomic_helper.c | 22 --
 include/drm/drm_atomic_helper.h |  3 +--
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 667ec97d4efb..bfb98fbd0e0e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1510,10 +1510,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
+   if (ret)
+   goto err;
}
 
/*
@@ -1522,7 +1520,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 * the software side now.
 */
 
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err;
 
/*
 * Everything below can be run asynchronously without the need to grab
@@ -1551,6 +1551,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
commit_tail(state);
 
return 0;
+
+err:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);
 
@@ -2254,8 +2258,12 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
  * the _plane.state, _crtc.state or _connector.state pointer. With
  * the current atomic helpers this is almost always the case, since the helpers
  * don't pass the right state structures to the callbacks.
+ *
+ * Returns:
+ *
+ * Always returns 0, cannot fail yet.
  */
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
int i;
@@ -2332,6 +2340,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
 
__for_each_private_obj(state, obj, obj_state, i, funcs)
funcs->swap_state(obj, >private_objs[i].obj_state);
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_swap_state);
 
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index dd196cc0afd7..37c9534ff691 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -84,8 +84,7 @@ void
 drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
 bool atomic);
 
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
- bool stall);
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state, bool stall);
 
 /* nonblocking commit helpers */
 int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
-- 
2.11.0

[PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver.

Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 22 --
 include/drm/drm_atomic_helper.h |  3 +--
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 667ec97d4efb..bfb98fbd0e0e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1510,10 +1510,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
+   if (ret)
+   goto err;
}
 
/*
@@ -1522,7 +1520,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 * the software side now.
 */
 
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err;
 
/*
 * Everything below can be run asynchronously without the need to grab
@@ -1551,6 +1551,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
commit_tail(state);
 
return 0;
+
+err:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);
 
@@ -2254,8 +2258,12 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
  * the _plane.state, _crtc.state or _connector.state pointer. With
  * the current atomic helpers this is almost always the case, since the helpers
  * don't pass the right state structures to the callbacks.
+ *
+ * Returns:
+ *
+ * Always returns 0, cannot fail yet.
  */
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
int i;
@@ -2332,6 +2340,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
 
__for_each_private_obj(state, obj, obj_state, i, funcs)
funcs->swap_state(obj, >private_objs[i].obj_state);
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_swap_state);
 
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index dd196cc0afd7..37c9534ff691 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -84,8 +84,7 @@ void
 drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
 bool atomic);
 
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
- bool stall);
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state, bool stall);
 
 /* nonblocking commit helpers */
 int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
-- 
2.11.0

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have changes to deal with the
>> clean up. In order to allow easy reverting, the commit that changes
>> behavior is separate so someone only has to revert that for testing.
>>
>> Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
>> failed cleanup_planes was not called.
>>
>> Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
>> Cc: David Airlie <airl...@linux.ie>
>> Cc: Daniel Vetter <daniel.vet...@intel.com>
>> Cc: Jani Nikula <jani.nik...@linux.intel.com>
>> Cc: Sean Paul <seanp...@chromium.org>
>> Cc: CK Hu <ck...@mediatek.com>
>> Cc: Philipp Zabel <p.za...@pengutronix.de>
>> Cc: Matthias Brugger <matthias@gmail.com>
>> Cc: Rob Clark <robdcl...@gmail.com>
>> Cc: Ben Skeggs <bske...@redhat.com>
>> Cc: Thierry Reding <thierry.red...@gmail.com>
>> Cc: Jonathan Hunter <jonath...@nvidia.com>
>> Cc: Jyri Sarha <jsa...@ti.com>
>> Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
>> Cc: Eric Anholt <e...@anholt.net>
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-media...@lists.infradead.org
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: freedr...@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> Cc: linux-te...@vger.kernel.org
>> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> We kinda need to backport this to older kernels, but I don't really see
> how :( Maybe we should split this up:
> patch 1: Change to int return type
> patches 2-(n-1): Driver conversions
> patch n: __must_check addition
>
> That would at least somewhat make this backportable ...
>
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
>>  drivers/gpu/drm/drm_atomic_helper.c  | 18 --
>>  drivers/gpu/drm/i915/intel_display.c | 10 +-
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  7 ++-
>>  drivers/gpu/drm/msm/msm_atomic.c | 14 +-
>>  drivers/gpu/drm/nouveau/nv50_display.c   | 10 --
>>  drivers/gpu/drm/tegra/drm.c  |  7 ++-
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  6 +-
>>  drivers/gpu/drm/vc4/vc4_kms.c| 21 +
>>  include/drm/drm_atomic_helper.h  |  4 ++--
>>  10 files changed, 82 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 516d9547d331..d4f787bf1d4a 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct 
>> drm_device *dev,
>>  goto error;
>>  }
>>  
>> -/* Swap the state, this is the point of no return. */
>> -drm_atomic_helper_swap_state(state, true);
> Push the swap_state up over the commit setup (but after the allocation)
> and there's no more a problem with unrolling.
I think just like msm this might also use stall = false safely.
>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c 
>> b/drivers/gpu/drm/msm/msm_atomic.c
>> index 9633a68b14d7..85dd485fdef4 100644
>> --- a/drivers/gpu/drm/msm/msm_atomic.c
>> +++ b/drivers/gpu/drm/msm/msm_atomic.c
>> @@ -232,8 +232,12 @@ int msm_atomic_commit(struct drm_device *dev,
>>   * mark our set of crtc's as busy:
>>   */
>>  ret = start_atomic(dev->dev_private, c->crtc_mask);
>> +if (ret)
>> +goto err_free;
>> +
>> +ret = drm_atomic_helper_swap_state(state, true);
> Hm, might be simpler to have stall = false (which btw makes your
> __must_check annotation a lie, you only have to check when you stall),
> since start_atomic above already does stall for everything as needed.
True, could we create a separate function for swap_state_and_wait, and kill the 
stall argument?
>>  if (ret) {
>> -kfree(c);
>> +commit_destroy(c);
>>  goto error;
>>  }
>>  
>> @@ -241,11 +245,9 @@ int msm_atomic_commit(struct drm_device *dev,

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have changes to deal with the
>> clean up. In order to allow easy reverting, the commit that changes
>> behavior is separate so someone only has to revert that for testing.
>>
>> Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
>> failed cleanup_planes was not called.
>>
>> Cc: Boris Brezillon 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Sean Paul 
>> Cc: CK Hu 
>> Cc: Philipp Zabel 
>> Cc: Matthias Brugger 
>> Cc: Rob Clark 
>> Cc: Ben Skeggs 
>> Cc: Thierry Reding 
>> Cc: Jonathan Hunter 
>> Cc: Jyri Sarha 
>> Cc: Tomi Valkeinen 
>> Cc: Eric Anholt 
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-media...@lists.infradead.org
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: freedr...@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> Cc: linux-te...@vger.kernel.org
>> Signed-off-by: Maarten Lankhorst 
> We kinda need to backport this to older kernels, but I don't really see
> how :( Maybe we should split this up:
> patch 1: Change to int return type
> patches 2-(n-1): Driver conversions
> patch n: __must_check addition
>
> That would at least somewhat make this backportable ...
>
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
>>  drivers/gpu/drm/drm_atomic_helper.c  | 18 --
>>  drivers/gpu/drm/i915/intel_display.c | 10 +-
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  7 ++-
>>  drivers/gpu/drm/msm/msm_atomic.c | 14 +-
>>  drivers/gpu/drm/nouveau/nv50_display.c   | 10 --
>>  drivers/gpu/drm/tegra/drm.c  |  7 ++-
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  6 +-
>>  drivers/gpu/drm/vc4/vc4_kms.c| 21 +
>>  include/drm/drm_atomic_helper.h  |  4 ++--
>>  10 files changed, 82 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 516d9547d331..d4f787bf1d4a 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct 
>> drm_device *dev,
>>  goto error;
>>  }
>>  
>> -/* Swap the state, this is the point of no return. */
>> -drm_atomic_helper_swap_state(state, true);
> Push the swap_state up over the commit setup (but after the allocation)
> and there's no more a problem with unrolling.
I think just like msm this might also use stall = false safely.
>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c 
>> b/drivers/gpu/drm/msm/msm_atomic.c
>> index 9633a68b14d7..85dd485fdef4 100644
>> --- a/drivers/gpu/drm/msm/msm_atomic.c
>> +++ b/drivers/gpu/drm/msm/msm_atomic.c
>> @@ -232,8 +232,12 @@ int msm_atomic_commit(struct drm_device *dev,
>>   * mark our set of crtc's as busy:
>>   */
>>  ret = start_atomic(dev->dev_private, c->crtc_mask);
>> +if (ret)
>> +goto err_free;
>> +
>> +ret = drm_atomic_helper_swap_state(state, true);
> Hm, might be simpler to have stall = false (which btw makes your
> __must_check annotation a lie, you only have to check when you stall),
> since start_atomic above already does stall for everything as needed.
True, could we create a separate function for swap_state_and_wait, and kill the 
stall argument?
>>  if (ret) {
>> -kfree(c);
>> +commit_destroy(c);
>>  goto error;
>>  }
>>  
>> @@ -241,11 +245,9 @@ int msm_atomic_commit(struct drm_device *dev,
>>   * This is the point of no return - everything below never fails except
>>   * when the hw goes bonghits. Which means we can commit the new state on
>>   * the software side now.
>> + *
>> + * swap driver private state while still holding state_lock
>>   */
>> -
>> -drm_atomic_helper_swap_state(state, true);
>> -
>> -/* swap driver private state while still holding state_lock */
&g

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have changes to deal with the
>> clean up. In order to allow easy reverting, the commit that changes
>> behavior is separate so someone only has to revert that for testing.
>>
>> Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
>> failed cleanup_planes was not called.
>>
>> Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
>> Cc: David Airlie <airl...@linux.ie>
>> Cc: Daniel Vetter <daniel.vet...@intel.com>
>> Cc: Jani Nikula <jani.nik...@linux.intel.com>
>> Cc: Sean Paul <seanp...@chromium.org>
>> Cc: CK Hu <ck...@mediatek.com>
>> Cc: Philipp Zabel <p.za...@pengutronix.de>
>> Cc: Matthias Brugger <matthias@gmail.com>
>> Cc: Rob Clark <robdcl...@gmail.com>
>> Cc: Ben Skeggs <bske...@redhat.com>
>> Cc: Thierry Reding <thierry.red...@gmail.com>
>> Cc: Jonathan Hunter <jonath...@nvidia.com>
>> Cc: Jyri Sarha <jsa...@ti.com>
>> Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
>> Cc: Eric Anholt <e...@anholt.net>
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-media...@lists.infradead.org
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: freedr...@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> Cc: linux-te...@vger.kernel.org
>> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> We kinda need to backport this to older kernels, but I don't really see
> how :( Maybe we should split this up:
> patch 1: Change to int return type
> patches 2-(n-1): Driver conversions
> patch n: __must_check addition
>
> That would at least somewhat make this backportable ...
>
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
>>  drivers/gpu/drm/drm_atomic_helper.c  | 18 --
>>  drivers/gpu/drm/i915/intel_display.c | 10 +-
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  7 ++-
>>  drivers/gpu/drm/msm/msm_atomic.c | 14 +-
>>  drivers/gpu/drm/nouveau/nv50_display.c   | 10 --
>>  drivers/gpu/drm/tegra/drm.c  |  7 ++-
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  6 +-
>>  drivers/gpu/drm/vc4/vc4_kms.c| 21 +
>>  include/drm/drm_atomic_helper.h  |  4 ++--
>>  10 files changed, 82 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 516d9547d331..d4f787bf1d4a 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct 
>> drm_device *dev,
>>  goto error;
>>  }
>>  
>> -/* Swap the state, this is the point of no return. */
>> -drm_atomic_helper_swap_state(state, true);
> Push the swap_state up over the commit setup (but after the allocation)
> and there's no more a problem with unrolling.
This can't be done higher up because of the interruptible wait.

Unless we change the patch series to move the waiting for hw_done to a separate 
step and get rid of the stall argument to swap_state once everything is 
converted. This could be useful for all drivers that have some kind of setup, 
because we could move the wait up slightly to suit the drivers needs.

~Maarten

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have changes to deal with the
>> clean up. In order to allow easy reverting, the commit that changes
>> behavior is separate so someone only has to revert that for testing.
>>
>> Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
>> failed cleanup_planes was not called.
>>
>> Cc: Boris Brezillon 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Sean Paul 
>> Cc: CK Hu 
>> Cc: Philipp Zabel 
>> Cc: Matthias Brugger 
>> Cc: Rob Clark 
>> Cc: Ben Skeggs 
>> Cc: Thierry Reding 
>> Cc: Jonathan Hunter 
>> Cc: Jyri Sarha 
>> Cc: Tomi Valkeinen 
>> Cc: Eric Anholt 
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-media...@lists.infradead.org
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: freedr...@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> Cc: linux-te...@vger.kernel.org
>> Signed-off-by: Maarten Lankhorst 
> We kinda need to backport this to older kernels, but I don't really see
> how :( Maybe we should split this up:
> patch 1: Change to int return type
> patches 2-(n-1): Driver conversions
> patch n: __must_check addition
>
> That would at least somewhat make this backportable ...
>
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
>>  drivers/gpu/drm/drm_atomic_helper.c  | 18 --
>>  drivers/gpu/drm/i915/intel_display.c | 10 +-
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  7 ++-
>>  drivers/gpu/drm/msm/msm_atomic.c | 14 +-
>>  drivers/gpu/drm/nouveau/nv50_display.c   | 10 --
>>  drivers/gpu/drm/tegra/drm.c  |  7 ++-
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  6 +-
>>  drivers/gpu/drm/vc4/vc4_kms.c| 21 +
>>  include/drm/drm_atomic_helper.h  |  4 ++--
>>  10 files changed, 82 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 516d9547d331..d4f787bf1d4a 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct 
>> drm_device *dev,
>>  goto error;
>>  }
>>  
>> -/* Swap the state, this is the point of no return. */
>> -drm_atomic_helper_swap_state(state, true);
> Push the swap_state up over the commit setup (but after the allocation)
> and there's no more a problem with unrolling.
This can't be done higher up because of the interruptible wait.

Unless we change the patch series to move the waiting for hw_done to a separate 
step and get rid of the stall argument to swap_state once everything is 
converted. This could be useful for all drivers that have some kind of setup, 
because we could move the wait up slightly to suit the drivers needs.

~Maarten

[PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver. All drivers have changes to deal with the
clean up. In order to allow easy reverting, the commit that changes
behavior is separate so someone only has to revert that for testing.

Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
failed cleanup_planes was not called.

Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
Cc: David Airlie <airl...@linux.ie>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Cc: CK Hu <ck...@mediatek.com>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Cc: Matthias Brugger <matthias@gmail.com>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Ben Skeggs <bske...@redhat.com>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Jonathan Hunter <jonath...@nvidia.com>
Cc: Jyri Sarha <jsa...@ti.com>
Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
Cc: Eric Anholt <e...@anholt.net>
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
 drivers/gpu/drm/drm_atomic_helper.c  | 18 --
 drivers/gpu/drm/i915/intel_display.c | 10 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  7 ++-
 drivers/gpu/drm/msm/msm_atomic.c | 14 +-
 drivers/gpu/drm/nouveau/nv50_display.c   | 10 --
 drivers/gpu/drm/tegra/drm.c  |  7 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  6 +-
 drivers/gpu/drm/vc4/vc4_kms.c| 21 +
 include/drm/drm_atomic_helper.h  |  4 ++--
 10 files changed, 82 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 516d9547d331..d4f787bf1d4a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
*dev,
goto error;
}
 
-   /* Swap the state, this is the point of no return. */
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err_pending;
 
+   /* Swap state succeeded, this is the point of no return. */
drm_atomic_state_get(state);
if (async)
queue_work(dc->wq, >work);
@@ -555,6 +557,14 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
*dev,
 
return 0;
 
+err_pending:
+   /* Fail the commit, wake up any waiter. */
+   spin_lock(>commit.wait.lock);
+   dc->commit.pending = false;
+   wake_up_all_locked(>commit.wait);
+   spin_unlock(>commit.wait.lock);
+err_free:
+   kfree(commit);
 error:
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index f1847d29ba3e..f66b6c45cdd0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1387,10 +1387,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
+   if (ret)
+   goto err;
}
 
/*
@@ -1399,7 +1397,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 * the software side now.
 */
 
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err;
 
/*
 * Everything below can be run asynchronously without the need to grab
@@ -1428,6 +1428,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
commit_tail(state);
 
return 0;
+
+err:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);
 
@@ -2137,7 +2141,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
  * the current atomic helpers this is almost always the case, since the helpers
  * don't pass the right state structures to the callbacks.
  */
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
+int drm_ato

[PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver. All drivers have changes to deal with the
clean up. In order to allow easy reverting, the commit that changes
behavior is separate so someone only has to revert that for testing.

Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
failed cleanup_planes was not called.

Cc: Boris Brezillon 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Matthias Brugger 
Cc: Rob Clark 
Cc: Ben Skeggs 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
 drivers/gpu/drm/drm_atomic_helper.c  | 18 --
 drivers/gpu/drm/i915/intel_display.c | 10 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  7 ++-
 drivers/gpu/drm/msm/msm_atomic.c | 14 +-
 drivers/gpu/drm/nouveau/nv50_display.c   | 10 --
 drivers/gpu/drm/tegra/drm.c  |  7 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  6 +-
 drivers/gpu/drm/vc4/vc4_kms.c| 21 +
 include/drm/drm_atomic_helper.h  |  4 ++--
 10 files changed, 82 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 516d9547d331..d4f787bf1d4a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
*dev,
goto error;
}
 
-   /* Swap the state, this is the point of no return. */
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err_pending;
 
+   /* Swap state succeeded, this is the point of no return. */
drm_atomic_state_get(state);
if (async)
queue_work(dc->wq, >work);
@@ -555,6 +557,14 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
*dev,
 
return 0;
 
+err_pending:
+   /* Fail the commit, wake up any waiter. */
+   spin_lock(>commit.wait.lock);
+   dc->commit.pending = false;
+   wake_up_all_locked(>commit.wait);
+   spin_unlock(>commit.wait.lock);
+err_free:
+   kfree(commit);
 error:
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index f1847d29ba3e..f66b6c45cdd0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1387,10 +1387,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
+   if (ret)
+   goto err;
}
 
/*
@@ -1399,7 +1397,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 * the software side now.
 */
 
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err;
 
/*
 * Everything below can be run asynchronously without the need to grab
@@ -1428,6 +1428,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
commit_tail(state);
 
return 0;
+
+err:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);
 
@@ -2137,7 +2141,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
  * the current atomic helpers this is almost always the case, since the helpers
  * don't pass the right state structures to the callbacks.
  */
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
int i;
@@ -2214,6 +2218,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
 
__for_each_private_obj(state, obj, obj_state, i, funcs)
funcs->swap_state(obj, >private_objs[i].obj_state);
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_swap_state);
 
diff --git a/drivers/gpu/drm/i915/intel_display.c

[PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.

[Maarten Lankhorst]

Without waiting for hw_done, previous atomic updates may dereference
the wrong state and cause a lot of confusion. The real fix is fixing
all obj->state to use the accessor macros, but for now wait
indefinitely and interruptibly.

Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
Cc: David Airlie <airl...@linux.ie>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Cc: CK Hu <ck...@mediatek.com>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Cc: Matthias Brugger <matthias@gmail.com>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Ben Skeggs <bske...@redhat.com>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Jonathan Hunter <jonath...@nvidia.com>
Cc: Jyri Sarha <jsa...@ti.com>
Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
Cc: Eric Anholt <e...@anholt.net>
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index f66b6c45cdd0..56e7729d993d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2144,8 +2144,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
 int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
-   int i;
-   long ret;
+   int i, ret;
struct drm_connector *connector;
struct drm_connector_state *old_conn_state, *new_conn_state;
struct drm_crtc *crtc;
@@ -2168,12 +2167,11 @@ int drm_atomic_helper_swap_state(struct 
drm_atomic_state *state,
if (!commit)
continue;
 
-   ret = wait_for_completion_timeout(>hw_done,
- 10*HZ);
-   if (ret == 0)
-   DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
- crtc->base.id, crtc->name);
+   ret = 
wait_for_completion_interruptible(>hw_done);
drm_crtc_commit_put(commit);
+
+   if (ret)
+   return ret;
}
}
 
-- 
2.11.0

[PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.

[Maarten Lankhorst]

Without waiting for hw_done, previous atomic updates may dereference
the wrong state and cause a lot of confusion. The real fix is fixing
all obj->state to use the accessor macros, but for now wait
indefinitely and interruptibly.

Cc: Boris Brezillon 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Matthias Brugger 
Cc: Rob Clark 
Cc: Ben Skeggs 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index f66b6c45cdd0..56e7729d993d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2144,8 +2144,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
 int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
-   int i;
-   long ret;
+   int i, ret;
struct drm_connector *connector;
struct drm_connector_state *old_conn_state, *new_conn_state;
struct drm_crtc *crtc;
@@ -2168,12 +2167,11 @@ int drm_atomic_helper_swap_state(struct 
drm_atomic_state *state,
if (!commit)
continue;
 
-   ret = wait_for_completion_timeout(>hw_done,
- 10*HZ);
-   if (ret == 0)
-   DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
- crtc->base.id, crtc->name);
+   ret = 
wait_for_completion_interruptible(>hw_done);
drm_crtc_commit_put(commit);
+
+   if (ret)
+   return ret;
}
}
 
-- 
2.11.0

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Maarten Lankhorst]

Op 27-06-17 om 17:01 schreef Daniel Vetter:
> On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote:
>> Op 27-06-17 om 09:37 schreef Daniel Vetter:
>>> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>>>> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
>>>>> Problem : While running IGT kms_atomic_transition test suite i encountered
>>>>> a hang in drmHandleEvent immediately following  an atomic_commit.
>>>>> After dumping the atomic state I relized that in this case there was
>>>>> not even one CRTC attached to the state and only disabled
>>>>> planes. This probably due to a commit which hadn't changed any property
>>>>> which would require attaching crtc state. This means drmHandleEvent
>>>>> will never wake up from read since without CRTC in atomic state
>>>>> the event fd will not be signaled.
>>>>>
>>>>> Fix: Protect against this issue by failing atomic_commit early in
>>>>> drm_mode_atomic_commit where such probelm can be identified.
>>>>>
>>>>> v2:
>>>>> Fix typos and extra newlines.
>>>>>
>>>>> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
>>>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzov...@amd.com>
>>>> Reviewed-by: Harry Wentland <harry.wentl...@amd.com>
>>> Stalling on this hoping for the igt patch. Does it exist already?
>>> -Daniel
>>>
>>>> Harry
>>>>
>>>>> ---
>>>>>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>>>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>>>> index a567310..48145bf 100644
>>>>> --- a/drivers/gpu/drm/drm_atomic.c
>>>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>>>> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
>>>>> *dev,
>>>>>  {
>>>>>   struct drm_crtc *crtc;
>>>>>   struct drm_crtc_state *crtc_state;
>>>>> - int i, ret;
>>>>> + int i, c = 0, ret;
>>>>>  
>>>>>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>>>>>   return 0;
>>>>> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct 
>>>>> drm_device *dev,
>>>>>  
>>>>>   crtc_state->event->base.fence = fence;
>>>>>   }
>>>>> +
>>>>> + c++;
>>>>>   }
>>>>>  
>>>>> + /*
>>>>> +  * Having this flag means user mode pends on event which will never
>>>>> +  * reach due to lack of at least one CRTC for signaling
>>>>> +  */
>>>>> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>>>>> + return -EINVAL;
>>>>> +
>>>>>   return 0;
>>>>>  }
>>>>>  
>>>>>
>> Just do it, and I'll commit this to igt?
> Ack on both the kernel patch and the igt patch, feel free to push them
> both with:
>
> Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>
> If you do, please add the Testcase: line to the kernel patch.
Oops, missed adding the testcase to commit message, but pushed.

I've pushed the IGT testcase as well, after fixing it up to make sure it works 
as intended.

~Maarten

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Maarten Lankhorst]

Op 27-06-17 om 17:01 schreef Daniel Vetter:
> On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote:
>> Op 27-06-17 om 09:37 schreef Daniel Vetter:
>>> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>>>> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
>>>>> Problem : While running IGT kms_atomic_transition test suite i encountered
>>>>> a hang in drmHandleEvent immediately following  an atomic_commit.
>>>>> After dumping the atomic state I relized that in this case there was
>>>>> not even one CRTC attached to the state and only disabled
>>>>> planes. This probably due to a commit which hadn't changed any property
>>>>> which would require attaching crtc state. This means drmHandleEvent
>>>>> will never wake up from read since without CRTC in atomic state
>>>>> the event fd will not be signaled.
>>>>>
>>>>> Fix: Protect against this issue by failing atomic_commit early in
>>>>> drm_mode_atomic_commit where such probelm can be identified.
>>>>>
>>>>> v2:
>>>>> Fix typos and extra newlines.
>>>>>
>>>>> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
>>>>> Signed-off-by: Andrey Grodzovsky 
>>>> Reviewed-by: Harry Wentland 
>>> Stalling on this hoping for the igt patch. Does it exist already?
>>> -Daniel
>>>
>>>> Harry
>>>>
>>>>> ---
>>>>>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>>>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>>>> index a567310..48145bf 100644
>>>>> --- a/drivers/gpu/drm/drm_atomic.c
>>>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>>>> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
>>>>> *dev,
>>>>>  {
>>>>>   struct drm_crtc *crtc;
>>>>>   struct drm_crtc_state *crtc_state;
>>>>> - int i, ret;
>>>>> + int i, c = 0, ret;
>>>>>  
>>>>>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>>>>>   return 0;
>>>>> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct 
>>>>> drm_device *dev,
>>>>>  
>>>>>   crtc_state->event->base.fence = fence;
>>>>>   }
>>>>> +
>>>>> + c++;
>>>>>   }
>>>>>  
>>>>> + /*
>>>>> +  * Having this flag means user mode pends on event which will never
>>>>> +  * reach due to lack of at least one CRTC for signaling
>>>>> +  */
>>>>> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>>>>> + return -EINVAL;
>>>>> +
>>>>>   return 0;
>>>>>  }
>>>>>  
>>>>>
>> Just do it, and I'll commit this to igt?
> Ack on both the kernel patch and the igt patch, feel free to push them
> both with:
>
> Acked-by: Daniel Vetter 
>
> If you do, please add the Testcase: line to the kernel patch.
Oops, missed adding the testcase to commit message, but pushed.

I've pushed the IGT testcase as well, after fixing it up to make sure it works 
as intended.

~Maarten

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Maarten Lankhorst]

Op 27-06-17 om 09:37 schreef Daniel Vetter:
> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
>>> Problem : While running IGT kms_atomic_transition test suite i encountered
>>> a hang in drmHandleEvent immediately following  an atomic_commit.
>>> After dumping the atomic state I relized that in this case there was
>>> not even one CRTC attached to the state and only disabled
>>> planes. This probably due to a commit which hadn't changed any property
>>> which would require attaching crtc state. This means drmHandleEvent
>>> will never wake up from read since without CRTC in atomic state
>>> the event fd will not be signaled.
>>>
>>> Fix: Protect against this issue by failing atomic_commit early in
>>> drm_mode_atomic_commit where such probelm can be identified.
>>>
>>> v2:
>>> Fix typos and extra newlines.
>>>
>>> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
>>> Signed-off-by: Andrey Grodzovsky 
>> Reviewed-by: Harry Wentland 
> Stalling on this hoping for the igt patch. Does it exist already?
> -Daniel
>
>> Harry
>>
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index a567310..48145bf 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
>>> *dev,
>>>  {
>>> struct drm_crtc *crtc;
>>> struct drm_crtc_state *crtc_state;
>>> -   int i, ret;
>>> +   int i, c = 0, ret;
>>>  
>>> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>>> return 0;
>>> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
>>> *dev,
>>>  
>>> crtc_state->event->base.fence = fence;
>>> }
>>> +
>>> +   c++;
>>> }
>>>  
>>> +   /*
>>> +* Having this flag means user mode pends on event which will never
>>> +* reach due to lack of at least one CRTC for signaling
>>> +*/
>>> +   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>>> +   return -EINVAL;
>>> +
>>> return 0;
>>>  }
>>>  
>>>
Just do it, and I'll commit this to igt?

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 6375fede7179..77429b3db384 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -1205,6 +1205,15 @@ static void crtc_invalid_params(struct 
kms_atomic_crtc_state *crtc_old,
crtc_commit_atomic(, plane, req, ATOMIC_RELAX_NONE,
   DRM_MODE_ATOMIC_TEST_ONLY);
 
+   /*
+* TEST_ONLY cannot be combined with DRM_MODE_PAGE_FLIP_EVENT,
+* but DRM_MODE_PAGE_FLIP_EVENT will always generate EINVAL
+* without valid crtc, so test it here.
+*/
+   crtc_commit_atomic_err(, plane, req, ATOMIC_RELAX_NONE,
+  DRM_MODE_ATOMIC_TEST_ONLY | 
DRM_MODE_PAGE_FLIP_EVENT,
+  EINVAL);
+
/* Create a blob which is the wrong size to be a valid mode. */
do_or_die(drmModeCreatePropertyBlob(crtc.state->desc->fd,
crtc.mode.data,
@@ -1356,12 +1365,12 @@ static void atomic_invalid_params(struct 
kms_atomic_crtc_state *crtc,
/* Valid pointers, but still should copy nothing. */
do_ioctl(desc->fd, DRM_IOCTL_MODE_ATOMIC, );
 
-   /* Nonsense flags. */
-   ioc.flags = 0xdeadbeef;
+   /* Valid noop, but with event set should fail. */
+   ioc.flags = DRM_MODE_PAGE_FLIP_EVENT;
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
 
-   /* Specifically forbidden combination. */
-   ioc.flags = DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_PAGE_FLIP_EVENT;
+   /* Nonsense flags. */
+   ioc.flags = 0xdeadbeef;
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
 
ioc.flags = 0;

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Maarten Lankhorst]

Op 27-06-17 om 09:37 schreef Daniel Vetter:
> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
>>> Problem : While running IGT kms_atomic_transition test suite i encountered
>>> a hang in drmHandleEvent immediately following  an atomic_commit.
>>> After dumping the atomic state I relized that in this case there was
>>> not even one CRTC attached to the state and only disabled
>>> planes. This probably due to a commit which hadn't changed any property
>>> which would require attaching crtc state. This means drmHandleEvent
>>> will never wake up from read since without CRTC in atomic state
>>> the event fd will not be signaled.
>>>
>>> Fix: Protect against this issue by failing atomic_commit early in
>>> drm_mode_atomic_commit where such probelm can be identified.
>>>
>>> v2:
>>> Fix typos and extra newlines.
>>>
>>> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
>>> Signed-off-by: Andrey Grodzovsky 
>> Reviewed-by: Harry Wentland 
> Stalling on this hoping for the igt patch. Does it exist already?
> -Daniel
>
>> Harry
>>
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index a567310..48145bf 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
>>> *dev,
>>>  {
>>> struct drm_crtc *crtc;
>>> struct drm_crtc_state *crtc_state;
>>> -   int i, ret;
>>> +   int i, c = 0, ret;
>>>  
>>> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>>> return 0;
>>> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
>>> *dev,
>>>  
>>> crtc_state->event->base.fence = fence;
>>> }
>>> +
>>> +   c++;
>>> }
>>>  
>>> +   /*
>>> +* Having this flag means user mode pends on event which will never
>>> +* reach due to lack of at least one CRTC for signaling
>>> +*/
>>> +   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>>> +   return -EINVAL;
>>> +
>>> return 0;
>>>  }
>>>  
>>>
Just do it, and I'll commit this to igt?

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 6375fede7179..77429b3db384 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -1205,6 +1205,15 @@ static void crtc_invalid_params(struct 
kms_atomic_crtc_state *crtc_old,
crtc_commit_atomic(, plane, req, ATOMIC_RELAX_NONE,
   DRM_MODE_ATOMIC_TEST_ONLY);
 
+   /*
+* TEST_ONLY cannot be combined with DRM_MODE_PAGE_FLIP_EVENT,
+* but DRM_MODE_PAGE_FLIP_EVENT will always generate EINVAL
+* without valid crtc, so test it here.
+*/
+   crtc_commit_atomic_err(, plane, req, ATOMIC_RELAX_NONE,
+  DRM_MODE_ATOMIC_TEST_ONLY | 
DRM_MODE_PAGE_FLIP_EVENT,
+  EINVAL);
+
/* Create a blob which is the wrong size to be a valid mode. */
do_or_die(drmModeCreatePropertyBlob(crtc.state->desc->fd,
crtc.mode.data,
@@ -1356,12 +1365,12 @@ static void atomic_invalid_params(struct 
kms_atomic_crtc_state *crtc,
/* Valid pointers, but still should copy nothing. */
do_ioctl(desc->fd, DRM_IOCTL_MODE_ATOMIC, );
 
-   /* Nonsense flags. */
-   ioc.flags = 0xdeadbeef;
+   /* Valid noop, but with event set should fail. */
+   ioc.flags = DRM_MODE_PAGE_FLIP_EVENT;
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
 
-   /* Specifically forbidden combination. */
-   ioc.flags = DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_PAGE_FLIP_EVENT;
+   /* Nonsense flags. */
+   ioc.flags = 0xdeadbeef;
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
 
ioc.flags = 0;

Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Maarten Lankhorst]

Op 09-06-17 om 23:30 schreef Andrey Grodzovsky:
> Problem:
> While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immidietly follwoing an atomic_commit.
> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the state and only disabled
> planes. This probably due to a commit which hadn't changed any property
> which would require attaching crtc state. This means drmHandleEvent
> will never wake up from read since without CRTC in atomic state
> the event fd will not be singnaled.
> This point to a bug in IGT but also DRM should gracefully
> fail  such scenario so no hang on user side will happen.
>
> Fix:
> Explicitly fail by failing atomic_commit early in
> drm_mode_atomic_commit where such problem can be identified.
>
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/drm_atomic.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
Patch itself looks sane, but I'm worried about failing with -EINVAL when the 
same configuration with TEST_ONLY would otherwise succeed on it.
Not sure whether we should fail or not, since sending 0 events could still be 
considered success.

I don't mind either way, but definitely something that should be discussed 
before applying.

Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Maarten Lankhorst]

Op 09-06-17 om 23:30 schreef Andrey Grodzovsky:
> Problem:
> While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immidietly follwoing an atomic_commit.
> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the state and only disabled
> planes. This probably due to a commit which hadn't changed any property
> which would require attaching crtc state. This means drmHandleEvent
> will never wake up from read since without CRTC in atomic state
> the event fd will not be singnaled.
> This point to a bug in IGT but also DRM should gracefully
> fail  such scenario so no hang on user side will happen.
>
> Fix:
> Explicitly fail by failing atomic_commit early in
> drm_mode_atomic_commit where such problem can be identified.
>
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/drm_atomic.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
Patch itself looks sane, but I'm worried about failing with -EINVAL when the 
same configuration with TEST_ONLY would otherwise succeed on it.
Not sure whether we should fail or not, since sending 0 events could still be 
considered success.

I don't mind either way, but definitely something that should be discussed 
before applying.

[PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper

[Maarten Lankhorst]

This fixes the following depmod error when building drm as a module:
depmod: ERROR: Found 6 modules in dependency cycles!
depmod: ERROR: Cycle detected: drm -> drm_kms_helper -> drm

Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the 
lvds-encoder bridge.")
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
---
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dc69175255b1..3999dffcd9ef 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,7 +24,6 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
-drm-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
@@ -35,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
drm_scdc_helper.o
 
+drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o

[PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper

[Maarten Lankhorst]

This fixes the following depmod error when building drm as a module:
depmod: ERROR: Found 6 modules in dependency cycles!
depmod: ERROR: Cycle detected: drm -> drm_kms_helper -> drm

Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the 
lvds-encoder bridge.")
Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dc69175255b1..3999dffcd9ef 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,7 +24,6 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
-drm-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
@@ -35,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
drm_scdc_helper.o
 
+drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o

Re: [PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Maarten Lankhorst]

Op 05-06-17 om 12:08 schreef Archit Taneja:
>
>
> On 06/03/2017 01:55 AM, Eric Anholt wrote:
>> Many DRM drivers have common code to make a stub connector
>> implementation that wraps a drm_panel.  By wrapping the panel in a DRM
>> bridge, all of the connector code (including calls during encoder
>> enable/disable) goes away.
>>
>> v2: Fix build with CONFIG_DRM=m, drop "dev" argument that should just
>> be the panel's dev, move kerneldoc up a level and document
>> _remove().
>> v3: Fix another breakage with CONFIG_DRM=m, fix breakage with
>> CONFIG_OF=n, move protos under CONFIG_DRM_PANEL_BRIDGE, wrap a
>> line.
>>
>> Signed-off-by: Eric Anholt 
>> Acked-by: Daniel Vetter  (v1)
>> Reviewed-by: Boris Brezillon  (v2)
>> Acked-by: Archit Taneja  (v2)
>> ---
>>
>> New version of the first patch with build fixes.  I've re-pushed to
>> get another round of kbuild test, but if it comes back clean, I'd like
>> to merge this one, the vc4 patches (unchanged), and atmel-hlcdc (acked
>> by the maintainer).  I'd be dropping my STM patch (replaced by their
>> DSI series), and mediatek (I'd like an ack from the maintainer first).
>
> Thanks, I've locally picked up this patch and the following patches from
> the v2 series:
>
> [PATCH v2 2/7] drm/vc4: Switch DSI to the panel-bridge layer, and support 
> bridges.
> [PATCH v2 3/7] drm/vc4: Switch DPI to using the panel-bridge helper.
> [PATCH v2 6/7] drm/atmel-hlcdc: Drop custom encoder cleanup func.
> [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with 
> drm_panel_bridge. 

This patch breaks support for building drm as module, because it imports some 
of the drm_kms_helper stuff.

Re: [PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Maarten Lankhorst]

Op 05-06-17 om 12:08 schreef Archit Taneja:
>
>
> On 06/03/2017 01:55 AM, Eric Anholt wrote:
>> Many DRM drivers have common code to make a stub connector
>> implementation that wraps a drm_panel.  By wrapping the panel in a DRM
>> bridge, all of the connector code (including calls during encoder
>> enable/disable) goes away.
>>
>> v2: Fix build with CONFIG_DRM=m, drop "dev" argument that should just
>> be the panel's dev, move kerneldoc up a level and document
>> _remove().
>> v3: Fix another breakage with CONFIG_DRM=m, fix breakage with
>> CONFIG_OF=n, move protos under CONFIG_DRM_PANEL_BRIDGE, wrap a
>> line.
>>
>> Signed-off-by: Eric Anholt 
>> Acked-by: Daniel Vetter  (v1)
>> Reviewed-by: Boris Brezillon  (v2)
>> Acked-by: Archit Taneja  (v2)
>> ---
>>
>> New version of the first patch with build fixes.  I've re-pushed to
>> get another round of kbuild test, but if it comes back clean, I'd like
>> to merge this one, the vc4 patches (unchanged), and atmel-hlcdc (acked
>> by the maintainer).  I'd be dropping my STM patch (replaced by their
>> DSI series), and mediatek (I'd like an ack from the maintainer first).
>
> Thanks, I've locally picked up this patch and the following patches from
> the v2 series:
>
> [PATCH v2 2/7] drm/vc4: Switch DSI to the panel-bridge layer, and support 
> bridges.
> [PATCH v2 3/7] drm/vc4: Switch DPI to using the panel-bridge helper.
> [PATCH v2 6/7] drm/atmel-hlcdc: Drop custom encoder cleanup func.
> [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with 
> drm_panel_bridge. 

This patch breaks support for building drm as module, because it imports some 
of the drm_kms_helper stuff.

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

[Maarten Lankhorst]

Op 16-12-16 om 14:17 schreef Nicolai Hähnle:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
>> 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;
>>>  int ret;
>>>
>>> -if (use_ww_ctx) {
>>> +if (use_ww_ctx && ww_ctx) {
>>> +struct ww_mutex *ww;
>>> +
>>>  ww = container_of(lock, struct ww_mutex, base);
>>>  if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
>>>  return -EALREADY;
>>
>> So I don't see the point of removing *ww from the function scope, we can
>> still compute that container_of() even if !ww_ctx, right? That would
>> safe a ton of churn below, adding all those struct ww_mutex declarations
>> and container_of() casts.
>>
>> (and note that the container_of() is a fancy NO-OP because base is the
>> first member).
>
> Sorry for taking so long to get back to you.
>
> In my experience, the undefined behavior sanitizer in GCC for userspace 
> programs complains about merely casting a pointer to the wrong type. I never 
> went into the standards rabbit hole to figure out the details. It might be a 
> C++ only thing (ubsan cannot tell the difference otherwise anyway), but that 
> was the reason for doing the change in this more complicated way.
>
> Are you sure that this is defined behavior in C? If so, I'd be happy to go 
> with the version that has less churn.
>
> I'll also get rid of those ww_mutex_lock* wrapper functions. 

ww_ctx = use_ww_ctx ? container_of : NULL ?

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

[Maarten Lankhorst]

Op 16-12-16 om 14:17 schreef Nicolai Hähnle:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
>> 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;
>>>  int ret;
>>>
>>> -if (use_ww_ctx) {
>>> +if (use_ww_ctx && ww_ctx) {
>>> +struct ww_mutex *ww;
>>> +
>>>  ww = container_of(lock, struct ww_mutex, base);
>>>  if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
>>>  return -EALREADY;
>>
>> So I don't see the point of removing *ww from the function scope, we can
>> still compute that container_of() even if !ww_ctx, right? That would
>> safe a ton of churn below, adding all those struct ww_mutex declarations
>> and container_of() casts.
>>
>> (and note that the container_of() is a fancy NO-OP because base is the
>> first member).
>
> Sorry for taking so long to get back to you.
>
> In my experience, the undefined behavior sanitizer in GCC for userspace 
> programs complains about merely casting a pointer to the wrong type. I never 
> went into the standards rabbit hole to figure out the details. It might be a 
> C++ only thing (ubsan cannot tell the difference otherwise anyway), but that 
> was the reason for doing the change in this more complicated way.
>
> Are you sure that this is defined behavior in C? If so, I'd be happy to go 
> with the version that has less churn.
>
> I'll also get rid of those ww_mutex_lock* wrapper functions. 

ww_ctx = use_ww_ctx ? container_of : NULL ?

Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress

[Maarten Lankhorst]

Op 30-11-16 om 01:35 schreef Chris Wilson:
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Peter Zijlstra <pet...@infradead.org>
> Cc: Maarten Lankhorst <d...@mblankhorst.nl>
> Cc: Nicolai Hähnle <nhaeh...@gmail.com>
> ---
>  kernel/locking/test-ww_mutex.c | 134 
> +
>  1 file changed, 134 insertions(+)
>
> diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
> index 63a5031de138..c367014f62dc 100644
> --- a/kernel/locking/test-ww_mutex.c
> +++ b/kernel/locking/test-ww_mutex.c
> @@ -21,6 +21,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Intel Corporation");
> @@ -224,6 +227,129 @@ static int test_abba(void)
>   return ret;
>  }
>  
> +struct stress {
> + struct work_struct work;
> + struct ww_mutex *locks;
> + int nlocks;
> +};
> +
> +static int *get_random_order(int count)
> +{
> + int *order;
> + int n, r, tmp;
> +
> + order = kmalloc_array(count, sizeof(*order), GFP_TEMPORARY);
> + if (!order)
> + return order;
> +
> + for (n = 0; n < count; n++)
> + order[n] = n;
> +
> + for (n = count - 1; n > 1; n--) {
> + r = get_random_int() % (n + 1);
> + if (r != n) {
> + tmp = order[n];
> + order[n] = order[r];
> + order[r] = tmp;
> + }
> + }
> +
> + return order;
> +}
> +
> +static void stress_work(struct work_struct *work)
> +{
> + struct stress *stress = container_of(work, typeof(*stress), work);
> + const int nlocks = stress->nlocks;
> + struct ww_mutex *locks = stress->locks;
> + struct ww_acquire_ctx ctx;
> + int contended = -1;
> + int *order;
> + int n, ret;
> +
> + order = get_random_order(nlocks);
> + if (!order)
> + return;
> +
> + ww_acquire_init(, _class);
> +
> +retry:
> + ret = 0;
> + for (n = 0; n < nlocks; n++) {
> + if (n == contended)
> + continue;
> +
> + ret = ww_mutex_lock([order[n]], );
> + if (ret < 0)
> + break;
> + }
What's wrong with attempting to lock the contended lock here?
Who knows, this might find some more bugs than the functional tests already do.
> + if (!ret)
> + usleep_range(1000, 2000); /* dummy load */
> +
> + if (contended > n)
> + ww_mutex_unlock([order[contended]]);
> + contended = n;
> + while (n--)
> + ww_mutex_unlock([order[n]]);
> +
> + if (ret == -EDEADLK) {
> + ww_mutex_lock_slow([order[contended]], );
> + goto retry;
> + }
> +
> + if (ret)
> + pr_err_once("ww_mutex stress test failed with %d\n", ret);
> +
> + ww_acquire_fini();
> +
> + kfree(order);
> + kfree(stress);
> +}
> +
> +static int stress(int nlocks, int count)
> +{
> + struct ww_mutex *locks;
> + struct workqueue_struct *wq;
> + int ret = -ENOMEM;
> + int n;
> +
> + wq = alloc_workqueue("test-ww_mutex", WQ_UNBOUND, 0);
> + if (!wq)
> + return -ENOMEM;
> +
> + locks = kmalloc_array(nlocks, sizeof(*locks), GFP_KERNEL);
> + if (!locks)
> + goto err;
> +
> + for (n = 0; n < nlocks; n++)
> + ww_mutex_init([n], _class);
> +
> + for (n = 0; n < count; n++) {
> + struct stress *stress;
> +
> + stress = kmalloc(sizeof(*stress), GFP_KERNEL);
> + if (!stress)
> + break;
> +
> + INIT_WORK(>work, stress_work);
> + stress->locks = locks;
> + stress->nlocks = nlocks;
> +
> + queue_work(wq, >work);
> + }
> +
> + flush_workqueue(wq);
> +
> + for (n = 0; n < nlocks; n++)
> + ww_mutex_destroy([n]);
> + kfree(locks);
> +
> + ret = 0;
> +err:
> + destroy_workqueue(wq);
> + return ret;
> +}
> +
>  static int __init test_ww_mutex_init(void)
>  {
>   int ret;
> @@ -240,6 +366,14 @@ static int __init test_ww_mutex_init(void)
>   if (ret)
>   return ret;
>  
> + ret = stress(16, 1024);
> + if (ret)
> + return ret;
> +
> + ret = stress(4096, 1024);
> + if (ret)
> + return ret;
> +
>   return 0;
>  }
>  

Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress

[Maarten Lankhorst]

Op 30-11-16 om 01:35 schreef Chris Wilson:
> Signed-off-by: Chris Wilson 
> Cc: Peter Zijlstra 
> Cc: Maarten Lankhorst 
> Cc: Nicolai Hähnle 
> ---
>  kernel/locking/test-ww_mutex.c | 134 
> +
>  1 file changed, 134 insertions(+)
>
> diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
> index 63a5031de138..c367014f62dc 100644
> --- a/kernel/locking/test-ww_mutex.c
> +++ b/kernel/locking/test-ww_mutex.c
> @@ -21,6 +21,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Intel Corporation");
> @@ -224,6 +227,129 @@ static int test_abba(void)
>   return ret;
>  }
>  
> +struct stress {
> + struct work_struct work;
> + struct ww_mutex *locks;
> + int nlocks;
> +};
> +
> +static int *get_random_order(int count)
> +{
> + int *order;
> + int n, r, tmp;
> +
> + order = kmalloc_array(count, sizeof(*order), GFP_TEMPORARY);
> + if (!order)
> + return order;
> +
> + for (n = 0; n < count; n++)
> + order[n] = n;
> +
> + for (n = count - 1; n > 1; n--) {
> + r = get_random_int() % (n + 1);
> + if (r != n) {
> + tmp = order[n];
> + order[n] = order[r];
> + order[r] = tmp;
> + }
> + }
> +
> + return order;
> +}
> +
> +static void stress_work(struct work_struct *work)
> +{
> + struct stress *stress = container_of(work, typeof(*stress), work);
> + const int nlocks = stress->nlocks;
> + struct ww_mutex *locks = stress->locks;
> + struct ww_acquire_ctx ctx;
> + int contended = -1;
> + int *order;
> + int n, ret;
> +
> + order = get_random_order(nlocks);
> + if (!order)
> + return;
> +
> + ww_acquire_init(, _class);
> +
> +retry:
> + ret = 0;
> + for (n = 0; n < nlocks; n++) {
> + if (n == contended)
> + continue;
> +
> + ret = ww_mutex_lock([order[n]], );
> + if (ret < 0)
> + break;
> + }
What's wrong with attempting to lock the contended lock here?
Who knows, this might find some more bugs than the functional tests already do.
> + if (!ret)
> + usleep_range(1000, 2000); /* dummy load */
> +
> + if (contended > n)
> + ww_mutex_unlock([order[contended]]);
> + contended = n;
> + while (n--)
> + ww_mutex_unlock([order[n]]);
> +
> + if (ret == -EDEADLK) {
> + ww_mutex_lock_slow([order[contended]], );
> + goto retry;
> + }
> +
> + if (ret)
> + pr_err_once("ww_mutex stress test failed with %d\n", ret);
> +
> + ww_acquire_fini();
> +
> + kfree(order);
> + kfree(stress);
> +}
> +
> +static int stress(int nlocks, int count)
> +{
> + struct ww_mutex *locks;
> + struct workqueue_struct *wq;
> + int ret = -ENOMEM;
> + int n;
> +
> + wq = alloc_workqueue("test-ww_mutex", WQ_UNBOUND, 0);
> + if (!wq)
> + return -ENOMEM;
> +
> + locks = kmalloc_array(nlocks, sizeof(*locks), GFP_KERNEL);
> + if (!locks)
> + goto err;
> +
> + for (n = 0; n < nlocks; n++)
> + ww_mutex_init([n], _class);
> +
> + for (n = 0; n < count; n++) {
> + struct stress *stress;
> +
> + stress = kmalloc(sizeof(*stress), GFP_KERNEL);
> + if (!stress)
> + break;
> +
> + INIT_WORK(>work, stress_work);
> + stress->locks = locks;
> + stress->nlocks = nlocks;
> +
> + queue_work(wq, >work);
> + }
> +
> + flush_workqueue(wq);
> +
> + for (n = 0; n < nlocks; n++)
> + ww_mutex_destroy([n]);
> + kfree(locks);
> +
> + ret = 0;
> +err:
> + destroy_workqueue(wq);
> + return ret;
> +}
> +
>  static int __init test_ww_mutex_init(void)
>  {
>   int ret;
> @@ -240,6 +366,14 @@ static int __init test_ww_mutex_init(void)
>   if (ret)
>   return ret;
>  
> + ret = stress(16, 1024);
> + if (ret)
> + return ret;
> +
> + ret = stress(4096, 1024);
> + if (ret)
> + return ret;
> +
>   return 0;
>  }
>  

Re: [PATCH 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

[Maarten Lankhorst]

Op 28-11-16 om 13:20 schreef Nicolai Hähnle:
> From: Nicolai Hähnle <nicolai.haeh...@amd.com>
>
> Cc: Peter Zijlstra <pet...@infradead.org>
> Cc: Ingo Molnar <mi...@redhat.com>
> Cc: Maarten Lankhorst <d...@mblankhorst.nl>
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com>
> ---
>  drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
> b/drivers/gpu/drm/vgem/vgem_fence.c
> index 488909a..e1d516f 100644
> --- a/drivers/gpu/drm/vgem/vgem_fence.c
> +++ b/drivers/gpu/drm/vgem/vgem_fence.c
> @@ -191,12 +191,12 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
>  
>   /* Expose the fence via the dma-buf */
>   ret = 0;
> - mutex_lock(>lock.base);
> + ww_mutex_lock(>lock.base, NULL);
Yuck, can we rename base to __NEVER_TOUCH_DIRECTLY_OUTSIDE_LOCKING_CORE?
It's harder to get them confused like that, even with a null context it's 
illegal to call mutex_lock/unlock directly.

~Maarten

Re: [PATCH 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

[Maarten Lankhorst]

Op 28-11-16 om 13:20 schreef Nicolai Hähnle:
> From: Nicolai Hähnle 
>
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Nicolai Hähnle 
> ---
>  drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
> b/drivers/gpu/drm/vgem/vgem_fence.c
> index 488909a..e1d516f 100644
> --- a/drivers/gpu/drm/vgem/vgem_fence.c
> +++ b/drivers/gpu/drm/vgem/vgem_fence.c
> @@ -191,12 +191,12 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
>  
>   /* Expose the fence via the dma-buf */
>   ret = 0;
> - mutex_lock(>lock.base);
> + ww_mutex_lock(>lock.base, NULL);
Yuck, can we rename base to __NEVER_TOUCH_DIRECTLY_OUTSIDE_LOCKING_CORE?
It's harder to get them confused like that, even with a null context it's 
illegal to call mutex_lock/unlock directly.

~Maarten