Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752955AbdGFFzi (ORCPT ); Thu, 6 Jul 2017 01:55:38 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:35921 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752924AbdGFFzh (ORCPT ); Thu, 6 Jul 2017 01:55:37 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:5640:0:960b:2678:e223:c1c6] In-Reply-To: <3cbc02dc-e535-7d66-923b-c9a4d0f14f13@axentia.se> References: <1499164632-5582-1-git-send-email-peda@axentia.se> <1499164632-5582-6-git-send-email-peda@axentia.se> <20170705062144.bdyngsas4uc5dj2d@phenom.ffwll.local> <3cbc02dc-e535-7d66-923b-c9a4d0f14f13@axentia.se> From: Daniel Vetter Date: Thu, 6 Jul 2017 07:55:35 +0200 X-Google-Sender-Auth: jfImD4TWrUMAho6LLFAYJHxm8ws Message-ID: Subject: Re: [PATCH v3 05/16] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set To: Peter Rosin Cc: Linux Kernel Mailing List , Boris Brezillon , dri-devel , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1525 Lines: 32 On Wed, Jul 5, 2017 at 7:50 PM, Peter Rosin wrote: >>> +retry: >>> + ret = drm_modeset_lock_all_ctx(dev, &ctx); >> >> With atomic you don't need to grab locks, this is done behind the scenes >> (as long as you handle the retry/backoff correctly). See the kerneldoc for >> the various drm_atomic_get_*_state functions. > > It doesn't work if I remove it. What is the disconnect? Good question, didn't spot this at first, but your backoff/retry logic is proken. When typing drm_modeset_lock locking code please make sure you've enabled both CONFIG_PROVE_LOCKING and CONFIG_DEBUG_WW_MUTEX_SLOWPATH. Without these two it's really easy to get this wrong. Please also read https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#kms-locking carefully plus all the kernel-doc of the various hooks. This stuff is a really tricky locking scheme, it takes a while to understand it and implement it correctly. Which is why all the locking magic is in shared code and for normal drivers no need think about it. For the fundamental algorithm, you can also check out the docs for w/w mutexes at https://www.kernel.org/doc/Documentation/locking/ww-mutex-design.txt Might also help to read a bunch of the other locking paths again, with my patches there's a few just in drm_fbdev_helper.c. I'll leave you with these snippets here since I think this is fun to learn, but when you're stuck I'm happy to help learn. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch