Received: by 2002:a4a:311b:0:0:0:0:0 with SMTP id k27-v6csp3977157ooa; Mon, 13 Aug 2018 22:30:19 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyOqxVywkQF+DOc6GKdQUwJcbqDyszKop/oyiVGkbU0Sht30aV02xH/1NY1m9nzPrtUI7+2 X-Received: by 2002:a17:902:82c7:: with SMTP id u7-v6mr18986203plz.83.1534224619570; Mon, 13 Aug 2018 22:30:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534224619; cv=none; d=google.com; s=arc-20160816; b=tWY4p+MuDCF7Mwhc2Py184Hbv7xiIRCe+ZorffirOfAfsd8CkLJv8fOBrfdLphZMAs EeuUBpo0YsNkyzZFIVzTW+d53pc4SZAktrXMX0eWkoshjRhU/U6zNPzvCHVESUDlsvfK MygI8p+cys+vET7Bu8VAPN+fGIP36wn0y7Pd6QLgFh2ypQkbRZc6s9yH9oiBQPCFkxSk /T5SWPG2NOd2XZOKWEtOX7EigXvZsdbS3a+q4yH3gkdpEzb2RFTaRLkioL19A6/C9ied 0YmRDReC54OVfA0TTORU/GxQxJtTNpmsSHNn7E44eKvLAL3A/qwvhZemBFjauGXn33Vh ruCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=r8Miab9F8dkzBZSvYCF80nkUsRZeosTv26b/ajkIbCg=; b=cjT5aO2qI5aiuQVRVSgaXWjBioeXtars9l8F0sVH03ge2z4cNLyhHHk708f0wkQiTE kxAROuNYsHnoQ9/cGIfCfUVETwkqFCRVH/2tggUp7gMIsSgKu2WCzPylhkgbC2nqzwpa UXqdY0Uzws5+RcDCkcuUTSpmMe9ZaeZ4H1Z95JdE0dvSYZJaIh2LM7FdrMT8q89nt9Z4 0H9sSHhz7+HSVLom3TV4YlsvacXaglYpNfqdaucwA0ap0lamdsDojxUm+RMska4jCzf3 61v3pMZ8VXhVXZOqtoXEsOrDaCHJ83Awbc5uPqGWzLrLpTMTxnZBqOsG7UJAnZu0VvG+ 1xBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1-v6si18163570plm.375.2018.08.13.22.30.04; Mon, 13 Aug 2018 22:30:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729990AbeHNIOG (ORCPT + 99 others); Tue, 14 Aug 2018 04:14:06 -0400 Received: from hermes.aosc.io ([199.195.250.187]:47400 "EHLO hermes.aosc.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728521AbeHNIOG (ORCPT ); Tue, 14 Aug 2018 04:14:06 -0400 Received: from localhost (localhost [127.0.0.1]) (Authenticated sender: icenowy@aosc.io) by hermes.aosc.io (Postfix) with ESMTPSA id 2BB0A5DAF9; Tue, 14 Aug 2018 05:28:28 +0000 (UTC) Message-ID: Subject: Re: [PATCH] drm/bridge/synopsys: dw-hdmi: re-run dw_hdmi_setup when setting mode From: Icenowy Zheng To: Andrzej Hajda , Archit Taneja , Laurent Pinchart , Neil Armstrong , Maxime Ripard , Jernej Skrabec , Daniel Vetter Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Date: Tue, 14 Aug 2018 13:28:18 +0800 In-Reply-To: <20180813114945eucas1p1e9d900848b4256341fe93278f4fa6f67~Kb0nDRoKq0841508415eucas1p1p@eucas1p1.samsung.com> References: <20180725035627.58223-1-icenowy@aosc.io> <20180813114945eucas1p1e9d900848b4256341fe93278f4fa6f67~Kb0nDRoKq0841508415eucas1p1p@eucas1p1.samsung.com> Organization: Anthon Open-Source Community Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2018-08-13一的 13:49 +0200,Andrzej Hajda写道: > On 25.07.2018 05:56, Icenowy Zheng wrote: > > Currently dw_hdmi_setup is only run when the dw-hdmi bridge is > > enabled, > > with the mode set last time. > > > > When the bridge is enabled before any mode is set (this may happen > > when > > booting), the mode won't be set at all, some setup steps will be > > skipped or fail, and the HDMI output may not work. > > I guess, it should not happen. Could you show the stack-trace. Mysteriously dw_hdmi_setup isn't called at all currently when booting in thie situation. I added dump_stack() at the head of the function, and it's only triggered when I re-plug the monitor. In this case I got: ``` [ 46.891513] CPU: 0 PID: 73 Comm: irq/34-1ee0000. Not tainted 4.18.0+ #152 [ 46.898290] Hardware name: Allwinner sun8i Family [ 46.903008] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 46.910746] [] (show_stack) from [] (dump_stack+0x88/0x9c) [ 46.917966] [] (dump_stack) from [] (dw_hdmi_update_power+0xb8/0x12cc) [ 46.926225] [] (dw_hdmi_update_power) from [] (dw_hdmi_bridge_enable+0x2c/0x70) [ 46.935262] [] (dw_hdmi_bridge_enable) from [] (drm_bridge_enable+0x24/0x34) [ 46.944040] [] (drm_bridge_enable) from [] (drm_atomic_helper_commit_modeset_enables+0x9c/0x180) [ 46.954552] [] (drm_atomic_helper_commit_modeset_enables) from [] (drm_atomic_helper_commit_tail_rpm+0x24/0x64) [ 46.966361] [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x40/0x6c) [ 46.975657] [] (commit_tail) from [] (drm_atomic_helper_commit+0xbc/0x128) [ 46.984259] [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x1cc/0x220) [ 46.994164] [] (restore_fbdev_mode_atomic) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [ 47.005369] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x30/0x54) [ 47.016226] [] (drm_fb_helper_set_par) from [] (drm_fb_helper_hotplug_event.part.11+0xa0/0xa8) [ 47.026563] [] (drm_fb_helper_hotplug_event.part.11) from [] (drm_helper_hpd_irq_event+0x110/0x118) [ 47.037334] [] (drm_helper_hpd_irq_event) from [] (dw_hdmi_irq+0x10c/0x194) [ 47.046025] [] (dw_hdmi_irq) from [] (irq_thread_fn+0x1c/0x54) [ 47.053589] [] (irq_thread_fn) from [] (irq_thread+0x158/0x21c) [ 47.061241] [] (irq_thread) from [] (kthread+0x148/0x150) [ 47.068373] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 47.075584] Exception stack(0xee8bbfb0 to 0xee8bbff8) [ 47.080630] bfa0: 00000000 00000000 00000000 00000000 [ 47.088797] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 47.096964] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ``` > > > > > Re-run dw_hdmi_setup when setting mode, in order to prevent such > > situation. > > mode_set is run with hardware disabled, thus usually it should not > touch > hardware. However I think there's many instances now where some hardware setup is performed in mode_set. > > > > > > Signed-off-by: Icenowy Zheng > > --- > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > index 5971976284bf..e2f832182afe 100644 > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > @@ -2007,6 +2007,7 @@ static void dw_hdmi_bridge_mode_set(struct > > drm_bridge *bridge, > > > > /* Store the display mode for plugin/DKMS poweron events */ > > memcpy(&hdmi->previous_mode, mode, sizeof(hdmi- > > >previous_mode)); > > + dw_hdmi_setup(hdmi, mode); > > This hdmi->previous_mode also looks strange, it is current mode and > moreover it is always available from crtc state, there is no point in > copying it to private field. Sorry I don't know about this. Maybe you should ask the original author of dw-hdmi? > > Regards > Andrzej > > > > mutex_unlock(&hdmi->mutex); > > } > >