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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 86DE3C433E0 for ; Thu, 25 Feb 2021 19:02:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33A7864F29 for ; Thu, 25 Feb 2021 19:02:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230371AbhBYTCr (ORCPT ); Thu, 25 Feb 2021 14:02:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233496AbhBYTCo (ORCPT ); Thu, 25 Feb 2021 14:02:44 -0500 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56331C061574 for ; Thu, 25 Feb 2021 11:02:04 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id r3so6295956wro.9 for ; Thu, 25 Feb 2021 11:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=R04SCbc3J2s6YGY6KTLqQ7dJLw7RfMlWnwJ0ZBxrr/A=; b=FcYamvVNhIttALmwinTG0BfvveZd/yBRYBN//4NW5hd8rU/hV1xxIHccU5RESjCeRb hZ2aLjMT4dMXcgqG9KW48eW5lRJqPnkGrhaGBrnBssj0U3M6Ls+csqDQAOucI4RCctWI sLdvKXnD097OdJpmfj9kiVrOIcnFNcRLJAYzoM/pFfhRU5WbczoyQp2PqHL6AKftUK7+ p3EixcHJlmALpr1P5ZRMIjCpNZ4vf423GnpNd+iARqGOesx3ukvGe+985cGFhs2Airml vmw9QI90G12Q4DsVB1NSeVDeL/LgDXOB+75mojcl466eGOHJFlyZNDeyY1k+wmF4NQPM IKKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=R04SCbc3J2s6YGY6KTLqQ7dJLw7RfMlWnwJ0ZBxrr/A=; b=DC+1Jos6ijOpV0HZiQ3V6FI7giD+x7wlZZjvujKVaRzgRKI3R8+bvWfC3LLkvu0nxu fUZ7Tzpi2QHkibT3MOzRuRPkT3YslLyYkljAshSY1jRyXw1lRESBxN7rg4CJqAGHaqp8 5DMnjrg4/pJghvZ1h/GeT6fmv2X75YAhPxYu/yC+VMAVdEGVZwAvxm8ZP/XjWy4Om6Dh soFleuLbQG0MPfhnBGo9jmls0oZ3PU4KFE+NhHxVIMmnvhdX1Pvrvu2yAm+ul7rrj5n+ veKUd8W0oMG0B7k+qjS+EPWXQ3IsvDpeJqbxI2C7QKD+hbxweZVYU7X4wvE5IwkD4EsZ WOcg== X-Gm-Message-State: AOAM533twOFiggQa50sZ571jWPoyx+uWljVOshFojRQm/HQi7hWqEDBm HpH770t9OmDLLZW2XUnkvhg= X-Google-Smtp-Source: ABdhPJxk25RGRPLVZhS8dIoWYL89+5XVazQbdxVKKeCGmetyLUCZO5Oi36KP0AaM2heny3nLG3zS2Q== X-Received: by 2002:a5d:4bc1:: with SMTP id l1mr5074737wrt.396.1614279723057; Thu, 25 Feb 2021 11:02:03 -0800 (PST) Received: from debian ([2.98.59.96]) by smtp.gmail.com with ESMTPSA id g17sm8289306wru.60.2021.02.25.11.02.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Feb 2021 11:02:02 -0800 (PST) Date: Thu, 25 Feb 2021 19:01:57 +0000 From: Sudip Mukherjee To: Greg KH , Ben Hutchings Cc: Thomas Zimmermann , Daniel Vetter , Mathias Nyman , Thomas Gleixner , Dave Airlie , Sebastian Andrzej Siewior , Oliver Neukum , Christoph Hellwig , Hans de Goede , Alan Stern , dri-devel , stable , Johan Hovold , Andy Shevchenko , Sean Paul , Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH v3] drm: Use USB controller's DMA mask when importing dmabufs Message-ID: References: <20210223105842.27011-1-tzimmermann@suse.de> <9b1e0c9b-2337-d76b-4870-72fbe8495fd2@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Feb 23, 2021 at 02:09:58PM +0100, Greg KH wrote: > On Tue, Feb 23, 2021 at 01:51:09PM +0100, Thomas Zimmermann wrote: > > Hi > > > > Am 23.02.21 um 13:24 schrieb Greg KH: > > > On Tue, Feb 23, 2021 at 01:14:30PM +0100, Daniel Vetter wrote: > > > > On Tue, Feb 23, 2021 at 1:02 PM Greg KH wrote: > > > > > > > > > > On Tue, Feb 23, 2021 at 12:46:20PM +0100, Daniel Vetter wrote: > > > > > > On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote: > > > > > > > On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote: > > > > > > > > USB devices cannot perform DMA and hence have no dma_mask set in their > > > > > > > > device structure. Importing dmabuf into a USB-based driver fails, which > > > > > > > > break joining and mirroring of display in X11. > > > > > > > > > > > > > > > > For USB devices, pick the associated USB controller as attachment device, > > > > > > > > so that it can perform DMA. If the DMa controller does not support DMA > > > > > > > > transfers, we're aout of luck and cannot import. > > > > > > > > > > > > > > > > Drivers should use DRM_GEM_SHMEM_DROVER_OPS_USB to initialize their > > > > > > > > instance of struct drm_driver. > > > > > > > > > > > > > > > > Tested by joining/mirroring displays of udl and radeon un der Gnome/X11. > > > > > > > > > > > > > > > > v3: > > > > > > > > * drop gem_create_object > > > > > > > > * use DMA mask of USB controller, if any (Daniel, Christian, Noralf) > > > > > > > > v2: > > > > > > > > * move fix to importer side (Christian, Daniel) > > > > > > > > * update SHMEM and CMA helpers for new PRIME callbacks > > > > > > > > > > > > > > > > Signed-off-by: Thomas Zimmermann > > > > > > > > Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices") > > > > > > > > Cc: Christoph Hellwig > > > > > > > > Cc: Greg Kroah-Hartman > > > > > > > > Cc: Johan Hovold > > > > > > > > Cc: Alan Stern > > > > > > > > Cc: Andy Shevchenko > > > > > > > > Cc: Sebastian Andrzej Siewior > > > > > > > > Cc: Mathias Nyman > > > > > > > > Cc: Oliver Neukum > > > > > > > > Cc: Thomas Gleixner > > > > > > > > Cc: # v5.10+ > > > > > > > > --- > > > > > > > > > > > > > > There shouldn't be anything "special" about a DRM driver that needs this > > > > > > > vs. any other driver that might want to know about DMA things related to > > > > > > > a specific USB device. Why isn't this an issue with the existing > > > > > > > storage or v4l USB devices? > > > > > > > > > > > > The trouble is that this is a regression fix for 5.9, because the dma-api > > > > > > got more opinionated about what it allows. The proper fix is a lot more > > > > > > invasive (we essentially need to rework the drm_prime.c to allow dma-buf > > > > > > importing for just cpu access), and that's a ton more invasive than just a > > > > > > small patch with can stuff into stable kernels. > > > > > > > > > > > > This here is ugly, but it should at least get rid of black screens again. > > > > > > > > > > > > I think solid FIXME comment explaining the situation would be good. > > > > > > > > > > Why can't I take a USB patch for a regression fix? Is drm somehow > > > > > stand-alone that you make changes here that should belong in other > > > > > subsystems? > > > > > > > > > > {hint, it shouldn't be} > > > > > > > > > > When you start poking in the internals of usb controller structures, > > > > > that logic belongs in the USB core for all drivers to use, not in a > > > > > random tiny subsystem where no USB developer will ever notice it? :) > > > > > > > > Because the usb fix isn't the right fix here, it's just the duct-tape. > > > > We don't want to dig around in these internals, it's just a convenient > > > > way to shut up the dma-api until drm has sorted out its confusion. > > > > > > > > We can polish the turd if you want, but the thing is, it's still a turd ... > > > > > > > > The right fix is to change drm_prime.c code to not call dma_map_sg > > > > when we don't need it. The problem is that roughly 3 layers of code > > > > (drm_prime, dma-buf, gem shmem helpers) are involved. Plus, since > > > > drm_prime is shared by all drm drivers, all other drm drivers are > > > > impacted too. We're not going to be able to cc: stable that kind of > > > > stuff. Thomas actually started with that series, until I pointed out > > > > how bad things really are. > > > > > > > > And before you ask: The dma-api change makes sense, and dma-api vs drm > > > > relations are strained since years, so we're not going ask for some > > > > hack there for our abuse to paper over the regression. I've been in > > > > way too many of those threads, only result is shouting and failed > > > > anger management. > > > > > > Let's do it right. If this is a regression from 5.9, it isn't a huge > > > one as that kernel was released last October. I don't like to see this > > > messing around with USB internals in non-USB-core code please. > > > > I get > > > > > git tag --contains 6eb0233ec2d0 > > ... > > v5.10-rc1 > > ... > > Ah, I thought you said 5.9 was when the problem happened, ok, yes, 5.10 > is slow to get out to a lot of distros that do not update frequently :( iiuc, Debian Bullseye release will be having v5.10.y. Ben ? -- Regards Sudip