From patchwork Mon Nov 5 15:10:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 10668405 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 761FC15A6 for ; Mon, 5 Nov 2018 15:10:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5ED5929A1D for ; Mon, 5 Nov 2018 15:10:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 021FE29433; Mon, 5 Nov 2018 15:10:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6FC59299EE for ; Mon, 5 Nov 2018 15:10:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729751AbeKFAah (ORCPT ); Mon, 5 Nov 2018 19:30:37 -0500 Received: from perceval.ideasonboard.com ([213.167.242.64]:60896 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729588AbeKFAah (ORCPT ); Mon, 5 Nov 2018 19:30:37 -0500 Received: from avalon.bb.dnainternet.fi (dfj612ybrt5fhg77mgycy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:2e86:4862:ef6a:2804]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 3FC80562; Mon, 5 Nov 2018 16:10:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1541430626; bh=JAP52wkWE0Zru5JVoPMXuCI8MYMm+EcHgE9Lyd/gxdI=; h=From:To:Cc:Subject:Date:From; b=v72mARQhXXZHYF41MVe9K+sn3Tyq6nztOONaxZ7YCATqoMU1bRoyHI/Y0z/ffY+x4 dSMjQyNldYfPIiCngxei7ijy1uuPTyHS0s3vro16pqNtmi8lMgON871cRvoRn9Rmq+ lT0djvrHTQznK8TxprwlOhYc03qziwMUv98uuaIQ= From: Laurent Pinchart To: dri-devel@lists.freedesktop.org Cc: linux-omap@vger.kernel.org, Tomi Valkeinen , Tony Lindgren Subject: [PATCH v2 0/4] omapdrm: Fix runtime PM issues at module load and unload time Date: Mon, 5 Nov 2018 17:10:24 +0200 Message-Id: <20181105151028.4091-1-laurent.pinchart@ideasonboard.com> X-Mailer: git-send-email 2.18.1 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello, This series fixes crashes in the omapdss driver at both load and unload time, due to runtime PM problems related to probe deferral. The bugs got introduced in v4.20-rc, this should thus be considered as v4.20 fixes. At the core of the problem comes commit 27d624527d99 ("drm/omap: dss: Acquire next dssdev at probe time") which can cause probe deferral for the DSS when the encoder and panel modules are not loaded yet. As the omapdss module contains drivers for the DSS and all its children, this results in the internal encoders being probed before the DSS. Missing runtime PM handling around register access then caused imprecise external aborts. Patch 1/4 moves population of the DSS children from arch code to the omapdss driver. This prevents the DSS children from being probed before the DSS. The change can be considered as a workaround in the sense that runtime PM of the DSS children should operate correctly even when the DSS probe fail. However, given that reducing the amount of arch code is an improvement in itself, I believe the solution to be acceptable. Patches 2/4 and 3/4 then ensure that the HDMI4 and DSI devices are active at bind and probe time respectively, in order to access hardware registers there. Patch 4/4 finally works around an issue in the runtime PM handlers of the internal encoders that try to manage the DISPC runtime PM state when the DISPC may not be available. This is a bit of a hack and should be fixed by moving DISPC runtime PM handling out of the internal encoders runtime PM handlers, but that will require more testing and should not be rushed during the -rc period. Tony, this series should fix the issues you've reported. I have tested it on both Pandaboard and AM57xx EVM, loading and unloading modules and exercising the display with kmstest. Patch 1/4 touches both the mach-omap2 and omapdss. Would it be OK merging it through the DRM tree ? I don't think there's a risk of conflict during the v4.20-rc cycle. Laurent Pinchart (4): drm/omap: Populate DSS children in omapdss driver drm/omap: hdmi4: Ensure the device is active during bind drm/omap: dsi: Ensure the device is active during probe drm/omap: Work around missing DISPC in runtime PM handlers arch/arm/mach-omap2/display.c | 111 +++++++++++++--------------- drivers/gpu/drm/omapdrm/dss/dsi.c | 29 ++++++-- drivers/gpu/drm/omapdrm/dss/dss.c | 11 ++- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 29 ++++++-- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 19 ++++- drivers/gpu/drm/omapdrm/dss/venc.c | 19 ++++- 6 files changed, 140 insertions(+), 78 deletions(-)