From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brian Norris Subject: Re: [PATCH] drm/rockchip: Allow driver to be shutdown on reboot/kexec Date: Wed, 5 Dec 2018 09:42:11 -0800 Message-ID: <20181205174209.GA224281@google.com> References: <20180805124807.18169-1-marc.zyngier@arm.com> <20181205030127.GA200921@google.com> <1693737.bVF0dcvACY@diego> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Marc Zyngier Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, Guenter Roeck , linux-arm-kernel@lists.infradead.org List-Id: linux-rockchip.vger.kernel.org SGksCgpPbiBXZWQsIERlYyAwNSwgMjAxOCBhdCAwMjoyODo0OFBNICswMDAwLCBNYXJjIFp5bmdp ZXIgd3JvdGU6Cj4gT24gMDUvMTIvMjAxOCAxNDoxMSwgSGVpa28gU3TDvGJuZXIgd3JvdGU6Cj4g PiBBbSBNaXR0d29jaCwgNS4gRGV6ZW1iZXIgMjAxOCwgMDQ6MDE6MzQgQ0VUIHNjaHJpZWIgQnJp YW4gTm9ycmlzOgo+ID4+IE9uIFN1biwgQXVnIDA1LCAyMDE4IGF0IDAxOjQ4OjA3UE0gKzAxMDAs IE1hcmMgWnluZ2llciB3cm90ZToKPiA+Pj4gTGVhdmluZyB0aGUgRFJNIGRyaXZlciBlbmFibGVk IG9uIHJlYm9vdCBvciBrZXhlYyBoYXMgdGhlIGFubm95aW5nCj4gPj4+IGVmZmVjdCBvZiBsZWF2 aW5nIHRoZSBkaXNwbGF5IGdlbmVyYXRpbmcgdHJhbnNhY3Rpb25zIHdoaWxzdCB0aGUKPiA+Pj4g SU9NTVUgaGFzIGJlZW4gc2h1dCBkb3duLgo+ID4+Pgo+ID4+PiBJbiB0dXJuLCB0aGUgSU9NTVUg ZHJpdmVyICh3aGljaCBzaGFyZXMgaXRzIGludGVycnVwdCBsaW5lIHdpdGgKPiA+Pj4gdGhlIFZP UCkgc3RhcnRzIHdhcm5pbmcgZWl0aGVyIG9uIHNodXRkb3duIG9yIHdoZW4gZW50ZXJpbmcgdGhl Cj4gPj4+IHNlY29uZGFyeSBrZXJuZWwgaW4gdGhlIGtleGVjIGNhc2UgKG5vdGhpbmcgaXMgZXhw ZWN0ZWQgb24gdGhhdAo+ID4+PiBmcm9udCkuCj4gPj4+Cj4gPj4+IEEgY2hlYXAgd2F5IG9mIGVu c3VyaW5nIHRoYXQgdGhpbmdzIGFyZSBuaWNlbHkgc2h1dCBkb3duIGlzIHRvCj4gPj4+IHJlZ2lz dGVyIGEgc2h1dGRvd24gY2FsbGJhY2sgaW4gdGhlIHBsYXRmb3JtIGRyaXZlci4KPiA+Pj4KPiA+ Pj4gU2lnbmVkLW9mZi1ieTogTWFyYyBaeW5naWVyIDxtYXJjLnp5bmdpZXJAYXJtLmNvbT4KPiA+ Pj4gLS0tCj4gPj4KPiA+PiBUaGlzIHBhdGNoIG1hZGUgaXQgaW50byA0LjIwLXJjMSBhcyB3ZWxs IGFzIC1zdGFibGUsIGFuZCBpdCBoYXMgY2F1c2VkCj4gPj4gcmVncmVzc2lvbnMgZm9yIG1lLCBv biB0aGUgS2V2aW4gYW5kIFNjYXJsZXQgWzFdIFJLMzM5OSBwbGF0Zm9ybXMuCj4gPj4KPiA+PiBP bgo+ID4+IHNodXRkb3duL3JlYm9vdCwgSSBzZWUgdGhpczoKPiA+Pgo+ID4+IFsgICA5NC43NDI1 NTldIFdBUk5JTkc6IENQVTogNCBQSUQ6IDIwMzUgYXQKPiA+PiBkcml2ZXJzL2dwdS9kcm0vZHJt X21vZGVfY29uZmlnLmM6NDc3IGRybV9tb2RlX2NvbmZpZ19jbGVhbnVwKzB4MWM0LzB4Mjk0Cj4g Pj4gLi4uCi4uLgo+ID4+IEFueXdheSwgdGhlIGFib3ZlIHdhcm5pbmdzIG9jY3VyIG9uIHY0LjIw LXJjLCB3aGljaCBJIHRoaW5rIGlzCj4gPj4ganVzdGlmaWNhdGlvbiBlbm91Z2ggZm9yIGEgcmV2 ZXJ0Lgo+ID4gCj4gPiBUaGF0J3Mgc3RyYW5nZS4gSSByZW1lbWJlciB0ZXN0aW5nIHF1aXRlIGEg bnVtYmVyIG9mIHNodXRkb3duL3JlYm9vdAo+ID4gY3ljbGVzIGJlZm9yZSBhcHBseWluZyB0aGF0 IHBhdGNoLiBBbmQgZm9yIGdvb2QgbWVhc3VyZSBkaWQgdGhlIHNhbWUKPiA+IGFnYWluIHJpZ2h0 IG5vdy4KPiA+IAo+ID4gLSBLZXZpbiwgd2l0aCBuZXRib290IGZpcm13YXJlLCBib290aW5nIGlu dG8gRGViaWFuK2NvbnNvbGUgb25seQo+ID4gLSBCb2IsIHdpdGggc3RvY2sgZmlybXdhcmUsIGJv b3RpbmcgaW50byBEZWJpYW4rS0RFIFBsYXNtYQo+ID4gLSBTY2FybGV0LCB3aXRoIHN0b2NrIGZp cm13YXJlLCBib290aW5nIGludG8gRGViaWFuK0tERSBQbGFzbWEKPiA+IAo+ID4gV2l0aCBzb21l IHJhbmRvbSBudW1iZXIgb2YgcmVib290IGFuZCBzaHV0ZG93bnMgb24gZWFjaCBJIGRpZG4ndAo+ ID4gc2VlIGFueSB3YXJuaW5ncyBhdCBhbGwuCj4gCj4gQW5kIEkndmUgYmVlbiB1c2luZyB0aGlz IHZlcnkgcGF0Y2ggZm9yIHF1aXRlIGEgd2hpbGUgbm93Lgo+IAo+IEJlZm9yZSBzdWdnZXN0aW5n IGEgcmV2ZXJ0LCBJJ2QgcmF0aGVyIHdlIHVuZGVyc3RhbmQgd2hhdCBpcyBnb2luZyBvbiwKPiBh bmQgd2h5IGlzIHRoZSBEUk0gbGF5ZXIgY3JhcHBpbmcgaXRzZWxmIHRoYXQgYmFkbHkgZm9yIGEg bGVnaXRpbWF0ZQo+IG9wZXJhdGlvbiAoaXQgaXMgY2VydGFpbmx5IGJldHRlciB0byBoYXZlIGEg c2h1dGRvd24gdGhhbiB0byBsZXQgdGhlIFZPUAo+IHNjYW4gb3V0IGNyYXAgb25jZSB0aGUgSU9N TVUgaGFzIGJlZW4gc2h1dCBkb3duKS4gSW4gc2hvcnQsIGRvbid0IHNob290Cj4gdGhlIG1lc3Nl bmdlci4KCkkgaG9uZXN0bHkgZG9uJ3Qga25vdyBtdWNoIGF0IGFsbCBhYm91dCBEUk0uIEJ1dCBJ IGRvIHNlZSB0aGlzIHByb2JsZW0Kb24gNC4xOS55IGFsc28gKGFuZCBwcm9iYWJseSA0LjE0Lnkp LCBub3cgdGhhdCB0aGlzIHBhdGNoIHdhcyBpbmNsdWRlZAp0aGVyZS4KCkknbSBmaW5lIHdpdGgg dHJ5aW5nIHRvICJmaXggZm9yd2FyZCIgaW4gbWFpbmxpbmUsIGJ1dCB1bmZvcnR1bmF0ZWx5LApp dCdzIHVzdWFsbHkgcXVpdGUgZGlmZmljdWx0IHRvIGdldCBHcmVnIHRvIGRyb3AgdGhpbmdzIGZy b20gLXN0YWJsZSwKZXNwZWNpYWxseSB3aGVuIHRoZSByZWdyZXNzaW9uIGlzIGFscmVhZHkgcHVz aGVkIHRvIGEgcmVsZWFzZS4gVGhhdCdzCndoeSBJJ2QgcHJvcG9zZSBhIHJldmVydCBmaXJzdCwg d2hpY2ggY2FuIGJlIHNlbnQgYmFjayB0byAtc3RhYmxlIHdoaWxlCnRoaW5ncyBhcmUgZmlndXJl ZCBvdXQuCgpJJ20gYWxzbyB3aWxsaW5nIHRvIHRlc3QgYW55IHVwZGF0ZXMsIGlmIHlvdSBoYXZl IGJldHRlciBzdWdnZXN0aW9ucy4KCj4gPj4gSSBwbGFuIHRvIHN1Ym1pdCBhIHJldmVydCB3aGlj aCBJIGhvcGUgY2FuIGdvIHRvIDQuMjAgYXMgd2VsbCBhcwo+ID4+IC1zdGFibGUuIEknZCBob3Bl IHRoZSByZW1vdmUoKS9zaHV0ZG93bigpIHBhdGhzIHNob3VsZCBiZSBmaXhlZCBiZWZvcmUKPiA+ PiB0aGlzIGdldHMgYXBwbGllZCBhZ2FpbiwgYW5kIHRoYXQgaXQgZG9lcyBub3QgZ2V0IHNoaXBw ZWQgdG8gLXN0YWJsZQo+ID4+IGtlcm5lbHMuCj4gPiAKPiA+IEJ1dCBqdWRnaW5nIGJ5IHRoZSBm YWN0IHRoYXQgdGhlIHdhcm5pbmcgaW5kaWNhdGVzIHRoYXQgc29tdGhpbmcgaXMgc3RpbGwKPiA+ IGhvbGRpbmcgb250byBhIGZyYW1lYnVmZmVyIGFuZCBhIHJtbW9kIHJvY2tjaGlwZHJtIGlzIG5v dCBwb3NzaWJsZQo+ID4gYXQgcnVucnRpbWUgZm9yIGxpa2VseSB0aGUgc2FtZSByZWFzb24sIEkg Z3Vlc3Mgd2UgcmVhbGx5IG1pZ2h0IGJlIGNyZWF0aW5nCj4gPiBhIHByb2JsZW0gd2l0aCB0aGF0 IHNodXRkb3duLgo+IAo+IFRoYXQncyBhIHBvdGVudGlhbCByb290IGNhdXNlLgo+IAo+ID4gCj4g PiBDYW4geW91IG1heWJlIGdpdmUgImRybS9yb2NrY2hpcDogc2h1dGRvd24gZHJtIHN1YnN5c3Rl bSBvbiBzaHV0ZG93biIgWzJdCj4gPiBhIHRyeT8gV2hlbiB0aGUgdW5kZXJseWluZyBpc3N1ZSBv ZiByZWJvb3Rpbmcgc3VyZmFjZWQgd2UgaGFkIDIgY29tcGV0aW5nIAo+ID4gc29sdXRpb25zLCBz byB3ZSBhdCBsZWFzdCBkb24ndCByZW9wZW4gdGhlIGlzc3VlLCB0aGF0IHBlb3BsZSBoYXZlIHBy b2JsZW1zCj4gPiByZWJvb3Rpbmc/CgpJJ2xsIHRyeSB0byBnaXZlIHRoYXQgYSBzcGluLgoKPiBr ZXhlYyB3b3JraW5nIGlzIGNlcnRhaW5seSBzb21ldGhpbmcgSSBuZWVkLiBBbmQgSSdkIGxpa2Ug dG8gdW5kZXJzdGFuZAo+IHdoeSBCcmlhbiBzZWVzIHRoaXMgYW5kIG5vYm9keSBlbHNlLgoKRm9y IG9uZSwgSSdtIGFjdHVhbGx5IHJ1bm5pbmcgQ2hyb21lIE9TLiBNeSB0ZXN0cyBjdXJyZW50bHkg ZG9uJ3QgaGF2ZQp0aGUgZnVsbCBDaHJvbWUgVUkgd29ya2luZywgc2luY2UgQ2hyb21lIE9TIGhh cyBzb21lIGJhc2ljIGdyYXBoaWNzIEFQSQpyZXF1aXJlbWVudHMgYW5kIHRoZXJlJ3Mgbm8gTWFs aSBHUFUgZHJpdmVyIHVwc3RyZWFtIChzbyBJIGdldCByZWxlZ2F0ZWQKdG8gb3VyIHNwbGFzaCBz Y3JlZW4gYW5kIGNvbnNvbGUgbWFuYWdlciwgZnJlY29uLCBpbnN0ZWFkKS4gQnV0IHNvbWUKcGVv cGxlIGhhdmUgYSBzb2Z0d2FyZS1yZW5kZXJlZCBsbHZtcGlwZSBiYWNrZW5kIHdvcmtpbmcsIGFu ZCB0aGV5Cmxpa2VseSB3b3VsZCBzZWUgdGhlIHNhbWUgcHJvYmxlbS4KCk1heWJlIGNvbW1vbiBM aW51eCBkaXN0cm9zIHRyZWF0ICJubyBHUFUiIHRvbyBzaW1wbGlzdGljYWxseSBhbmQgZG9uJ3QK cmVhbGx5IGV4ZXJjaXNlIHRoZSBEUk0gZnJhbWV3b3JrIG11Y2guIEkgZHVubm8uCgpCcmlhbgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwg bWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A343C04EB9 for ; Wed, 5 Dec 2018 17:42:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D1A112084C for ; Wed, 5 Dec 2018 17:42:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="byvmC21H"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="mR12I0Wg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1A112084C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WpiSkZf7oq2QGZ1N1YTRYMakTFDsFacaoeLZqqpBk0M=; b=byvmC21HaN6Wps EpYe/5/JzV0u1FGQFv14P/j+fXxIqGGX+KOqBUIYZJqk5PGstjVwNhifaDoga0R3Sim1Yn6DhFE3M JHcBzCenOAkh7d4rgTHNcjJiJI2UkgGxbHNW7VcKoLSk0tvYpsMAZI0pOHc1g2kZsbeP71+YGwh+a iJmptiDfj+TZl2DNh995cM8Dy+eBlmaeuYZbfHETDxA212K4prixd0GjbYAiGay3AOxnF/g2lWc6b /Oh1oitVFBLrIEd9J2mAR7Tc9q2dxNX5oL4ejhJkydm/9GzD2kCt/naUA3SXp1ehEqoX9gP+KQ9kN B1W3ai5o6ujW5XXJvYlA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gUbBy-0004aj-MI; Wed, 05 Dec 2018 17:42:34 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gUbBp-0004Yl-BF for linux-arm-kernel@lists.infradead.org; Wed, 05 Dec 2018 17:42:30 +0000 Received: by mail-pg1-x541.google.com with SMTP id z10so9334382pgp.7 for ; Wed, 05 Dec 2018 09:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=H82VOLH32FQsGyx2BnmP11meBb7aRxjVMwmR5I4yftQ=; b=mR12I0WgDkJJk9doQzmB5CI33SvEW0wmcF1ZxUAeOImCl+7uM65cv5mpJasfv4Kw78 5PzNV0naYFDJSQQiAUenHvkYN3vmjqhtZ1vdAqr0Xi87AwSbU0JKtcxWW+Jtr6aBluxK WrzJZAUa/m7NkA609kvLKDQ038DKX+sZyE53k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=H82VOLH32FQsGyx2BnmP11meBb7aRxjVMwmR5I4yftQ=; b=mKuOfLoMOp+BmGiV6nx3WzZS0tlExyHUCCnfhv4IWYD4Qex4HLLTfKNeql/SpOFwzo 6zYmApkpm0qJzFBu7f3yN+rBYu5iL/0go2/RuY/RDntA2pYtE571jbe/unK/TnNUzz0W RHyZRgB8KQr8ElhId1M94H/xZImZu+yVnY9msJq57t3RHj8cixQE/+TYWgitDuqTx0A9 VJKoBZ5QcXmPTrWtmySf4ykPXwvCcjddU7ss6e1C6fmhWEDsl7g0WaTxbBdEIbtcu24c kNxrY/rev7/OCoBocqZ8lL9V3znlKLZmOdsIfR9p24PeMe+pdEQhESSvukTQ/V1iIKmU TuOQ== X-Gm-Message-State: AA+aEWZY7zPTcTUXh53i0NYi6p7yC0YrZ2J1WNq92hNk98Cxu4UJjJqI u17Xr/YEeXeTH0HMuScbtY3YwQ== X-Google-Smtp-Source: AFSGD/Vya30S7Xoif9HN5bgrX0P/yaC6sJypQyj6h1u0MMLshTlK1kv74VJG/+5PyCQq7ftlVWWx2Q== X-Received: by 2002:a62:3241:: with SMTP id y62mr25246550pfy.178.1544031734383; Wed, 05 Dec 2018 09:42:14 -0800 (PST) Received: from google.com ([2620:15c:202:1:534:b7c0:a63c:460c]) by smtp.gmail.com with ESMTPSA id g11sm26168194pfo.139.2018.12.05.09.42.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Dec 2018 09:42:13 -0800 (PST) Date: Wed, 5 Dec 2018 09:42:11 -0800 From: Brian Norris To: Marc Zyngier Subject: Re: [PATCH] drm/rockchip: Allow driver to be shutdown on reboot/kexec Message-ID: <20181205174209.GA224281@google.com> References: <20180805124807.18169-1-marc.zyngier@arm.com> <20181205030127.GA200921@google.com> <1693737.bVF0dcvACY@diego> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181205_094226_459506_993D9ABC X-CRM114-Status: GOOD ( 29.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heiko =?iso-8859-1?Q?St=FCbner?= , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, Guenter Roeck , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Wed, Dec 05, 2018 at 02:28:48PM +0000, Marc Zyngier wrote: > On 05/12/2018 14:11, Heiko St=FCbner wrote: > > Am Mittwoch, 5. Dezember 2018, 04:01:34 CET schrieb Brian Norris: > >> On Sun, Aug 05, 2018 at 01:48:07PM +0100, Marc Zyngier wrote: > >>> Leaving the DRM driver enabled on reboot or kexec has the annoying > >>> effect of leaving the display generating transactions whilst the > >>> IOMMU has been shut down. > >>> > >>> In turn, the IOMMU driver (which shares its interrupt line with > >>> the VOP) starts warning either on shutdown or when entering the > >>> secondary kernel in the kexec case (nothing is expected on that > >>> front). > >>> > >>> A cheap way of ensuring that things are nicely shut down is to > >>> register a shutdown callback in the platform driver. > >>> > >>> Signed-off-by: Marc Zyngier > >>> --- > >> > >> This patch made it into 4.20-rc1 as well as -stable, and it has caused > >> regressions for me, on the Kevin and Scarlet [1] RK3399 platforms. > >> > >> On > >> shutdown/reboot, I see this: > >> > >> [ 94.742559] WARNING: CPU: 4 PID: 2035 at > >> drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x1c4/0x= 294 > >> ... ... > >> Anyway, the above warnings occur on v4.20-rc, which I think is > >> justification enough for a revert. > > = > > That's strange. I remember testing quite a number of shutdown/reboot > > cycles before applying that patch. And for good measure did the same > > again right now. > > = > > - Kevin, with netboot firmware, booting into Debian+console only > > - Bob, with stock firmware, booting into Debian+KDE Plasma > > - Scarlet, with stock firmware, booting into Debian+KDE Plasma > > = > > With some random number of reboot and shutdowns on each I didn't > > see any warnings at all. > = > And I've been using this very patch for quite a while now. > = > Before suggesting a revert, I'd rather we understand what is going on, > and why is the DRM layer crapping itself that badly for a legitimate > operation (it is certainly better to have a shutdown than to let the VOP > scan out crap once the IOMMU has been shut down). In short, don't shoot > the messenger. I honestly don't know much at all about DRM. But I do see this problem on 4.19.y also (and probably 4.14.y), now that this patch was included there. I'm fine with trying to "fix forward" in mainline, but unfortunately, it's usually quite difficult to get Greg to drop things from -stable, especially when the regression is already pushed to a release. That's why I'd propose a revert first, which can be sent back to -stable while things are figured out. I'm also willing to test any updates, if you have better suggestions. > >> I plan to submit a revert which I hope can go to 4.20 as well as > >> -stable. I'd hope the remove()/shutdown() paths should be fixed before > >> this gets applied again, and that it does not get shipped to -stable > >> kernels. > > = > > But judging by the fact that the warning indicates that somthing is sti= ll > > holding onto a framebuffer and a rmmod rockchipdrm is not possible > > at runrtime for likely the same reason, I guess we really might be crea= ting > > a problem with that shutdown. > = > That's a potential root cause. > = > > = > > Can you maybe give "drm/rockchip: shutdown drm subsystem on shutdown" [= 2] > > a try? When the underlying issue of rebooting surfaced we had 2 competi= ng = > > solutions, so we at least don't reopen the issue, that people have prob= lems > > rebooting? I'll try to give that a spin. > kexec working is certainly something I need. And I'd like to understand > why Brian sees this and nobody else. For one, I'm actually running Chrome OS. My tests currently don't have the full Chrome UI working, since Chrome OS has some basic graphics API requirements and there's no Mali GPU driver upstream (so I get relegated to our splash screen and console manager, frecon, instead). But some people have a software-rendered llvmpipe backend working, and they likely would see the same problem. Maybe common Linux distros treat "no GPU" too simplistically and don't really exercise the DRM framework much. I dunno. Brian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48620C04EB9 for ; Wed, 5 Dec 2018 17:42:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F149208E7 for ; Wed, 5 Dec 2018 17:42:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="mR12I0Wg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F149208E7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728197AbeLERmS (ORCPT ); Wed, 5 Dec 2018 12:42:18 -0500 Received: from mail-pg1-f195.google.com ([209.85.215.195]:37075 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727514AbeLERmP (ORCPT ); Wed, 5 Dec 2018 12:42:15 -0500 Received: by mail-pg1-f195.google.com with SMTP id 80so9338471pge.4 for ; Wed, 05 Dec 2018 09:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=H82VOLH32FQsGyx2BnmP11meBb7aRxjVMwmR5I4yftQ=; b=mR12I0WgDkJJk9doQzmB5CI33SvEW0wmcF1ZxUAeOImCl+7uM65cv5mpJasfv4Kw78 5PzNV0naYFDJSQQiAUenHvkYN3vmjqhtZ1vdAqr0Xi87AwSbU0JKtcxWW+Jtr6aBluxK WrzJZAUa/m7NkA609kvLKDQ038DKX+sZyE53k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=H82VOLH32FQsGyx2BnmP11meBb7aRxjVMwmR5I4yftQ=; b=SXy2vyloUC9J2GOhtWqTrh1VLMsmnM05Kxe8039sdy8f1a7Dqlu68x82MPpfvrRMG2 VUBDHcEIA26iYpg9u2K6LXxb8/CmM7GTnVxaOAoVUPgJGwxknkRtL9Be6TMkM/mfJG4I jHMNNpUQYoHGe10AuvYw3vzcPw16s4i9jVnwqtVWnC4yHZL4GylzJcOgj+lA9mFiMil8 YOnqo3hjAb4Y+n58UlLcB+Ah0LqlOJH3gwfKHMKS+WtaZbM3fPOg4SPMX37upbK2BGN8 yMAxtdpr3OtBg+bpFK0iTHP64tJzcHn4ILQlg+7QrxGWUFTNaw/y+BWgtER+9EC2ZvFX /lkg== X-Gm-Message-State: AA+aEWYfOqhW+HnmWhCzYWpn6TOqR5G98Syg437PrqdbIm4Uf2C1q4uy xfsj1t1OqtrWNLnT5SrqFSA7bA== X-Google-Smtp-Source: AFSGD/Vya30S7Xoif9HN5bgrX0P/yaC6sJypQyj6h1u0MMLshTlK1kv74VJG/+5PyCQq7ftlVWWx2Q== X-Received: by 2002:a62:3241:: with SMTP id y62mr25246550pfy.178.1544031734383; Wed, 05 Dec 2018 09:42:14 -0800 (PST) Received: from google.com ([2620:15c:202:1:534:b7c0:a63c:460c]) by smtp.gmail.com with ESMTPSA id g11sm26168194pfo.139.2018.12.05.09.42.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Dec 2018 09:42:13 -0800 (PST) Date: Wed, 5 Dec 2018 09:42:11 -0800 From: Brian Norris To: Marc Zyngier Cc: Heiko =?iso-8859-1?Q?St=FCbner?= , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, Guenter Roeck , linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/rockchip: Allow driver to be shutdown on reboot/kexec Message-ID: <20181205174209.GA224281@google.com> References: <20180805124807.18169-1-marc.zyngier@arm.com> <20181205030127.GA200921@google.com> <1693737.bVF0dcvACY@diego> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Dec 05, 2018 at 02:28:48PM +0000, Marc Zyngier wrote: > On 05/12/2018 14:11, Heiko Stübner wrote: > > Am Mittwoch, 5. Dezember 2018, 04:01:34 CET schrieb Brian Norris: > >> On Sun, Aug 05, 2018 at 01:48:07PM +0100, Marc Zyngier wrote: > >>> Leaving the DRM driver enabled on reboot or kexec has the annoying > >>> effect of leaving the display generating transactions whilst the > >>> IOMMU has been shut down. > >>> > >>> In turn, the IOMMU driver (which shares its interrupt line with > >>> the VOP) starts warning either on shutdown or when entering the > >>> secondary kernel in the kexec case (nothing is expected on that > >>> front). > >>> > >>> A cheap way of ensuring that things are nicely shut down is to > >>> register a shutdown callback in the platform driver. > >>> > >>> Signed-off-by: Marc Zyngier > >>> --- > >> > >> This patch made it into 4.20-rc1 as well as -stable, and it has caused > >> regressions for me, on the Kevin and Scarlet [1] RK3399 platforms. > >> > >> On > >> shutdown/reboot, I see this: > >> > >> [ 94.742559] WARNING: CPU: 4 PID: 2035 at > >> drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x1c4/0x294 > >> ... ... > >> Anyway, the above warnings occur on v4.20-rc, which I think is > >> justification enough for a revert. > > > > That's strange. I remember testing quite a number of shutdown/reboot > > cycles before applying that patch. And for good measure did the same > > again right now. > > > > - Kevin, with netboot firmware, booting into Debian+console only > > - Bob, with stock firmware, booting into Debian+KDE Plasma > > - Scarlet, with stock firmware, booting into Debian+KDE Plasma > > > > With some random number of reboot and shutdowns on each I didn't > > see any warnings at all. > > And I've been using this very patch for quite a while now. > > Before suggesting a revert, I'd rather we understand what is going on, > and why is the DRM layer crapping itself that badly for a legitimate > operation (it is certainly better to have a shutdown than to let the VOP > scan out crap once the IOMMU has been shut down). In short, don't shoot > the messenger. I honestly don't know much at all about DRM. But I do see this problem on 4.19.y also (and probably 4.14.y), now that this patch was included there. I'm fine with trying to "fix forward" in mainline, but unfortunately, it's usually quite difficult to get Greg to drop things from -stable, especially when the regression is already pushed to a release. That's why I'd propose a revert first, which can be sent back to -stable while things are figured out. I'm also willing to test any updates, if you have better suggestions. > >> I plan to submit a revert which I hope can go to 4.20 as well as > >> -stable. I'd hope the remove()/shutdown() paths should be fixed before > >> this gets applied again, and that it does not get shipped to -stable > >> kernels. > > > > But judging by the fact that the warning indicates that somthing is still > > holding onto a framebuffer and a rmmod rockchipdrm is not possible > > at runrtime for likely the same reason, I guess we really might be creating > > a problem with that shutdown. > > That's a potential root cause. > > > > > Can you maybe give "drm/rockchip: shutdown drm subsystem on shutdown" [2] > > a try? When the underlying issue of rebooting surfaced we had 2 competing > > solutions, so we at least don't reopen the issue, that people have problems > > rebooting? I'll try to give that a spin. > kexec working is certainly something I need. And I'd like to understand > why Brian sees this and nobody else. For one, I'm actually running Chrome OS. My tests currently don't have the full Chrome UI working, since Chrome OS has some basic graphics API requirements and there's no Mali GPU driver upstream (so I get relegated to our splash screen and console manager, frecon, instead). But some people have a software-rendered llvmpipe backend working, and they likely would see the same problem. Maybe common Linux distros treat "no GPU" too simplistically and don't really exercise the DRM framework much. I dunno. Brian