From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759547AbcIWMxC (ORCPT ); Fri, 23 Sep 2016 08:53:02 -0400 Received: from foss.arm.com ([217.140.101.70]:58448 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757758AbcIWMw5 (ORCPT ); Fri, 23 Sep 2016 08:52:57 -0400 Date: Fri, 23 Sep 2016 13:52:49 +0100 From: Brian Starkey To: Daniel Vetter Cc: Liviu Dudau , Sean Paul , Russell King - ARM Linux , Linux Kernel Mailing List , dri-devel Subject: Re: [PATCH] drm/i2c: tda998x: don't register the connector Message-ID: <20160923125248.GA23321@e106950-lin.cambridge.arm.com> References: <20160809224812.GJ1041@n2100.armlinux.org.uk> <20160921085738.GA27277@e106950-lin.cambridge.arm.com> <20160921162803.GS1041@n2100.armlinux.org.uk> <20160922103917.GA5632@e106950-lin.cambridge.arm.com> <20160922105155.GT1041@n2100.armlinux.org.uk> <20160922141404.GA5222@e106950-lin.cambridge.arm.com> <20160923093416.GU8917@e106497-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote: >On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau wrote: >> rmmod-ing the hdlcd module generates a WARN() splat as the vsync is still >> enabled, but we never got the call to turn off the CRTC. Brian is still >> tracking through the fbdev emulation to figure out the cause for that. > >fbdev emulation doesn't do that for you. If you need/want to shut down >all the crtcs on driver unload, you need to do that yourself. There's >atomic helpers to do that for you that for you. The problem is a sort-of circular dependency between ->lastclose (at least the common implementation of it), unregister and disabling fbdev. I want to move drm_dev_unregister() to be the first thing we do at rmmod-time. However we need to disable fbdev first, otherwise ->lastclose restores the fbdev mode, guaranteeing that vsync is turned on for drm_vsync_cleanup() to then WARN on. There's a slightly different (perceived) problem - the one that Liviu mentions - that drm_fbdev_cma_fini() doesn't disable the CRTC anyway. You say it's not the fbdev helpers' responsibility to teardown their modeset, but regardless I have nowhere to disable the CRTC if I want to do drm_dev_unregister() first; and if the CRTC isn't disabled there's always a chance of hitting the same vsync WARN even without fbdev. We *could* add an ->unload and disable everything there, but as that's deprecated I'm guessing there should be another way. Perhaps we should track ->firstopen/->lastclose pairs so we can detect that ->lastclose is being called from unregister and use it to disable everything in that case. drm_vblank_cleanup() seems to have been carried over to unregister from drm_put_dev(), but drm_dev_register() doesn't call drm_vblank_init() so it seems a little strange to have it there. I can see other drivers I'd expect to hit the same WARN but I don't have HW to test it on. Thanks, Brian >-Daniel >-- >Daniel Vetter >Software Engineer, Intel Corporation >+41 (0) 79 365 57 48 - http://blog.ffwll.ch >