Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3191092pxb; Wed, 13 Oct 2021 00:26:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzF31DgQiICWM0maRjg5G+tJmk2Jl9tGfiG9SGa41PnaiUJ2xYWWaLZkJfkBA9Px0DoodGE X-Received: by 2002:a17:90a:290b:: with SMTP id g11mr11368164pjd.35.1634110006349; Wed, 13 Oct 2021 00:26:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634110006; cv=none; d=google.com; s=arc-20160816; b=eSTm6ITkGX6E4AIvn+WpAcH6NoNaY+Uop4v9qCTQCMaTKGJ/5Dp35yCh9YxX+FsmYp tpBQomTfLqKeZAqUqGoQdJoY4h01/9YndeqBK4EdM2jmudOieDXKX3jeaUbzseWA29SG d7L/DA49b7UdcKhq3tu9NzWCfugwG2ByDmLUQ8I3Zm+H4kLWf5dj22fKJfkfwfYyeqB/ YgfyzwpdXhF5AkidSazFFZd26r1qRMOAEjRr859gl0Y1czBOzV/FVP3OKBWvrJ40xGBM BzW30c+s2M54LUo/0bNaM9d7jIpP0gUhLgXig59YhLBYBQt04U1wMnngSaG4K5+kyYH0 P3Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=VZlgmIaK5VshXzrvcxHWzFvsBDeHPEcl207BCrJqEXk=; b=RFo1SVc90rSwM5BH6lDG5IHYAfAPGzMidOVPZOthP8zVMKAr+gukOkF8U90AYAHpqX 5Ivc8d0UZ78ll3QwYKKlx9MkYqaRol/5ZzEG0TxQIccuDGiR20hY6So/mddeqmru52nA WwLQzmK4gHRKHbTH9g8jObIWSyw49MGJqePWq0lcEqCdWlkhrBGLGyJO3Gx5+ETJlovL 7fLX4P08nZK7l86HWwvB3CpoW3xkwxJbYN18HUSzjGn/bNvScZvn5NX9ati3/S1XX8su 5kA7/okpW30tqUoCvV+Y0pPJT/xaaNaaGGYD+qzo/xqiZuWzccv9rSfTc1GnjlPjDyye Bhsw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g11si16141948plp.180.2021.10.13.00.26.32; Wed, 13 Oct 2021 00:26:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238347AbhJMH0W (ORCPT + 99 others); Wed, 13 Oct 2021 03:26:22 -0400 Received: from honk.sigxcpu.org ([24.134.29.49]:52308 "EHLO honk.sigxcpu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233938AbhJMH0U (ORCPT ); Wed, 13 Oct 2021 03:26:20 -0400 Received: from localhost (localhost [127.0.0.1]) by honk.sigxcpu.org (Postfix) with ESMTP id 03792FB03; Wed, 13 Oct 2021 09:24:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at honk.sigxcpu.org Received: from honk.sigxcpu.org ([127.0.0.1]) by localhost (honk.sigxcpu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em9WVIhHY5eG; Wed, 13 Oct 2021 09:24:12 +0200 (CEST) Date: Wed, 13 Oct 2021 09:24:11 +0200 From: Guido =?iso-8859-1?Q?G=FCnther?= To: Andrzej Hajda Cc: Laurent Pinchart , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Jyri Sarha , Tomi Valkeinen , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails Message-ID: References: <00493cc61d1443dab1c131c46c5890f95f6f9b25.1634068657.git.agx@sigxcpu.org> <78425826-1c28-4cb5-ba1f-23c6492a3810@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78425826-1c28-4cb5-ba1f-23c6492a3810@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Oct 13, 2021 at 08:48:32AM +0200, Andrzej Hajda wrote: > On 12.10.2021 22:47, Guido G?nther wrote: > > Hi Laurent, > > On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote: > > > Hi Guido, > > > > > > Thank you for the patch. > > > > > > On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido G?nther wrote: > > > > Otherwise logs are filled with > > > > > > > > [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@30800000/mipi-dsi@30a0 0000 to encoder None-34: -517 > > > > > > > > when the bridge isn't ready yet. > > > > > > > > Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge attach fails") > > > > Signed-off-by: Guido G?nther > > > > --- > > > > drivers/gpu/drm/drm_bridge.c | 11 ++++++----- > > > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > > > > index a8ed66751c2d..f0508e85ae98 100644 > > > > --- a/drivers/gpu/drm/drm_bridge.c > > > > +++ b/drivers/gpu/drm/drm_bridge.c > > > > @@ -227,14 +227,15 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge, > > > > bridge->encoder = NULL; > > > > list_del(&bridge->chain_node); > > > > + if (ret != -EPROBE_DEFER) { > > > > #ifdef CONFIG_OF > > > > - DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n", > > > > - bridge->of_node, encoder->name, ret); > > > > + DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n", > > > > + bridge->of_node, encoder->name, ret); > > > > #else > > > > - DRM_ERROR("failed to attach bridge to encoder %s: %d\n", > > > > - encoder->name, ret); > > > > + DRM_ERROR("failed to attach bridge to encoder %s: %d\n", > > > > + encoder->name, ret); > > > > #endif > > > > - > > > > + } > > > > > > This looks fine as such, but I'm concerned about the direction it's > > > taking. Ideally, probe deferral should happen at probe time, way before > > > the bridge is attached. Doing otherwise is a step in the wrong direction > > > in my opinion, and something we'll end up regretting when we'll feel the > > > pain it inflicts. > > > > The particular case I'm seeing this is the nwl driver probe deferrals if > > the panel bridge isn't ready (which needs a bunch of components > > (dsi, panel, backlight wrapped led, ...) and it probes fine later on so I > > wonder where you see the actual error cause? That downstream of the > > bridge isn't ready or that the display controller is already attaching > > the bridge? > > So it is something wrong there, nwl should not publish bridge interface > until it gather its resources (the panel in this case). That helps, I'll look at that. Thanks! -- Guido > > Regards > Andrzej > > > > > > Cheers, > > -- Guido > > > > > > > > > return ret; > > > > } > > > > EXPORT_SYMBOL(drm_bridge_attach); > > > > > > -- > > > Regards, > > > > > > Laurent Pinchart > > > >