Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp5604042rwb; Tue, 9 Aug 2022 00:21:12 -0700 (PDT) X-Google-Smtp-Source: AA6agR7RC0BKZ4ervR/Xh+mLX5O20zCx/32w9z2ZiCEqgJAQnpRAOfXyMJUk3YFWkvfgqaitML4w X-Received: by 2002:a63:2a90:0:b0:41d:95d7:9851 with SMTP id q138-20020a632a90000000b0041d95d79851mr5370004pgq.564.1660029672583; Tue, 09 Aug 2022 00:21:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660029672; cv=none; d=google.com; s=arc-20160816; b=F5OGAnV3ule2opJqZz0GR0rpIexoHJiCicts2C9XDmCHL02fek9rrnKe2eUDIKw6J2 Kld0t8tCi6njI8FkspeWyh39c2Yvq1R8sYs4LnGjvMqHRkK/W3QGL1ways/tyEOmgwr8 2BuxncZoIMc85Ul24mUVcatxIWTQlZuBaVcELLsXB9ocFW9rMlYugK8wexWb0j/mNqss F9+gSlsrNgeM/39ovKryoNSj4+c87QigI/Pcfxa9EVy82QaTAZ+d78cDUxVRE+MWgjDx 8zctWA8StwVWv2+0JziqJfhxi83xGNWnveYaHVPnfs6iqv4MJx2Csvi58j7opQA+DoQx WdkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature:dkim-signature; bh=M//xmn5LutYADQgn/epE+LDRLxNBhunceyOYbX10LMo=; b=ZcBFuJRER52z950jxazEE6f/19C4a9rDNXn/0fUYCHrnkBhMSFJWoL/YDzqd+JzUaK qkqXIkA2/CLzVN/kmSPBn8YJy8RQtfO1re3xRxxOoYYGp9SFDv2S9WWKZpGaZ4lnJeY/ CG9UTgiEJp62WAQzAGB8rRVLpge2Pe8rpPBXfyXV10tcZ/r/3fickAcdEb4CWPyNIWZU kHpcXXnGajB4Ba29wv6vy1b6X4cc/VqYtVec08D8ePMVLc4wKZBX2hINQpOCFd/J9UA0 zuLaqq0DNfS3BfVde66PtF6XgfwKT/79Gw2kyXWOnHotAP8TIi2EDVG3Ix5w5AlF91r/ MfyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Ol5Iyd0m; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=eKnwwTBJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s5-20020a656445000000b0041a4cfc72fdsi624208pgv.196.2022.08.09.00.20.55; Tue, 09 Aug 2022 00:21:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Ol5Iyd0m; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=eKnwwTBJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236184AbiHIHPo (ORCPT + 99 others); Tue, 9 Aug 2022 03:15:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238884AbiHIHPi (ORCPT ); Tue, 9 Aug 2022 03:15:38 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13B52FFA for ; Tue, 9 Aug 2022 00:15:37 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B928A336BF; Tue, 9 Aug 2022 07:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1660029335; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M//xmn5LutYADQgn/epE+LDRLxNBhunceyOYbX10LMo=; b=Ol5Iyd0mbOYphIFJlKMx4OTlKXgXt5p0YHgtPXABkzEtsSVccJBR0+ZGITnYRRsxA2KCZj sUJXQOYVMoBX3kkla+cw2hsyh0miuFS/V9zLos4oErj8+nqv6JatirXL15GUooB7aG8wl0 AXHvGmd57TYuRgHZs6v79WK0wq5ybXw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1660029335; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M//xmn5LutYADQgn/epE+LDRLxNBhunceyOYbX10LMo=; b=eKnwwTBJHEBTC7q4QcXmf2lw8j/MFI6m5eW/0m2HJPzU15BQAXvAfFLHg0xU5f7TDRR5wH JgHueNb5cIGNL2BA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8932913A9D; Tue, 9 Aug 2022 07:15:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Si9zHZcJ8mLpcQAAMHmgww (envelope-from ); Tue, 09 Aug 2022 07:15:35 +0000 Date: Tue, 09 Aug 2022 09:15:35 +0200 Message-ID: <87h72lx4yw.wl-tiwai@suse.de> From: Takashi Iwai To: Thomas Zimmermann Cc: Takashi Iwai , dri-devel@lists.freedesktop.org, Dave Airlie , Sean Paul , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect In-Reply-To: References: <20220804075826.27036-1-tiwai@suse.de> <20220804075826.27036-4-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 09 Aug 2022 09:13:16 +0200, Thomas Zimmermann wrote: > > Hi > > Am 04.08.22 um 09:58 schrieb Takashi Iwai: > > At both suspend and disconnect, we should rather cancel the pending > > URBs immediately. For the suspend case, the display will be turned > > off, so it makes no sense to process the rendering. And for the > > disconnect case, the device may be no longer accessible, hence we > > shouldn't do any submission. > > > > Tested-by: Thomas Zimmermann > > Signed-off-by: Takashi Iwai > > --- > > drivers/gpu/drm/udl/udl_drv.h | 2 ++ > > drivers/gpu/drm/udl/udl_main.c | 25 ++++++++++++++++++++++--- > > drivers/gpu/drm/udl/udl_modeset.c | 2 ++ > > 3 files changed, 26 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h > > index f01e50c5b7b7..28aaf75d71cf 100644 > > --- a/drivers/gpu/drm/udl/udl_drv.h > > +++ b/drivers/gpu/drm/udl/udl_drv.h > > @@ -39,6 +39,7 @@ struct urb_node { > > struct urb_list { > > struct list_head list; > > + struct list_head in_flight; > > spinlock_t lock; > > wait_queue_head_t sleep; > > int available; > > @@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device *dev) > > int udl_submit_urb(struct drm_device *dev, struct urb *urb, > > size_t len); > > int udl_sync_pending_urbs(struct drm_device *dev); > > +void udl_kill_pending_urbs(struct drm_device *dev); > > void udl_urb_completion(struct urb *urb); > > int udl_init(struct udl_device *udl); > > diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c > > index 93615648414b..47204b7eb10e 100644 > > --- a/drivers/gpu/drm/udl/udl_main.c > > +++ b/drivers/gpu/drm/udl/udl_main.c > > @@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb) > > urb->transfer_buffer_length = udl->urbs.size; /* reset to actual */ > > spin_lock_irqsave(&udl->urbs.lock, flags); > > - list_add_tail(&unode->entry, &udl->urbs.list); > > + list_move(&unode->entry, &udl->urbs.list); > > udl->urbs.available++; > > spin_unlock_irqrestore(&udl->urbs.lock, flags); > > @@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct > > drm_device *dev, int count, size_t size) > > retry: > > udl->urbs.size = size; > > INIT_LIST_HEAD(&udl->urbs.list); > > + INIT_LIST_HEAD(&udl->urbs.in_flight); > > init_waitqueue_head(&udl->urbs.sleep); > > udl->urbs.count = 0; > > @@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device *dev, long timeout) > > } > > unode = list_first_entry(&udl->urbs.list, struct urb_node, > > entry); > > - list_del_init(&unode->entry); > > + list_move(&unode->entry, &udl->urbs.in_flight); > > udl->urbs.available--; > > unlock: > > @@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev) > > spin_lock_irq(&udl->urbs.lock); > > /* 2 seconds as a sane timeout */ > > if (!wait_event_lock_irq_timeout(udl->urbs.sleep, > > - udl->urbs.available == udl->urbs.count, > > + list_empty(&udl->urbs.in_flight), > > udl->urbs.lock, > > msecs_to_jiffies(2000))) > > ret = -ETIMEDOUT; > > @@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev) > > return ret; > > } > > +/* kill pending URBs */ > > +void udl_kill_pending_urbs(struct drm_device *dev) > > +{ > > + struct udl_device *udl = to_udl(dev); > > + struct urb_node *unode; > > + > > + spin_lock_irq(&udl->urbs.lock); > > + while (!list_empty(&udl->urbs.in_flight)) { > > + unode = list_first_entry(&udl->urbs.in_flight, > > + struct urb_node, entry); > > + spin_unlock_irq(&udl->urbs.lock); > > + usb_kill_urb(unode->urb); > > + spin_lock_irq(&udl->urbs.lock); > > + } > > + spin_unlock_irq(&udl->urbs.lock); > > +} > > + > > int udl_init(struct udl_device *udl) > > { > > struct drm_device *dev = &udl->drm; > > @@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev) > > { > > struct udl_device *udl = to_udl(dev); > > + udl_kill_pending_urbs(dev); > > udl_free_urb_list(dev); > > put_device(udl->dmadev); > > udl->dmadev = NULL; > > diff --git a/drivers/gpu/drm/udl/udl_modeset.c b/drivers/gpu/drm/udl/udl_modeset.c > > index 50025606b6ad..169110d8fc2e 100644 > > --- a/drivers/gpu/drm/udl/udl_modeset.c > > +++ b/drivers/gpu/drm/udl/udl_modeset.c > > @@ -397,6 +397,8 @@ udl_simple_display_pipe_disable(struct drm_simple_display_pipe *pipe) > > struct urb *urb; > > char *buf; > > + udl_kill_pending_urbs(dev); > > + > > I already reviewed the patchset, but I have another comment. I think > we should only kill urbs from within the suspend handler. Same for the > call to the URB-sync function in patch 2. > > This disable function is part of the regular modeset path. It's > probably not appropriate to outright remove pending URBs here. This > can lead to failed modesets, which would have succeeded otherwise. Well, the device shall be turned off right after that point, so the all pending rendering makes little sense, no? Takashi