From patchwork Thu Dec 6 17:56:47 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thierry Reding X-Patchwork-Id: 10716531 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 1518215A6 for ; Thu, 6 Dec 2018 17:56:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 04C2A2F036 for ; Thu, 6 Dec 2018 17:56:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EC3712F03B; Thu, 6 Dec 2018 17:56:56 +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=-5.2 required=2.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D46572F036 for ; Thu, 6 Dec 2018 17:56:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 49C286E621; Thu, 6 Dec 2018 17:56:53 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2B1386E621 for ; Thu, 6 Dec 2018 17:56:52 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id p4so1373020wrt.7 for ; Thu, 06 Dec 2018 09:56:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=uBTSCDzXLqxhUgRxL261wLjMonJqr2DVCCdO2/tNrtA=; b=h7ljXwxfZ8GrtM8Kzd9LQ/2LJRG6v0L2ioABHkD9T5y5dVLyYhyUN56V33M+L1IAvm pbTVGGpPgRfqO1Nt7QuwpwhJvgDKN8GaNBmWu84fiYOc/If5Qf5gtkKFUJXFMhhHlKi6 MeBN32E5Ez8WIFa4EYrP6KloIDNbP29jI8hfqBjrOKC0Tdz7f0TIlO1kpdHOznPqluBa yd93AY4DzXsqPcMK/7W4fWPQ8z83TkoakZ7VYmptIAweBJtsoHUCshrsYQHTwokq+JO7 Vlm+O1+2y9KPYpUz8SYH9LZKwWp3hgGyYSt4fZqfmZKw7rPQJALmNnpLq3inN83Ny4B6 R/Nw== X-Gm-Message-State: AA+aEWb1Mos6Ki5hbGLLmiO8hsdJF0w04/K4lrDB896Mh9e1/6yTmk7Z 3tQkkZQItSdnSf6Z28eJEf4= X-Google-Smtp-Source: AFSGD/Vxt/iC0q8pkp4zxWaXrdFmkonMYZUYmSwvhKE4fKHjHYM4GPirKNGx6P6Ew3WGpDGRbnrRww== X-Received: by 2002:adf:f848:: with SMTP id d8mr9721808wrq.178.1544119010667; Thu, 06 Dec 2018 09:56:50 -0800 (PST) Received: from localhost (pD9E51040.dip0.t-ipconnect.de. [217.229.16.64]) by smtp.gmail.com with ESMTPSA id j202sm2529199wmf.15.2018.12.06.09.56.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Dec 2018 09:56:49 -0800 (PST) From: Thierry Reding To: Thierry Reding Subject: [PATCH] drm/tegra: sor: Reset the SOR if possible Date: Thu, 6 Dec 2018 18:56:47 +0100 Message-Id: <20181206175647.29019-1-thierry.reding@gmail.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP From: Thierry Reding If the SOR is already up and running when the kernel driver is probed, setting a mode will typically fail. This can be seen for example on Jetson TX2. Under certain circumstances the generic power domain code will cause the SOR to be reset. However, if the power domain is never powered off (this can happen if the HDA controller is enabled, which is part of the same power domain as the SOR), then the SOR will end up not getting reset and fail to properly set a mode. To work around this, try to get the reset control and assert/deassert it, irrespective of whether or not a generic power domain is attached to the SOR. On platforms where the kernel implements generic power domains (up to Tegra210) this will fail, because the power domain will already have acquired an exclusive reference to the reset control. But on recent platforms there the BPMP provides an ABI to control power domains, it's possible to acquire the reset control from SOR and use it to put the SOR into a known good state at probe time. The proper solution for this is to make the SOR driver capable of dealing with hardware that's already up and running (by first grace- fully shutting it down, or perhaps by seamlessly transitioning to the kernel driver and taking over the running display configuration). That is fairly involved, though, so we'll go with this quickfix for now. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/sor.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index 07a077bd73e4..ef8692b7075a 100644 --- a/drivers/gpu/drm/tegra/sor.c +++ b/drivers/gpu/drm/tegra/sor.c @@ -3340,14 +3340,23 @@ static int tegra_sor_probe(struct platform_device *pdev) goto remove; } - if (!pdev->dev.pm_domain) { - sor->rst = devm_reset_control_get(&pdev->dev, "sor"); - if (IS_ERR(sor->rst)) { - err = PTR_ERR(sor->rst); + sor->rst = devm_reset_control_get(&pdev->dev, "sor"); + if (IS_ERR(sor->rst)) { + err = PTR_ERR(sor->rst); + + if (err != -EBUSY || WARN_ON(!pdev->dev.pm_domain)) { dev_err(&pdev->dev, "failed to get reset control: %d\n", err); goto remove; } + + /* + * At this point, the reset control is most likely being used + * by the generic power domain implementation. With any luck + * the power domain will have taken care of resetting the SOR + * and we don't have to do anything. + */ + sor->rst = NULL; } sor->clk = devm_clk_get(&pdev->dev, NULL);