Message ID | 20220609082246.13182-1-tiwai@suse.de (mailing list archive) |
---|---|
State | Changes Requested |
Delegated to: | Laurent Pinchart |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1nzDRR-00DK59-Bi; Thu, 09 Jun 2022 08:22:57 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231195AbiFIIWy (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Thu, 9 Jun 2022 04:22:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229949AbiFIIWy (ORCPT <rfc822;linux-media@vger.kernel.org>); Thu, 9 Jun 2022 04:22:54 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 789D859977; Thu, 9 Jun 2022 01:22:53 -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 37DE221DE0; Thu, 9 Jun 2022 08:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1654762972; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=3bSkabX8VgHADh3/J147QctYpANZTcxqp+PhwF48u7U=; b=jMHryVCYuHawC8UOHpKcsOosXeHxW+FWCNtyiRu7CrzD8dXe+rw8dgb/6rSgelBzFyBECw O1mwjUGNz188J1OPSbAyJwhyi8EbF0z6CPOi5zi2ZEgPAoEu9rtGxHCYEnySZRQCVEc3TQ T93o5lbPtgRBKBNV8Sw14H7cLysPZX4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1654762972; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=3bSkabX8VgHADh3/J147QctYpANZTcxqp+PhwF48u7U=; b=oXSJNwov56gM336GaG/zxSS+pY3oeJyBVKxahb+8lYCLEp9j6LS7wEY7WPhdYWLKiwrp44 BmphxTQFJRMN8ADw== 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 02FC813A8C; Thu, 9 Jun 2022 08:22:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id sVlZO9utoWKpSgAAMHmgww (envelope-from <tiwai@suse.de>); Thu, 09 Jun 2022 08:22:51 +0000 From: Takashi Iwai <tiwai@suse.de> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] media: uvcvideo: Fix spurious DMA max segment size warnings Date: Thu, 9 Jun 2022 10:22:46 +0200 Message-Id: <20220609082246.13182-1-tiwai@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -2.5 (--) X-LSpam-Report: No, score=-2.5 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1 autolearn=ham autolearn_force=no |
Series |
media: uvcvideo: Fix spurious DMA max segment size warnings
|
|
Commit Message
Takashi Iwai
June 9, 2022, 8:22 a.m. UTC
As default, the DMA max segment size is set to 64k, and uvcvideo may
overflow that size easily, resulting in a warning like:
DMA-API: xhci_hcd 0000:00:14.0: mapping sg segment longer than device claims to support [len=98304] [max=65536]
Explicitly set up the DMA max segment size for avoiding spurious kernel
warnings.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/media/usb/uvc/uvc_video.c | 2 ++
1 file changed, 2 insertions(+)
Comments
Hi Takashi, (CC'ing Greg and the linux-usb mailing list) Thank you for the patch. On Thu, Jun 09, 2022 at 10:22:46AM +0200, Takashi Iwai wrote: > As default, the DMA max segment size is set to 64k, and uvcvideo may > overflow that size easily, resulting in a warning like: > > DMA-API: xhci_hcd 0000:00:14.0: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > Explicitly set up the DMA max segment size for avoiding spurious kernel > warnings. > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/media/usb/uvc/uvc_video.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index 1b4cc934109e..25aa6e6a6906 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -2160,6 +2160,8 @@ int uvc_video_init(struct uvc_streaming *stream) > for_each_uvc_urb(uvc_urb, stream) > INIT_WORK(&uvc_urb->work, uvc_video_copy_data_work); > > + dma_set_max_seg_size(uvc_stream_to_dmadev(stream), UINT_MAX); > + uvc_stream_to_dmadev() returns the pointer to the HCD's struct device, which is shared between all drivers on the bus. Is it really fine for a USB device driver to change the maximum segment size of the HCD device directly ? > return 0; > } >
On Thu, Jun 09, 2022 at 12:18:30PM +0300, Laurent Pinchart wrote: > Hi Takashi, > > (CC'ing Greg and the linux-usb mailing list) > > Thank you for the patch. > > On Thu, Jun 09, 2022 at 10:22:46AM +0200, Takashi Iwai wrote: > > As default, the DMA max segment size is set to 64k, and uvcvideo may > > overflow that size easily, resulting in a warning like: > > > > DMA-API: xhci_hcd 0000:00:14.0: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > > > Explicitly set up the DMA max segment size for avoiding spurious kernel > > warnings. > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > > --- > > drivers/media/usb/uvc/uvc_video.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > > index 1b4cc934109e..25aa6e6a6906 100644 > > --- a/drivers/media/usb/uvc/uvc_video.c > > +++ b/drivers/media/usb/uvc/uvc_video.c > > @@ -2160,6 +2160,8 @@ int uvc_video_init(struct uvc_streaming *stream) > > for_each_uvc_urb(uvc_urb, stream) > > INIT_WORK(&uvc_urb->work, uvc_video_copy_data_work); > > > > + dma_set_max_seg_size(uvc_stream_to_dmadev(stream), UINT_MAX); > > + > > uvc_stream_to_dmadev() returns the pointer to the HCD's struct device, > which is shared between all drivers on the bus. Is it really fine for a > USB device driver to change the maximum segment size of the HCD device > directly ? Ick, no! That feels wrong, it should only change things for that one specific device, not all devices on that bus. thanks, greg k-h
On Fri, 10 Jun 2022 10:57:40 +0200, Greg Kroah-Hartman wrote: > > On Thu, Jun 09, 2022 at 12:18:30PM +0300, Laurent Pinchart wrote: > > Hi Takashi, > > > > (CC'ing Greg and the linux-usb mailing list) > > > > Thank you for the patch. > > > > On Thu, Jun 09, 2022 at 10:22:46AM +0200, Takashi Iwai wrote: > > > As default, the DMA max segment size is set to 64k, and uvcvideo may > > > overflow that size easily, resulting in a warning like: > > > > > > DMA-API: xhci_hcd 0000:00:14.0: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > > > > > Explicitly set up the DMA max segment size for avoiding spurious kernel > > > warnings. > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > > > --- > > > drivers/media/usb/uvc/uvc_video.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > > > index 1b4cc934109e..25aa6e6a6906 100644 > > > --- a/drivers/media/usb/uvc/uvc_video.c > > > +++ b/drivers/media/usb/uvc/uvc_video.c > > > @@ -2160,6 +2160,8 @@ int uvc_video_init(struct uvc_streaming *stream) > > > for_each_uvc_urb(uvc_urb, stream) > > > INIT_WORK(&uvc_urb->work, uvc_video_copy_data_work); > > > > > > + dma_set_max_seg_size(uvc_stream_to_dmadev(stream), UINT_MAX); > > > + > > > > uvc_stream_to_dmadev() returns the pointer to the HCD's struct device, > > which is shared between all drivers on the bus. Is it really fine for a > > USB device driver to change the maximum segment size of the HCD device > > directly ? > > Ick, no! That feels wrong, it should only change things for that one > specific device, not all devices on that bus. Hrm, indeed, that points to the HCD. This made me wonder, though, whether the current usage of dma_*sgtable() with that device is OK or not. The warning came from that code path, after all... Takashi
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index 1b4cc934109e..25aa6e6a6906 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -2160,6 +2160,8 @@ int uvc_video_init(struct uvc_streaming *stream) for_each_uvc_urb(uvc_urb, stream) INIT_WORK(&uvc_urb->work, uvc_video_copy_data_work); + dma_set_max_seg_size(uvc_stream_to_dmadev(stream), UINT_MAX); + return 0; }