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=-4.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,TVD_SUBJ_WIPE_DEBT,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 0D2A0C2BA2B for ; Thu, 9 Apr 2020 14:19:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AEC8C20771 for ; Thu, 9 Apr 2020 14:19:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BC90dwXA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AEC8C20771 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 594948E000D; Thu, 9 Apr 2020 10:19:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 544408E0006; Thu, 9 Apr 2020 10:19:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 432EF8E000D; Thu, 9 Apr 2020 10:19:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 35E4A8E0006 for ; Thu, 9 Apr 2020 10:19:43 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0C4D683F7 for ; Thu, 9 Apr 2020 14:19:43 +0000 (UTC) X-FDA: 76688525046.06.jail75_8efdcde433d53 X-HE-Tag: jail75_8efdcde433d53 X-Filterd-Recvd-Size: 7728 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Thu, 9 Apr 2020 14:19:42 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id g3so12162909wrx.2 for ; Thu, 09 Apr 2020 07:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZUmhXgHoG6HvjILgsbXz8GHCgll+LOxrRpBdz13V/lg=; b=BC90dwXA5AK4WR90ooTtvULwZnu4ZsRVQnQLV9NzDFZ7lKqicRXsEGPNedNOxy+3QI a1kmoOXSFteeDxdRL+7e8P62DjjD9bQZg3s3fofRhJoe7L1J9a46LbUxrQ6AtBTORXKV NDIKSoT9CEStlFz6MiX3tbzgvTr7KX9SEjLdYBH0eiP7EZNSClTpfzc0SSPSYynPiChj rYQTfJjtkntOCwrv+a6GMvAsCqYj/CQkd4PMEIkllHf9XhpKzORn/6xDs0+pafSbvmxv oU2GBI4+6mAQrXmQRuIHv6FAH1pdnq+zGKXLFmqILm/RS3QETgMEHnp/o0W7dlcGkPIh SqeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZUmhXgHoG6HvjILgsbXz8GHCgll+LOxrRpBdz13V/lg=; b=bogwesEkcDBUA5ErAVsPsF/YveuQ1G2I38tx63ZvNtAVHEONCAB9NZUMHVPzYGajNr 2PA9LfX6qX/yrJXLXNuSBvXZPmowcds0yGMBosIV6Fy7qlfOyz5KaMg0o6lVd5M549Pw uPzFCa5Xq04j5JxanST/Nb3f5cs+QxU7UEmzwAusrA1BJevX+vz79epp5rCOffmuTA49 O61BSVy3uQO6h2aox15+17cbyC9AqWzByz8GggE7cRTlpHvkHrylsEag1y/yjkTjv3dk wJWyT1qNDZJm/mbUwI1N81nQ1GKv/+Sk4dxb45Tgss7AMKHaQSb1V5ZfLO+zWuULagiY ZSmw== X-Gm-Message-State: AGi0PuZPq8MIKEV/zQVhkPfYi4OS7KUuBlVvc+ASVd98Soo7mqDdp0nC yqvVbvJPS9IoW+YxGFDf1GYCiae7cM7nCHh7l68= X-Google-Smtp-Source: APiQypLOoBbfys5GjBpuB2sw0gQny4RebKmCrdoglSc09SupmnqmNJDVTgB3bGVTn0oBHL2+TIHKXrenRgwfEr3zhLg= X-Received: by 2002:a5d:4145:: with SMTP id c5mr9091691wrq.362.1586441981450; Thu, 09 Apr 2020 07:19:41 -0700 (PDT) MIME-Version: 1.0 References: <20200408115926.1467567-1-hch@lst.de> <20200408115926.1467567-20-hch@lst.de> <20200408122504.GO3456981@phenom.ffwll.local> In-Reply-To: From: Alex Deucher Date: Thu, 9 Apr 2020 10:19:30 -0400 Message-ID: Subject: Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc To: Daniel Vetter Cc: Benjamin Herrenschmidt , linux-hyperv@vger.kernel.org, David Airlie , dri-devel , Linux MM , "K. Y. Srinivasan" , "open list:GENERIC INCLUDE/A..." , linux-s390@vger.kernel.org, Wei Liu , Stephen Hemminger , X86 ML , Christoph Hellwig , Peter Zijlstra , Laura Abbott , Nitin Gupta , Haiyang Zhang , "moderated list:DMA BUFFER SHARING FRAMEWORK" , bpf , Linux ARM , Christophe Leroy , Robin Murphy , Linux Kernel Mailing List , Minchan Kim , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Sakari Ailus , Andrew Morton , linuxppc-dev Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter wrote: > > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt > wrote: > > > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote: > > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: > > > > If this code was broken for non-coherent caches a crude powerpc hack > > > > isn't going to help anyone else. Remove the hack as it is the last > > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL. > > > > > > Well Ben added this to make stuff work on ppc, ofc the home grown dma > > > layer in drm from back then isn't going to work in other places. I guess > > > should have at least an ack from him, in case anyone still cares about > > > this on ppc. Adding Ben to cc. > > > > This was due to some drivers (radeon ?) trying to use vmalloc pages for > > coherent DMA, which means on those 4xx powerpc's need to be non-cached. > > > > There were machines using that (440 based iirc), though I honestly > > can't tell if anybody still uses any of it. > > agp subsystem still seems to happily do that (vmalloc memory for > device access), never having been ported to dma apis (or well > converted to iommu drivers, which they kinda are really). So I think > this all still works exactly as back then, even with the kms radeon > drivers. Question really is whether we have users left, and I have no > clue about that either. > > Now if these boxes didn't ever have agp then I think we can get away > with deleting this, since we've already deleted the legacy radeon > driver. And that one used vmalloc for everything. The new kms one does > use the dma-api if the gpu isn't connected through agp. All radeons have a built in remapping table to handle non-AGP systems. On the earlier radeons it wasn't quite as performant as AGP, but it was always more reliable because AGP is AGP. Maybe it's time to let AGP go? Alex > -Daniel > > > Cheers, > > Ben. > > > > > -Daniel > > > > > > > > > > > Signed-off-by: Christoph Hellwig > > > > --- > > > > drivers/gpu/drm/drm_scatter.c | 11 +---------- > > > > 1 file changed, 1 insertion(+), 10 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c > > > > index ca520028b2cb..f4e6184d1877 100644 > > > > --- a/drivers/gpu/drm/drm_scatter.c > > > > +++ b/drivers/gpu/drm/drm_scatter.c > > > > @@ -43,15 +43,6 @@ > > > > > > > > #define DEBUG_SCATTER 0 > > > > > > > > -static inline void *drm_vmalloc_dma(unsigned long size) > > > > -{ > > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE) > > > > - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL)); > > > > -#else > > > > - return vmalloc_32(size); > > > > -#endif > > > > -} > > > > - > > > > static void drm_sg_cleanup(struct drm_sg_mem * entry) > > > > { > > > > struct page *page; > > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data, > > > > return -ENOMEM; > > > > } > > > > > > > > - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT); > > > > + entry->virtual = vmalloc_32(pages << PAGE_SHIFT); > > > > if (!entry->virtual) { > > > > kfree(entry->busaddr); > > > > kfree(entry->pagelist); > > > > -- > > > > 2.25.1 > > > > > > > > > > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel