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=-7.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED autolearn=unavailable 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 985A8C04AB5 for ; Thu, 6 Jun 2019 23:00:34 +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 67D4020645 for ; Thu, 6 Jun 2019 23:00:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="uwFDzmkC"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="SQ6VQ7xX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67D4020645 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=P1SQ/2brt/NOTL33Bqxt/XOduKWLgwBRup6MlDLpguw=; b=uwFDzmkCusJE0e lI8oGtgpEa51nW94DotXPgwISzL6LX0Y9N2EJO9lXu+D0XksYlG/qohwT+a7EKqNn+JM6lh0nBn2W uD0w4LT5hg6FJotDqjtOqJiaKM0qVCBjJU4uO+tKszPTOV7JQvPR5xbrbRR1WS8E3em+455UA3wG7 ErPbckPQt9dIU7y0HCdak88coC7UXJCUaVTlal025FDoD66iNegaZUXewiBuPgIfMCReOf7rxzJYl FKCxD4Vx/tM6N44pyDEO+5+lFjTx6G6a3Yj7w0RZnq07c+GfIwvZY21lf7rzlb8a2HuYnj77oQU9W 9MDKXxsZ9fwdDszOmh8Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hZ1Mx-0006ZG-5d; Thu, 06 Jun 2019 23:00:27 +0000 Received: from mail-io1-xd42.google.com ([2607:f8b0:4864:20::d42]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hZ1LC-0004nj-N6 for linux-arm-kernel@lists.infradead.org; Thu, 06 Jun 2019 22:58:40 +0000 Received: by mail-io1-xd42.google.com with SMTP id i10so1501437iol.13 for ; Thu, 06 Jun 2019 15:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nZyg+4+QNKbKPq0WwkGA+iMce1tFBIQolx/rr5mhJFU=; b=SQ6VQ7xXspnotBNh7TJpasqfkB9SD+WXfZFDbmWBNN4+1xeq/tt2vj7xg9kOfp8Jn+ 2tqwB/HzqlKfvSfg7a25R8OwV1bJh1loaTbudTWz8QmBkGkLMkmobmKogKb/+FnTOa1g /sie1KrlCOWdVZiWWJLXrlxPkf/E1T1lI1Wqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nZyg+4+QNKbKPq0WwkGA+iMce1tFBIQolx/rr5mhJFU=; b=dcc5VNgRI+KGAyY99HBCgZKfBVorDCyvmNGQBx0F7O89HFqRVdQQtkYE6DgNm6DIoi Q+871THUXjglOZBlOY/P4njs+1E0OxBatd1EhWlWRIop+9SDvC39TUr3rtMW1IE2Qtte WrEe/U6o5bKP1BwbrgAVKx8BdgcQe0K1cMafYt60xKbceqWQPmbkPPSsUuVxa/j/e6eM VKTiJ9karGE6i9gH2urVu2P/v5FzqPZth6a1Qp+cw6G0rW4BvuyRyNqJJ8yRhPa6v+gB GLvs0FicI3AHu4z/j5d9taL28QdtRy/2PgLwwVO6P9XlLtgnTbwnvxwG99EThViYX+to vY9g== X-Gm-Message-State: APjAAAXg40oaEMgXt0s9prKMmBmoy/J9RRoHtp64BT4KDCN5qIRZOVnp KOHPKAWTO5L1y6Cf6SQzERin48JjBTY= X-Google-Smtp-Source: APXvYqwhEucZoch9FHrKImLkqLH6UFdDtm+1wd8OemfQx8WxzK/cg0mcOZzEh2Mb+0XLFKv5ZVxC4g== X-Received: by 2002:a6b:4e08:: with SMTP id c8mr12410884iob.217.1559861914452; Thu, 06 Jun 2019 15:58:34 -0700 (PDT) Received: from mail-it1-f173.google.com (mail-it1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id r62sm79105ita.37.2019.06.06.15.58.32 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jun 2019 15:58:33 -0700 (PDT) Received: by mail-it1-f173.google.com with SMTP id l21so2679713ita.2 for ; Thu, 06 Jun 2019 15:58:32 -0700 (PDT) X-Received: by 2002:a02:9143:: with SMTP id b3mr9564655jag.12.1559861912576; Thu, 06 Jun 2019 15:58:32 -0700 (PDT) MIME-Version: 1.0 References: <20190604204207.168085-1-dianders@chromium.org> <20190604204207.168085-2-dianders@chromium.org> <20190606164221.GI17077@art_vandelay> In-Reply-To: <20190606164221.GI17077@art_vandelay> From: Doug Anderson Date: Thu, 6 Jun 2019 15:58:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] drm/rockchip: dw_hdmi: Handle suspend/resume To: Sean Paul X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190606_155838_804094_3AA13E5E X-CRM114-Status: GOOD ( 25.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heiko Stuebner , "open list:ARM/Rockchip SoC..." , David Airlie , Neil Armstrong , Sandy Huang , dri-devel , LKML , Andrzej Hajda , Matthias Kaehlcke , Sean Paul , Laurent Pinchart , Daniel Vetter , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Thu, Jun 6, 2019 at 9:42 AM Sean Paul wrote: > > On Tue, Jun 04, 2019 at 01:42:07PM -0700, Douglas Anderson wrote: > > On Rockchip rk3288-based Chromebooks when you do a suspend/resume > > cycle: > > > > 1. You lose the ability to detect an HDMI device being plugged in. > > > > 2. If you're using the i2c bus built in to dw_hdmi then it stops > > working. > > > > Let's call the core dw-hdmi's suspend/resume functions to restore > > things. > > > > NOTE: in downstream Chrome OS (based on kernel 3.14) we used the > > "late/early" versions of suspend/resume because we found that the VOP > > was sometimes resuming before dw_hdmi and then calling into us before > > we were fully resumed. For now I have gone back to the normal > > suspend/resume because I can't reproduce the problems. > > > > Signed-off-by: Douglas Anderson > > --- > > > > Changes in v3: > > - dw_hdmi_resume() is now a void function (Laurent) > > > > Changes in v2: > > - Add forgotten static (Laurent) > > - No empty stub for suspend (Laurent) > > > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > > index 4cdc9f86c2e5..7bb0f922b303 100644 > > --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > > +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > > @@ -542,11 +542,25 @@ static int dw_hdmi_rockchip_remove(struct platform_device *pdev) > > return 0; > > } > > > > +static int __maybe_unused dw_hdmi_rockchip_resume(struct device *dev) > > +{ > > + struct rockchip_hdmi *hdmi = dev_get_drvdata(dev); > > + > > + dw_hdmi_resume(hdmi->hdmi); > > The rockchip driver is already using the atomic suspend/resume helpers (via the > modeset helpers). Would you be able to accomplish the same thing by just moving > this call into the encoder enable callback? > > .enable is called on resume via the atomic commit framework, so everything is > ordered properly. Of course, this would reset the dw_hdmi bridge on each enable, > but I don't think that would be a problem? I tried and it sorta kinda half worked, but... 1. One of the problems solved by this patch is making "hot plug detect" work after suspend / resume. AKA: if you have nothing plugged in to the HDMI port and then suspend/resume you need to be able to detect when something is plugged in. When nothing is plugged in then the ".enable" isn't called at resume time. 2. I'm not so convinced about the whole ordering being correct. Unfortunately on my system (Chrome OS running the chromeos-4.19 kernel) we end up getting an i2c transfer before the ".enable" is called. I put a dump_stack() in the i2c transfer: [ 42.212516] CPU: 0 PID: 1479 Comm: DrmThread Tainted: G C 4.19.47 #60 [ 42.221182] Hardware name: Rockchip (Device Tree) [ 42.226449] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 42.235114] [] (show_stack) from [] (dump_stack+0x84/0xa4) [ 42.243195] [] (dump_stack) from [] (dw_hdmi_i2c_wait+0x6c/0xa8) [ 42.251858] [] (dw_hdmi_i2c_wait) from [] (dw_hdmi_i2c_xfer+0x1a8/0x30c) [ 42.261298] [] (dw_hdmi_i2c_xfer) from [] (__i2c_transfer+0x3a8/0x5d8) [ 42.270543] [] (__i2c_transfer) from [] (i2c_transfer+0x94/0xc4) [ 42.279204] [] (i2c_transfer) from [] (drm_do_probe_ddc_edid+0xbc/0x11c) [ 42.288642] [] (drm_do_probe_ddc_edid) from [] (drm_probe_ddc+0x34/0x5c) [ 42.298081] [] (drm_probe_ddc) from [] (drm_get_edid+0x60/0x2e0) [ 42.306743] [] (drm_get_edid) from [] (dw_hdmi_connector_get_modes+0x30/0x78) [ 42.316669] [] (dw_hdmi_connector_get_modes) from [] (drm_helper_probe_single_connector_modes+0x218/0x5c0) [ 42.329413] [] (drm_helper_probe_single_connector_modes) from [] (drm_mode_getconnector+0x144/0x418) [ 42.341573] [] (drm_mode_getconnector) from [] (drm_ioctl_kernel+0xa0/0xf0) [ 42.351303] [] (drm_ioctl_kernel) from [] (drm_ioctl+0x32c/0x3c0) [ 42.360063] [] (drm_ioctl) from [] (vfs_ioctl+0x28/0x44) [ 42.367946] [] (vfs_ioctl) from [] (do_vfs_ioctl+0x718/0x8b0) [ 42.376315] [] (do_vfs_ioctl) from [] (ksys_ioctl+0x5c/0x84) [ 42.384587] [] (ksys_ioctl) from [] (sys_ioctl+0x18/0x1c) [ 42.392570] [] (sys_ioctl) from [] (__sys_trace_return+0x0/0x10) ...I see several transfers fail and then finally a few seconds later finally see the .enable call: [ 44.021501] DOUG: dw_hdmi_rockchip_encoder_enable start [ 44.027792] DOUG: dw_hdmi_rockchip_encoder_enable end I can gather more info if it's useful. === ...any chance we can keep the patch as-is, or do you have ideas of how to solve the above problems? Thanks! -Doug _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel